Personas are a powerful technique to describe the users and customers of a product in order to make the right product decisions. This post shares my tips to create helpful personas for digital products.
1. Get to Know the Users
Any persona description should be based on knowledge gained from direct interaction with the target customers and users. This is necessary to build a connection with the beneficiaries of your product, develop empathy, and understand their current wants, needs, and circumstances.
Before you create your personas, you should therefore get to know your audience, for example, by observing how they currently get a job done and by interviewing them. Otherwise, your characters may not accurately represent your target group. In the worst case, they are based on ideas and speculation, not real people. Involve (some of) the team members in the user research work, including UX people and developers. This allows you to leverage their knowledge, and it establishes a shared understanding of the users and their goals.
Put aside any ideas about the desired user experience and the product features when you develop your personas. Describe the characters according to your market insights. Do not make them fit your ideas and assumptions!
2. Keep your Personas Concise
While every persona description should help the team members understand who the beneficiaries of the product are and what the goals they pursue, I recommend that you make and keep your personas concise so they fit on an A4 sheet of paper.
Be careful not to bloat them and don’t add irrelevant details, for instance, another spare time activity or a cute pet. While your personas have to contain enough information to be usable, too much detail makes them difficult to work with. Only include information that helps you make informed decisions about the user interactions, the visual design, and the product functionality. Leave out the rest.
My simple, minimalist persona template wants to help you write concise personas. You can download the template by clicking on the picture below.
3. Distinguish User and Buyer Personas
Create separate user and customer personas whenever the users and the customers are not the same people. This allows you to capture the user and the customer-specific needs, and it makes divergent or conflicting goals easier to see.
Say we want to develop a new, advanced X-Wing Fighter, admittedly a highly implausible but fun scenario. The Rebel Alliance pilots would want a plane that’s easy to fly and well protected. But the purchase department of the Alliance is likely to be concerned with its price and maintenance cost. Employing two different personas allows you to model the user and the buyer, and to state their different goals.
4. Choose a Primary Persona
Whenever you create several personas for a product, choose one primary persona. The primary persona is the character you mainly design and build the product for. Say we choose Luke, a pilot, as the primary persona in the X-Wing Fighter example above. Then meeting Luke’s goal—creating a plane that’s easy to fly and well protected—becomes our top priority. But if we choose John, a purchase team member, as the primary persona, then the resulting product would be very different.
If you find it difficult to choose one primary persona, this may indicate that your target market is too large and heterogeneous, or that your product has become too big and complex. If that’s the case, then consider re-segmenting the market, unbundling the product, or introducing product variants.
5. Make your Personas Believable
Your personas should help the development team empathise with the users and view the product from their perspective. To achieve this, your personas must be believable. The following three tips help you with this:
- Base your personas on first-hand user research (as discussed above).
- Choose a representative name and picture.
- Create and update personas together with the development team.
6. Focus on the Main Benefit or Problem
I frequently see personas that contain a lengthy list of goals. While is it is perfectly OK that a persona description states more than one problem that should be addressed or benefit that should be offered, I recommend selecting one main problem or benefit—the true reason why the persona would want to use or purchase the product. This creates focus and facilitates effective decision-making. If you feel that the other persona goals are too important to omit them, prioritise the goals and put the primary one at the top.
7. Connect Personas and User Stories
Make the most of your personas, and use them in the scenarios, the storyboards, the workflows, and the user stories you discover: your primary persona should be the protagonist in your stories. The template below puts the user or customer modelled as a persona into the user story (based on by Rachel Davies’ user story template).
As <persona> ,
I want <what?>
so that <why?>.
8. Involve the Development Team Members
The best persona descriptions are worthless if the people who should use them don’t understand or accept them. I therefore recommend that you involve (some of) the development team members in creating the personas. Ideally, the individuals should participate in the user research on which the personas are based.
If that’s not possible, then review the initial persona descriptions together with the team members and be open to feedback. Don’t add unnecessary or speculative details, but be willing to adjust the descriptions so that they are easier to understand for and resonate with the team members.
9. Don’t Forget to Update Your Personas
Adjust your persona descriptions, as you lean more about the users and customers and their needs by building prototypes and product increments. This is particularly useful in an agile context, where you want to minimise the amount of initial market research and start with provisional, good-enough personas to quickly test your crucial ideas. Adjust and refine your personas based on the insights you generate. Rewrite your personas or start with brand-new ones if you have to pivot and change your product strategy.
10. Recognise when Personas are not Appropriate
While personas are a powerful tool, there are instances when they are not appropriate. If you create a bespoke product that serves a small user group, then working with personas may not be necessary. Similarly, if your product does not have any end users, employing personas is not advisable.
Take a client of mine that develops a physics engine, software responsible for the clever animations in computer games. The users of the software are games developers who integrate the engine into their code. Creating personas for the physics engine is not beneficial in my mind. But for the entire game it is, of course.
Post a Comment or Ask a Question
12 Comments
Hi! As a self-taught User Researcher I find your resources very helpful. In terms of creating personas I’m not always sure how many personas to do. I work in the Edtech field and often have conversations about is the user a teacher or student. I see this related to buyer or user but any extra thoughts you had would help here. I also find the different education levels of students and the different goals of the teachers difficult – how do you know how many personas to create? Many thanks in advance!
Hi Becky,
Thank you for sharing your feedback and question. How many personas you need will depend on the size and diversity of the market (segment) you choose. The larger and more diverse the target group is, the more personas you will need. From a practical perspective, I would try to work with less no more than ten personas. If you find that’s hard to achieve, then try the following two things: First, check if the persona goals are overlapping. If that’s the case, you may be able to remove one of them. Secondly, consider choosing a smaller target group.
Hope this helps!
Thanks Roman! This was very helpful!
Who develops personas? Is this driven by the PO? I’m currently a SM and being asked to help with developing personas. I’m fine facilitating discussions /workshop to develop personas but I feel the PO should be driving the meeting. Thank you!
Thanks for sharing your question Cristi. I agree that the product owner should lead the persona creation effort. I also recommend that (selected) development team members collaborate with the product owner including the UX designer. This ensures that the persona descriptions are clear and it exposes the team members to the users, as personas should always be based on interviews, observations, and other user research work. This, in turn, increases the team’s understanding of the target market and the team members’ ability to empathise with the users. Hope this helps!
Hi Pichler,
I am a product owner in my organization. I am interested in determining the product performance and the project progress. What KPIs i should use? please guide me through this.
Thanks
Hi Asma, Thanks for sharing your question. You can find my advice on how to choose the right KPIs in the article “10 Tips on How to Choose the Right Key Performance Indicators“. You may also want to take a look at my post “The Product Roadmap and the Release Plan” to better understand how you can track the project progress. Hope this helps!
> … “Creating personas for the physics engine is not beneficial in my mind.”
The physics engine case seems to me a good example where personas would be useful to the development of an API.
Rationale.
the use and adoption of a such a physics engine will depend on how well it matches the mental models of physic laws game developers have in their mind. You need to identify what most game developers understand of physics, and what basic and advanced needs they have, so to shape your API accordingly.
As I mentioned on G+, as someone who’s used personas in the past, I like this overview. A few comments: First, add a real user quote or two to each persona to give it some life. If you’ve talked to 10 or 20 people, you should have some interesting quotes..if not, you aren’t ready to do anything beyond an ad-hoc persona 🙂 Second: For the details column of your canvas, I’d suggest thinking about which attributes genuinely describe your users and (ideally) affect their need for/use of your product…. and omitting the ones that don’t. Thirdly: Any particular reason you refer to “Customer personas” rather than the more standard “buyer personas”? Or is that more of a UK term? 🙂
Hi John, Thanks for your great suggestions. I usually use “customer persona” and “buyer persona”, but opted for the former in the post. Kim Godwin uses the term “customer personas” in the persona chapter of her book “Designing for the Digital Age” btw, and I believe she is American 😉
Hello Pichler,
I want to ask you a question but there is no place on your website where I can post this question. So I am asking here:
Q. As per your experience and observation, What KPIs are being used in Agile/Scrum based software development companies?
Your input is valuable for my thesis work and appreciated.
Thanks & Regards,
Hi Sadia, Thanks for your contacting me. The best place to ask me a question that is not related to a post is: https://www.romanpichler.com/contact/
To help you choose the right KPIs, please let me know what you want to measure. Are you interested in determining the product performance or the project progress?