“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:
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:
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.
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?
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!