“I mean, I don’t think that Linda would be able to figure that out on her own, I think we’d have to give Carmen and Alonzo the ability to fill that information in for her.” Jonathan mused. “I can reconfigure part of the database to make that possible, hang on, let me look at something…”

Our primary roles as a Product Owner is to know what will drive value for our project – much of this comes from knowing what customers or users need.

We can’t do this alone, we have to have the team in alignment (if not always agreement) about what customers and users will want and be able to understand. How can we get the team here without wasting their time in endless meetings and user-interview sessions? The best way to do this is to establish personas.

At the core, personas are a tool to help a team think about the problem from a certain perspective – the perspective of a user or customer. In this article, I’ll outline how Personas  can improve efficiencies in production, mitigate business risks, and serve as a template for understanding post-launch successes and shortcomings of a product. At the end, I include a list of questions that can help you build your own personas.

What is a Persona?

A Persona is a character that we use to talk about the product we’re building. We’ll usually have a few that represent the different types of user or customer that we’re likely to have. Here is an example of some personas for a project I worked on recently:

<Image of personas for metar4u>
Personas usually have Names, personal details, and personalities. We usually construct them after doing research about our perspective users.

When we build products, personas are a tool for creating better hypotheses about whether the product will be successful. Buy building and talking about these characters as if they are real people, we’re able to better frame internal conversations to have more clarity around our goals.

A Persona is a Tool

What information should I fill out about my persona? We can think of two things that this tool is meant to accomplish:

Build Empathy

Building something for an actual human just feels better than building something to check boxes in a requirements doc. Just give it a shot, you might like it.

Seed Conversations

More importantly, Personas enable us to frame questions in ways that help us explore user experience questions. Yes, a user can execute the function that results in a printed report, but can Karen figure out how to do it?


Lets compare two example personas from a project I worked on a few years ago. Both Linda and Carmen were personas we used for an app that would enable distributed families to send money home to their families for healthcare expenses.

<Image of Carmen and Linda persona cards>

From a strictly functional perspective, this seems like a pretty simple idea – users can send money from one country to another (input money, choose a contact from a list, send the money, recieve, etc…). Take a second to think about what this app should look like – if you have a few minutes, sketch a few screens.

Pretty simple, so why do we need Carmen and Linda?

First picture Carmen. Though her family is stretched across two countries, Carmen is the central node of communication (and gossip) that keeps the family connected. Carmen’s husband gets paid every Friday evening in cash. Saturday morning, she takes that cash to her grocery store in Texas where, two young sons in tow, she buys a week’s worth of groceries, stops by the Western Union counter to send some money home. She doesn’t have a bank account, but her sister – who used to have a job which got her a visa – has a one, but they keep the account empty except for when they need to write a check for something. 
Linda lives in a small town outside Guadalajara, Mexico. She is 67 years old and uses a smart phone her grandson bought her for around $30usd. She doesn’t know much about it, her grandson manages most of it for her, but she knows how to use facebook to show off pictures of her grandkids and she loves using it to take pictures with her church group when they take trips on Sundays. She has been going to the same doctor, Dr. Mena, for 25 years. He carries a brand new, top-line iPhone, but at the office his “digital set up” consists of an aging Dell that he doesn’t know how to use (he has an assistant for that).

That app just got a little more complicated. What considerations do we need to take into account designing for Carmen?

  • Without her own bank account, she’ll have to send money in another way. Could the team discuss some opportunities in this area?
  • Carmen gets an influx of money at a pretty regular interval once a week (the same time she is thinking about sending some home to her family). What discussions could we have with the product team about this?
  • From a business perspective, what sorts of partnerships would we be looking into to make things easier for Carmen?

How about Linda?

  • Linda is getting on in years, her vision isn’t what it used to be.
  • Linda is almost certainly not up on the latest UI trends, but she does have one app that she has mastered – how does this knowledge affect our own design patterns?
  • Even if he is willing, Dr. Mena may have some difficulty understanding our product, particularly if Linda is the one telling him about it. How should we think about this as a team?

Thinking in Stories

(No, not User Stories, though those are an important tool too.)

The world is a big, messy place. When we think about building products for the real world, it isn’t just the functionality of the product, but the context that the product will be used in.

Luckily, your development team is (probably) made up of humans. Given context, humans are quite good at negotiating complex situations, understanding the wild, un-structured nature of real life, and creating solutions that will function in that sense.

I pride myself on being a good designer, researcher, and product owner, but I make a lot of mistakes. When I armed my team with Carmen, Linda, and a host of other personas, they were able to join conversations about product strategy in a more meaningful way and come up with a host of ideas that I would never have thought of, including a bunch of technical solutions that I wouldn’t have known were possible. The difference: they could picture a person they were designing for.

Create your Own

On the project mentioned above, we did a bunch of design research to get to know some actual potential customers for our service. They started a little shallow – more as user types* with names and random pictures we found on the internet – but as we met more people and had more conversations, they grew to have unique personalities, virtues, and pitfalls.

*A User Type is a role in a system. In our system, for instance, user types may have been senders, receivers  doctors, and assistants. We used three personas to discuss “senders.” Carmen was a “sender,” but since her life was far different than the more affluent “Alonso” or the more migrant “Hector,” it helped both our design and business strategy conversations to use these personas.

On the next page I’ve outlined a 5-minute getting-started guide for building personas and included a few tips. Have fun!

Categories: How To