You may already have been handed user personas: a polished profile with a photo, a first name, an age, some hobbies and a quote. It was shown once at the kick-off meeting, then filed in a shared folder nobody opened again. The tool is not to blame. The trouble lies in how the profile was made, and above all in the fact that nobody had decided what it was for.
I designed Moonworkers, my payroll software for small UK businesses, starting from its users: personas first, then wireframes, then a Figma design system. And I use a very stripped-down form of persona every day in my content machine. Here is what I take from it: which type of persona to make given your time and data, how to build it, and how to put it to work afterwards.
01A persona is a decision tool, not a portrait
Nielsen Norman Group defines a persona as a fictional yet realistic description of a typical user, grounded in research with real people. The same article gives the rule I find most useful: every piece of information needs a reason to be there. If it would not change the design or help settle a decision, it goes. A persona's favourite wine has no place in an intranet profile, but it matters for a marketplace for sommeliers.
The other benefit is quieter: a shared vocabulary. In a meeting, the persona's name stands in for a long description. Instead of everyone holding their own idea of "the user", the team talks about the same person. When someone says "Claire will never read that on her phone between two appointments", the discussion moves on.
So my rule is simple: a persona that settles no decision is a poster. Before writing one, I note the three or four decisions it will have to help with (the home page, the order of a journey, the tone of the content, what we will not build). It is also the first question Nielsen Norman Group asks in its article on persona scope: what are these personas for?
02Three ways to make personas, depending on time and data
There is no single way to create personas. Nielsen Norman Group describes three types, which differ in the research behind them:
- proto personas, built in a 2 to 4 hour workshop from what the team already knows or assumes, ending with 3 to 6 personas;
- qualitative personas, drawn from interviews with 5 to 30 users, which the author considers right for most teams;
- statistical personas, which add a survey of at least 100 respondents, ideally 500, and statistical analysis.
For a small business, the choice is usually between the first two. Proto personas have a real merit: they make everyone's assumptions explicit. They also have a flaw, which the same article names: they can become an echo chamber for the team's mistakes. I always present them as a hypothesis to test, never as a finding.
Statistical personas are rarely justified in a small organisation. They need the qualitative research first, plus statistical work, and often end up close to the qualitative personas anyway. One point in that article stayed with me: personas built only on demographics or website analytics do not tell you why people act as they do. And the why is what you design with.
03Creating personas in five steps
This is the method I follow, in a version a small team can get through in a few weeks at most.
1. Write down the decisions before the profiles
I list what the personas will have to settle, and at what level. A persona for the whole company and a persona for one specific tool do not hold the same information: the wider the scope, the more general the data, and the less it helps you design a screen.
2. Gather what you already know, then treat it as a hypothesis
The UK government's Service Manual is very clear on this: any opinion that does not come from users is an assumption to be proven by research. So I start from analytics, support requests and sales feedback, keeping that label firmly in mind.
3. Talk to real users
Short interviews, focused on what the person is trying to do, how they do it today and what gets in the way. I listen for the words they use, because those words will end up in headings and buttons.
4. Group by behaviour and needs, not by age
I group people who share the same goals, the same difficulties and the same expectations, even if everything else sets them apart. Then I write the needs in the Service Manual format: "As a… I need… so that…".
5. Cut the profile down to what is useful
A name to remember them by, the context of use, how familiar they are with the subject, their goals, what holds them back, and one sentence said by a real user. Everything else goes. After that, the profile has to live in the working tools: in the mock-up brief, in the test plan, in the scoping week of a project.
04What I did with Moonworkers and with this blog
At Moonworkers, the personas were the starting point for everything else. They guided the wireframes, then the Figma design system that followed.
In my content machine, I use a blunter version. Every article brief has a "reader" field: who reads, in what situation, with what problem, in one sentence. As long as that field is under 30 characters, or still holds the example text, the tool rejects the brief and writing does not start. It is a persona cut down to what serves a decision, and checked by a machine rather than by good intentions.
That field really does change the text. An article written for "businesses" speaks to everyone, so to no one. An article written for a founder who has already paid for useless profiles starts somewhere else, picks different examples and stops sooner.
05The B2B persona: a role in a situation
In B2B, I first describe a role in a situation, not a person with an age and hobbies. The person who uses the tool every day is often not the one who chooses it, nor the one who signs. Each has their own questions, and a page that answers only one of them leaves the others hanging.
The Service Manual also reminds you to consider the people who provide or support the service, not just "typical" users. In business software, that is often the accountant, the administrator or the support team. They appear in no marketing profile, yet they are the ones who recommend or block a tool.
For acquisition, I link each B2B persona to a moment in the buying journey and to what they need to read at that moment. That link is what later lets you build a marketing plan that does not try to speak to everyone at once.
06Why personas fail
In a short video, Why Personas Fail, Nielsen Norman Group lists the causes of failure it sees. I keep three.
First, personas that are too broad. People want one set to serve the whole company and end up with profiles so general they help design no specific feature. Second, personas handed over like posters, without telling the team how to use them. Third, personas created alone in a corner and then passed to others, who do not believe in them because they do not know where they came from.
I will add an honest limit of my own. Personas do not replace testing with real users: reviewing a mock-up "from Claire's point of view" helps, but it does not tell you what Claire will actually do. That is why I follow them with a clickable prototype tested before development. And if your budget allows no interviews at all, a proto persona is better than nothing, as long as you present it as a guess.
07Where to start this week
If you already have personas in a folder, take them out and ask one question: what decision have they helped make in the last six months? If the answer is none, do not bin them straight away. Keep what rests on facts, strip out the decoration, and add the decisions they will have to serve.
If you are starting from scratch, start small: half a day of workshop to write down your assumptions, then five interviews with real customers to test them. You will have a primary persona that is imperfect but useful, and you will correct it as you test.
This is the kind of work I do at the start of a project, in scoping or design, and you will find the details in my services. If your personas are asleep in a folder, we can talk about it.