Persona

The word "user" comes up dozens of times a day on a product team. The trouble is that it points at a different picture for everyone in the room. The engineer is thinking of whoever filed a support ticket an hour ago. The designer is thinking of the person she interviewed last week. Sales is thinking of the team lead at the company whose contract fell through yesterday. All users, none of them the same person.

Meetings took a familiar shape because of it. Someone proposes simplifying the settings screen, someone else objects that users want fine-grained control, and a third person says users wouldn't know what to do with those controls anyway. Everyone is arguing from someone they actually met, so nobody is wrong, and the conversation doesn't converge. The decision ends up going to whoever spoke loudest that day or ranked highest in the room.

Averaging made it worse. Survey twenty people, and you get a mean age of 34, a mean team size of 7, and 22 minutes of use per day. Tidy numbers, and not one real person matches them. On one side sits a freelancer working alone; on the other, a team of thirty sharing one workspace; the average points at an empty spot between them. A screen built for a person who doesn't exist ends up half-right for both. Permission settings feel like clutter to the freelancer and come up short for the team of thirty.

A persona solves this with a representative instead of an average. Stories from research get sorted into similar piles, and each pile is written up as one person with a name, a job, and a shape to their day. In the next meeting, people say that name instead of "the user," and the moment they say it, everyone pictures the same person. That's why this document shows up so often in product discovery, the work of checking whether something is worth building before building it. User research goes out and collects the raw material; the persona is where that material gets set into a form the team can use every day.

There's only one group under persona: three types, split by who gets drawn and what the drawing rests on.

Before the types, it helps to know what fills a page. A persona is usually one page per person, with six lines on it.

1. Name and photo — something you can say out loud, like "Dohyun, marketing associate." The person is a composite rather than an individual, so the photo comes from a commercially licensed stock library. The naming has one purpose: nobody remembers "User A," and everyone remembers Dohyun six months later.
2. Situation — three or four sentences on where they work, what they do, and how a day goes. Whether the team is five people or fifty, whether they decide alone or have to get sign-off, belongs here. Constraints count as situation too: a person who lives in shared calendars all day reads a notification differently from someone heads-down in an editor.
3. Goal — what they're trying to finish by using the product. Written as their work rather than as a feature: not "make documents look nice" but "pull four colleagues' comments into one page before the meeting."
4. Where they get stuck — the specific place the work stalls today, taken from observation. Not "it's hard to use" but "the colleague who gets the invite link turns back at the login screen."
5. Tools and fluency — what they already use and how fast they pick up something new. You can't hand the same screen to someone who has the shortcuts memorized and someone who hunts through menus.
6. A quote — one or two sentences carried over verbatim from research. This line is what marks the other five as observed rather than invented.

The three types divide by whether evidence exists and by whose page it is.

1. Proto-persona — drawn before any research, from what the team already believes. Two hours in a meeting room produces one. Its value isn't accuracy but exposure: when four people each draw a page and the user's team size comes out as 3 on two of them and 40 on the others, the first thing to check in research has just picked itself. It's an assumption, so it gets thrown out and redrawn once findings arrive, which is why these pages usually carry a label at the top saying they predate research.
2. User persona — the person who actually opens the product, making documents, leaving comments, sending invites. How screens get laid out and which features come first ride on this page. It's what most teams mean when they say persona.
3. Buyer persona — the person who decides whether money gets spent. In products sold to companies, that person often spends under five minutes a day inside the product. The daily user cares whether the editor is fast; the person approving the invoice cares whether it clears a security review and fits the existing purchasing process. Merge the two pages and you get either a lovely product nobody can buy or a compliant one nobody uses. In consumer products the two are the same person, so one page covers it.

The types run in sequence. With no research yet, a proto-persona records the assumptions and gets work started; once interviews supply material, it becomes a user persona. If the people who buy differ from the people who use, a buyer persona joins as a second page. Fewer pages is better. Keep six of them and every meeting starts by arguing which page applies, which means none of them get used. Stop at two or three and treat the rest as variations. A variation is a line or two noting how one segment departs from the main page, not a new page of its own.

Who writes it and who reads it is worth knowing too. The draft comes from whoever ran the research, usually a product manager or designer, and sales and support check it against the customers they meet. The readership is wider: designers laying out screens, whoever writes the interface text, the meeting where priorities get set, marketers drafting ad copy. That's why a persona lives separately from the research report. Thirty pages of findings never get reopened; one page ends up on the wall. The report keeps a trail back from that page to the interviews behind it.

The material comes from outside these three types. User research supplies fresh conversations, and complaints and requests that have already piled up come through voice of customer (VOC). A finished persona then becomes material for other documents: a customer journey map, which lays out how a customer discovers, uses, and eventually leaves a product, starts by putting a persona in the role of the person walking that line.

"This feature isn't for Dohyun. It's for the person who only approves things."

The work under discussion targets the buyer rather than the daily user.

"That isn't in the persona. Where is it coming from?"

Asking whether the claim just made rests on research or on a hunch, and asking for the source rather than dismissing it outright.

"Our persona is a year old, so I wouldn't trust the team-size line."

Part of the document has aged out and can't be used as evidence.

Pagedeck redrew its personas during a quarter when paid conversion stalled. Until then the team worked from a single page: a freelancer. Most free users did work alone, so it was a reasonable page to have, but the paying side signed team contracts, and nobody who approves a purchase appeared anywhere on it.

Mia put eight user interviews next to five contract records Sofia brought over, and the pile split in two. One was the person making documents daily. The other was a team lead who decides whether to adopt a tool and then checks usage once a month. When Noa pinned the two pages side by side, all six features shipped the previous quarter turned out to have been built from the first page only. The team lead's page listed a goal — see who is actually using this — that the product had no screen for.

The next quarter started with an admin view showing who had opened the workspace that month. It took half a year to notice that one of the two pages had been blank the whole time. The interviews behind it had been sitting in a folder since spring; nobody had sorted them into a second pile.

The most common mistake is reading a persona as a demographic profile. The template has boxes for age, gender, city, and hobbies, so filling those boxes feels like the job. The lines that actually drive decisions sit elsewhere. Knowing someone is 32 and likes hiking settles nothing about the settings screen, while "has to pull four colleagues' comments into one page before the meeting" and "the invited colleague turns back at the login screen" point straight at what to build next. Spend the time on hobbies and compress the goal and the sticking point into one line each, and nobody opens the page again after the day it was made. For teams building work tools rather than consumer goods, what a person is accountable for at their company decides far more than their age does. A useful test is to cover the top of the page and ask whether the rest still tells you what to build; if it doesn't, the wrong lines got the attention.

The second mistake is treating it as a one-time deliverable. A good page looks finished on the wall, and once it's up there's no obvious reason to touch it. But a persona is research frozen at a moment, and it ages exactly as fast as that research does. When a product shifts from solo users to teams, when a price increase changes who signs up, when a competitor appears and people start arriving with comparisons in hand, the page on the wall is already describing someone else. New joiners still read it as current fact and go fix the wrong thing. Noting on each line when it was written and which study it came from is what separates the lines still worth trusting from the ones that have quietly turned back into guesses.