How to do personas properly


What’s a persona, then? Done well, It’s a handy reference guide that helps designers and developers remember who they’re designing and building for throughout their project, because it’s certainly not themselves. Personas are concise, practical little documents, summarising everything your project team knows about the users of the application or service you’re creating. They can help us all remember what really matters over the weeks or months we’re working away in our office, worrying about deadlines and sprint planning sessions rather than customers.

You’ve doubtless heard of personas before, and the majority of you will have created - or tried to create -a few yourselves, but I’ll wager that for many of you, they didn’t seem to be that useful, and didn’t really get used much thereafter. Why should you go back and try again?

Done properly, personas can help a team maintain empathy with specific people who aren’t present, rather than falling back on a much more risky, generic profile which can be loaded with assumptions and projections from team members. That’s good, as the success of the product we’re building depends upon us giving customers what they need and want. As a project team we need something to challenge us when we all like a feature and want to put it in, or when we can’t decide how to prioritise the backlog, because what we want doesn’t matter. All that matters is what our customers experience and how it matches their expectations.

Joining projects, I’ve inherited a lot of personas over my fifteen years in design, and to be honest have only seen a tiny handful that were ever done well. The vast majority have either been woefully light on detail, have been made-up in a boardroom based on team assumptions, or have captured strange details that aren’t relevant to the project, like someone’s dog’s name or their favourite sport. Often I’ve seen personas made as something of a box-ticking exercise, dreamed up because people felt they were supposed to make them, rather than as a practical tool to help people work.

So how do you do personas well?
These are my top tips for avoiding the common pitfalls and making the time invested worthwhile.

Base them on real knowledge

If your team knows nothing about your users, there’s no point starting personas at all. In fact, there’s little point starting the project, full stop. Do your homework, first. The best information comes from first-hand contact such as interviews, group workshops and usability tests. If you can’t get this, then find someone in your organisation - or client’s organisation - who does have first-hand experience. This might the product owner, customer services staff, technical support, sales reps.. Find them and see what they can tell you. A persona that’s made up on people’s hunches is a complete waste of everyone’s time.

Make them real people if appropriate

If you’ve met a range of real people in your earlier user research - yes, it’s entirely appropriate to make them your personas and name them as such. Anything that helps your team keep real people in mind over spec documents is a good thing and will lead to a better product.

Don’t ever assume your user is just like you

It’s depressingly common for teams to end up making decisions based upon what they feel is right, ultimately designing for themselves rather than taking steps to check their assumptions. Your users may be mostly like you, but you need to be sure of that- which means going to find out - and furthermore there will always be differences which you need to know about to deliver a quality experience. If you hear people say “Well if it was me, I’d use that feature all the time” call it out and pull out your personas to steer things back on track.

Keep them short and keep them to hand

The persona needs to be something team members can refer back to quickly at any time, often whilst discussions are in full flow. If it’s a big document, no one's going to read it. Keep it to a single page if you can - other details can always be captured on a user story map or similar. In addition, stick them on the wall or put them somewhere easy to find. They’re not going to get used buried in a Dropbox folder, somewhere.

Stick to a handful

I once joined a digital transformation project that had 19 separate personas, which was too many to be practical - most of us couldn’t remember the difference between them. Differences between personas need to be significant to impact your design effort, and you want a handful at most to capture the main points concisely.  

I typically have 1-2 primary personas - those who will use my application the most or get the most value from it - and perhaps the same number of secondary personas, furnished with less detail. These might be admin users or people who use your application less frequently to do things like audit and create reports.

Find a decent photo.

Seriously. No’one takes a cheesy stock photo seriously.

You want a photo because you’re trying to build empathy with people who aren’t present. Giving them a believable face will help. If you have a photo of a real customer, use that. If you don’t, then get a decent quality, natural-looking photo from or

Make the content mostly qualitative

Your client or company may have quantitative data on customers, and that’s well worth learning from, but by itself it’s not going to help. You need quantitative information such as customers’ relevant goals, motivations, concerns, feelings and what they expect to get out of your product. You can only get this kind of stuff by talking to people, as quantitative data can sometimes say what happens, but never why.


Tell a relatable story that builds empathy and understanding

Write your personas so that someone completely new to the project can read them and imagine themselves in their shoes. Avoid business jargon and acronyms - chances are not everyone using the personas will use your jargon. Tell everyone who this person is, how they think and what they need to do with the product you’re building.

Only add information that will impact design and development

If a piece of information isn’t going to inform and change what your team build, it has no business being included in a persona. The specifics will vary depending on what you’re designing. For example, if you’re branding or working on a consumer product, then it may be helpful to decide on a personas other favourite brands and something about their lifestyle. If you’re building B2B software someone would use at work, you need to focus more on their job and responsibilities.
Generally speaking, I try to include the following information in most of my personas:

  • Name

  • Job description

  • Goals and motivations

  • Concerns and frustrations

  • How they currently do the tasks they need to

  • Scenarios of use with a sense of frequency /priority

  • Devices they use and in which scenarios

  • Disabilities

  • Knowledge - technical, or domain

  • Language

Make them diverse as a matter of principle

If you’re in the tech industry, chances are your team is mostly male, mostly white and mostly of a similar mindset. I hope not, but the most likely scenario is that you’re designing and building for a very different type of person to the ones in the room.

It’s good practice to make your personas diverse in terms of gender, racial background and life experience. Challenge the norms of the project team when discussing what you’re building and you will all reap the benefits in the end.

Consider and add different disabilities

Additionally, unless you have evidence to the contrary, you can expect some of your customers to have a disability. This might be physical, meaning they need a keyboard or screen reader. It might be cognitive, such as dyslexia or dementia. It might be sensory, meaning they have one of several different forms of colour blindness. Don’t make the half-hearted effort of tacking on an extra persona as the ‘accessibility one’ - you’re dealing with real, well-rounded people here. Instead, give one or more of your primary personas a disability to ensure you’ll keep talking about accessibility regularly.

Use them to question, evaluate features and find the limits of your knowledge

Once you have personas built, you need to use them. Refer back to them to help your team make decisions about scope, priority and design details. For example, if a new feature is proposed, ask which persona/s it will benefit - does it match up with their overall goals? If you can’t decide how to prioritise your work, use the personas to ask what will deliver the most value to users. Recognise also, that you might not have all the information you need for your personas. Leave sections on them that say ‘TBC’ and complete them later, once you’ve learned more.

Use them to recruit for usability testing

Next time you arrange direct contact with customers - perhaps to usability test or get some feedback on early concepts - refer to the personas to help your recruitment effort. Ensure you’ve met with an appropriate range of people who fit your persona profiles. If they don’t, then either you got the wrong people, or perhaps your personas need to be revisited?

Update them as you learn more

Personas, like user story maps and any kind of specification, should be evolving over the course of the project. Every time you meet customers you’re going to learn something more, and that means updating your personas to capture the new information. Don’t treat them as law - they reflect the sum total of your team’s user knowledge, and so it’s only right that they should change over time.

If you’d like help with user research and creating proper personas for your project, then I can help.