A persona is a short description of one kind of user: who they are, what they are trying to get done and the conditions they work in. The Nielsen Norman Group defines it as “a fictional, yet realistic, description of a typical or target user of the product”. You use personas to build a great user experience by making each design decision with a particular person in mind, instead of “the user”, who has a habit of wanting whatever the person speaking wants.
The method was popularised by Alan Cooper in his 1999 book The Inmates Are Running the Asylum. It works on two conditions. The personas must come from watching and talking to real users, and they must be used to decide things. A persona that is invented in a meeting and then filed does nothing for anyone.
What a persona looks like for a business system
In marketing, a persona describes a type of customer, with an age, an income and a set of interests. For an internal system or a customer portal it is more practical than that. It describes a role in a real job.
Here is an illustration for a job-scheduling system. The details are made up for the example. Yours should come from observation.
Sam, dispatcher
- Does: assigns and rearranges jobs all day, mostly while on the phone to a customer.
- Works at: a desk with two monitors and a headset, with constant interruptions.
- Needs: to see every engineer’s day at a glance and to move a job in a few seconds.
- Struggles with today: opening three screens to check whether the parts are in stock, and a paper list of promises made to customers.
- Skill: expert. Uses the system for hours every day and will learn keyboard shortcuts.
- Counts as success: never having to ring a customer back because the first answer was wrong.
Now set two others beside Sam. The field engineer uses the system on a phone, outdoors, twenty times a day for half a minute at a time, often with no signal. The accounts clerk at a customer’s office logs in to the portal once a month to download invoices, has never been trained and will not remember where anything is.
Those three people need three different things from the same system. Sam needs a dense screen that rewards practice. The engineer needs a few large buttons. The clerk needs a page so plain that it requires no memory at all. Without personas, one screen gets designed for an imaginary average of the three and suits none of them.
What to put in and what to leave out
| Include | Leave out |
|---|---|
| What the person is trying to get done | Invented ages, hobbies and favourite brands |
| The tasks they do and how often | A stock photograph and a quotation nobody said |
| Where they work and on what device | Personality types |
| How expert they are and how often they use the system | Anything you cannot trace back to something you saw or were told |
| What goes wrong for them today | |
| What a good day looks like |
The test for any detail is whether the design would change if it were different. How often someone uses the system passes that test: daily users want speed, and monthly users want to be led by the hand. Their taste in music does not.
Some personal characteristics do pass. If many of the users read English as a second language, or work in poor light, or wear gloves, that belongs in the persona because it changes the design. The same applies to eyesight and other accessibility needs.
How to build personas from evidence
- List every role that will touch the system. Include the occasional ones: the manager who only reads reports, the administrator who sets up new users, the customer or supplier who logs in from outside.
- Watch and talk to a few people in each role. An hour beside someone doing the job tells you more than a questionnaire. Our article on how to get user feedback for your app describes what to look for.
- Look for the differences that affect design. Frequency of use, device, surroundings and expertise are the usual ones. Two job titles may turn out to be one persona. One job title may be two, such as the new starter and the colleague who has done the job for ten years.
- Write each persona on one page. A name helps people talk about them. A role name is enough if invented first names feel artificial.
- Show each one to the people it describes. They will correct it, and they will be glad to have been asked.
A typical business system needs only a handful of personas. If you have many more, some are probably duplicates. Choose one as the primary persona, the person whose needs win when two of them conflict. Cooper’s advice was to design for one specific person and not for an average of everybody.
One caution. An AI assistant will write a plausible persona in seconds. With no observation behind it, the result is a guess in tidy formatting, and people will trust it more than it deserves. The Nielsen Norman Group’s guidance is that personas must be based on user research, and that has not changed. AI is useful for summarising your interview notes. It cannot replace the interviews.
How to use them once you have them
Personas earn their keep in the decisions that follow.
- Deciding what to build first. The tasks of the primary persona go into the first release. Requests that serve nobody on the list get questioned.
- Designing screens. Each persona’s frequency of use and device decide how dense or how simple their screens are. Different roles can be given different views of the same data.
- Setting permissions. Personas correspond closely to the roles in the system, so they are a good first draft of who may see and change what.
- Writing the scope. Requirements phrased around a persona are easier to check: “a dispatcher can move a job to another engineer without leaving the schedule”. That sentence can be tested. “A scheduling module” cannot.
- Choosing testers. When a prototype is ready, find at least one real person matching each persona to try it.
- Settling disagreements. “Would the engineer do that standing in a car park?” ends a discussion faster than opinion does.
Give the personas to your supplier along with the requirements. If you are buying bespoke software to an agreed scope, they help both sides see the same system. Section 2 of our software project planning worksheet, “Who will use it”, is the natural starting point.
Personas are one tool within a wider approach, described in our article on user-centred design. They mostly inform the UX half of the split explained in the difference between UI and UX design.
Where personas go wrong
- They are invented. Written in a meeting from assumptions, they record what managers believe about the job.
- They describe the buyer. The director commissioning the system is seldom the person who will use it for eight hours a day.
- There are too many. Nobody can keep a dozen people in mind, so nobody tries.
- They are filed. If the personas are not mentioned when screens are reviewed, they have stopped doing their job.
- They go stale. When the work changes, for example when engineers start taking payment on site, the personas need revisiting.
You can make a start in half an hour. List everyone who will use the system, and beside each write three things: how often they will use it, on what device and where. Lines that look the same are one persona. Then book an hour with one person from each remaining line and watch them work, before anyone draws a screen.