Personas
In short A persona is a fictional but specific user, built from research, that the team designs for instead of the vague “user”. Done well, personas settle recurring feature arguments and give you a concrete test for every UI decision.
Based on: A. Cooper, The Inmates Are Running the Asylum (1999), the persona method of interaction design.
On this page
Key ideas#
Alan Cooper’s book is the original source of personas as a software design method. Its core ideas:
Specific beats general#
The word “user” is elastic: everyone in a meeting stretches it to fit the feature they already want. A persona with a name, a job and a set of goals cannot be stretched. Cooper notes that the method starts to work when developers use the personas’ names in everyday conversation without being prompted. From then on, feature debates that used to restart at every meeting stay settled. The method fails when a team says “persona” but still thinks “user”: specificity is the active ingredient.
Design personas are not marketing personas#
Both look like short profiles of people, but they rest on different data. Marketing personas are built on demographics and sales channels; they explain how a product is bought. Design personas are built only on behavior and goals; they explain how it is used. Mixing them up is a common mistake.
Design for the user, not the buyer#
Teams often design for someone close to the product who does not use it: a reviewer, or the manager who approves the purchase. Cooper’s argument is that even when buyer and user differ, the buyer’s success depends on the real end user being satisfied.
The cast of characters#
Cooper suggests starting with roughly 3 to 12 candidate personas per project; after sifting, usually 3 to 7 remain useful. Not every persona is a design target:
- Primary persona — someone whose needs cannot be met by an interface designed for anyone else. Each primary persona gets its own interface. If you find more than three, Cooper reads it as a sign that the product is trying to do too much.
- Negative persona — someone you explicitly do not design for, even if they work close to the product. In one of Cooper’s cases, the product was meant to bypass an intermediary role entirely, not to make that role easier.
- Personas don’t need completely different goals. Two people with the same practical goals but different motives (one wants to avoid mistakes, the other wants a promotion) can be two personas.
Design for the most constrained primary persona#
Cooper’s in-flight entertainment case makes the point. Of the passenger personas, the team chose as primary not the frequent business traveler but an elderly passenger who was uneasy with technology and had limited hand mobility. The reasoning: an interface that works for the most constrained user will work for the others, but not the other way round. The result replaced menu hierarchies with a single scrolling strip of titles, driven by a large physical knob. Shortcuts for experienced travelers were there, but stayed out of his way.
One sheet, everywhere#
Cooper keeps the persona set on one page — name, picture, job, goals, a few personal details — and brings it to every meeting and into every document handed to the client.
How to apply it#
- Ground personas in research. Build them from interviews and observation, not from team opinions. Each one should trace back to real people you met.
- Write goals, not feature wishes. “Wants to know when the bike will be ready without calling” is a goal; “wants an SMS feature” is a solution.
- Name the primary persona for each interface, and name the negative personas. Record both in the vision or scope document.
- Use names in requirements. Write user stories and scenarios for a named persona, not “as a user”.
- Review against the persona. In prototype reviews, replace “Is this user-friendly?” with “Does this work for the primary persona?”
Review checklist#
- Every persona traces to research data.
- Each persona has goals and behaviors, not only demographics.
- Each interface has one primary persona, and there are no more than three overall.
- Negative personas are written down.
- Personas describe users, not buyers or approvers.
- Stories, scenarios and review comments refer to personas by name.
Example#
The Workshop, a fictional chain of 12 bike-repair workshops, is adding online booking. Interviews with customers and front-desk staff produce four candidate customer personas: a commuter who needs the bike back by Monday, a parent booking for children’s bikes, a cycling enthusiast who wants to specify exact parts, and an older occasional rider who rarely books anything online.
The analyst proposes the older rider as the primary persona for the booking site: if he can book without help, the commuter and the parent can too. The enthusiast’s detailed options sit behind an “Add details” link that the primary persona can ignore. The front-desk employee who today retypes phone bookings is a negative persona for the booking site: the site should remove that retyping, not make it easier. Front-desk staff get their own interface, with their own primary persona.
Pitfalls#
- Treating a persona as “user” with a name → keep the details and use them to decide.
- Too many primary personas → narrow the scope or split the product.
- Personas built from demographics → rebuild them around behavior and goals.
- Personas written once, then filed away → bring the sheet to every review.
- Designing for the person who signs the contract → design for the person at the screen.
Sources and further reading#
- A. Cooper. The Inmates Are Running the Asylum. Sams, 1999.