Personas that change decisions | Nautilus Tech Labs

Ask a team to show you their personas and you will often get a slide with a stock photo, a first name, an age range and a few hobbies. "Sarah, 34, loves yoga and values convenience." Then ask when the team last made a decision differently because of Sarah. The room usually goes quiet.

Personas were meant to do something more useful than that. Alan Cooper popularized them in software design in his 1999 book The Inmates Are Running the Asylum, as a way to design for specific people instead of an imaginary average user. The point was always to change what gets built.

Build them from behavior

Demographics rarely explain why someone buys, calls support or leaves. Behavior does. So the raw material for a useful persona is evidence of what people actually do:

interviews with customers, ideally while they do the task in question,
support tickets and call notes, which show where people get stuck,
product and website data, which show what they use and what they ignore,
and the sales team's notes on why deals are won or lost.

Look for patterns in goals and situations, not in age or job title. A facilities manager responsible for one cold store behaves very differently from one responsible for forty buildings, even if they have the same title and the same age.

Keep each persona to one page

A useful persona fits on a single page and answers a handful of questions:

What is this person trying to get done?
What situation are they usually in when they deal with you? Busy, on site, at a desk, under pressure?
What do they worry about getting wrong?
What do they do today when your product or service lets them down?
What would make them recommend you, or leave?

Use their own words wherever you can. A quote from an interview carries more weight in a meeting than any summary.

Three or four personas are usually enough. If you have eleven, nobody will remember any of them.

Tie every persona to decisions

This is the step most teams skip. For each persona, write down the decisions it should change. For example:

which features go into the next release,
what the onboarding emails say,
which support channel gets staffed first,
what you stop doing because this persona does not need it.

Then use the personas in the meetings where those decisions get made. A persona that is never mentioned in a roadmap review is decoration.

Revisit them every year

Customers change, and so does your business. Plan a short refresh each year: a few new interviews, a look at the latest support data, and a check of whether each persona still explains what people do. Retire the ones that no longer do.

A small test

Pick one decision your team is about to make this month. Ask which persona it serves and what that persona would want. If nobody can answer, your personas need work. That is the kind of research our customer experience team starts with.