1. Start with Provisional Personas
As its name suggests, a provisional persona is not a fully-fledged, detail rich user model, but a first version that is good enough to start discovering the right user experience and the right product features. Working with sketchy but good enough personas is particularly helpful in an agile and lean context where we want to very quickly test our assumptions, rather spending a lot of time with upfront market research.
To get started, learn enough about the users and customers by employing, for instance, direct observation and problem interviews. While your initial personas can be sketchy, they should be based on market insight and nor speculation. With your provisional personas in place, gather feedback on prototypes, product increments, and MVPs to validate and adapt your personas. As you run more iterations, your personas should become more refined. The following picture illustrates this process:
Note that provisional personas are different from proto-personas, as defined by Jeff Gothelf, as proto-personas are not necessarily based on user research.
2. Keep your Personas Concise
It’s easy to add more and more detail as you create your personas: Enriching the description and adding, for instance, another cool spare time activity or a cute pet can be so much fun. While your personas have to contain enough information to be usable, too much detail bloats them, and they become difficult to work with.
Only include information that is relevant, 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 wanst to help you write concise personas (you can download the template by clicking on the picture):
3. Distinguish User and Customer 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. The pilots would want a plane that’s easy to fly and well protected. But the purchase department of the Rebel Alliance is likely to be concerned with the purchase price and the maintenance cost. Employing two different personas allows us 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, the 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, the purchase guy, as the primary persona, then the resulting product would be very different.
5. Make your Personas Believable
Your personas should help the development team cultivate empathy for the users and customers, and to view the product from the user’s perspective. To achieve this, your personas have to be believable. There are three practices that help you create believable personas:
- Base your personas on user research.
- Respectfully choose a persona’s name, picture, and characteristics.
- Refine personas together with the development team.
6. Identify the Main Benefit or Problem
I frequently see personas that contain a lengthy list of problem and benefit statements. While is it is perfectly OK that a persona description provides more than one problem or benefit, 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.
7. Test your Personas
Validate your persona descriptions, as you lean more about the users and customers and their needs by building prototypes, product increments, and MVPs. This is particularly useful in an agile and lean context, where you want to minimise the amount of initial market research to quickly test your crucial ideas.
Adjust and refine your personas when you decide to persevere. But rewrite your personas or start with brand-new ones if you have to pivot and change your strategy.
8. 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. The following format helps you connect your personas with your user stories:
9. Visualise your Personas
Make you personas visible and accessible to everyone involved in the development effort. I find working with paper-based personas very beneficial, and I like to put them on the Product Canvas.
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 product that serves a small user group, then working with personas not be necessary. Similarly, if your product does not have any end users, the 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.
A FREE guide for agile teams.
Are you running retrospectives regularly? Perhaps you run retrospectives once a week, or fortnightly. Do you feel like you could be getting more out of your retrospectives and fuelling continuous improvement in your teams? You may already find retrospectives valuable, but suspect there are ways of making them better.