User Persona

When the word "user" came up in a meeting, everyone pictured a different face. The engineer pictured someone their own age who memorizes keyboard shortcuts, sales pictured the enterprise team lead they met yesterday, and the designer pictured someone opening the product for the first time knowing nothing. Because everyone used the same word, nobody noticed they were describing different people.

So the arguments never ended. One side wanted fewer menu items and the other wanted every feature visible, and both sides brought reasons — except one side's imagined person used shortcuts while the other's clicked through menus to find things. At Pagedeck a debate like that dragged on for two weeks, and the question left standing at the end was simply who this person we keep talking about actually is.

The material from user research, which gathers evidence by watching and asking users, didn't settle it either. Thirty pages of observation notes and interview transcripts don't get opened mid-meeting. A user persona compresses those thirty pages into one and hangs them on a person with a name. Of the three types that sit under persona, this one falls between the sheet drawn from assumptions before any research and the sheet drawn for whoever approves the spending: it covers the person who opens the product every day.

One sheet per person, six lines each.

1. Name and photo — give them a name you can say out loud, like Dana in marketing. They stand in for many people rather than being anyone real, so use a stock portrait you're licensed to use. The reason for the name is simple: nobody remembers User A, but everyone still remembers Dana six months later.
2. Context — three or four sentences on where they work, what the job is, and how a day goes. Whether the team is five people or fifty, and whether they decide alone or report upward, belongs here.
3. Goal — what they're trying to finish by using the product. Write it as their work, not as a feature: not "make the document look nice" but "pull four teammates' opinions onto one page before the meeting."
4. Where they get stuck — the point in that work where they currently stop. It has to be a specific place that came out of observation. Not "it's awkward to use" but "the colleague who gets the 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 memorizes shortcuts and someone who hunts through menus.
6. A quote — one or two sentences carried over verbatim from research. This line is the evidence that the other five weren't invented.

Lines 4 and 6 carry the weight of the document. Both come only from observation, so failing to fill them means the research isn't done yet. A sheet where the rest was filled in from imagination goes by a different name.

The draft belongs to the product manager or designer who ran the research. Without having gone through the material by hand, you can't tell which sentence you heard over and over from which one was a single person's exception. Sales and support review it next. That's where someone checks the sheet against the people they talk to daily, and it's usually where one or two missing conditions surface. Sales at Pagedeck added one that way: most of the accounts they closed had somebody from outside the company on the document, which nothing in the research had flagged.

The readership is much wider.

1. Designers building screens — what to put in plain sight, and what a first-time visitor sees first, gets decided against line 5.
2. Whoever writes the product's copy — UX writing guides people through the wording inside a product, and the same instruction gets written differently depending on whether the reader knows the jargon.
3. The meeting that decides build order — when two features tie in prioritization, the tiebreak is which one sits closer to line 3.
4. Marketers — ad copy and the first line of a landing page get written as if speaking to this person.

This is why a persona lives apart from the research report. Nobody reopens a thirty-page report, while a single page ends up taped to a wall. In exchange, the report keeps a place to trace which interview each line came from. Six months later somebody asks why that condition is written there, and a line with no evidence behind it loses its force.

"Would Dana use this feature? There's nothing like that task on the current sheet."

Asking whether to build something by naming a person instead of arguing in the abstract.

"The persona is last year's and needs a refresh. Back then we only looked at solo users."

The product and the customers have moved since the research, so the sheet no longer matches who's out there.

"That's not the user persona, that's the person signing the check. They need a separate sheet."

Pointing out that in this product the daily user and the payer aren't the same person.

At Pagedeck, Mia writes this page and Noa reads it daily. Mia works through twelve interviews to get a draft down, and Noa rereads line 4 every time she lays out a screen. With "the invited colleague turns back at the login screen" sitting on the sheet, she ends up drawing a version where clicking the invite shows the document before asking anyone to log in.

The signal that a sheet is wrong arrives in the same place. When a usability test puts real users through real tasks and they stall somewhere the sheet didn't predict, the sheet gets fixed before the screen does.

The most common mistake is reading it as a profile card filled with demographics. Age 32, enjoys hiking, favorite brands — those lines show up in so many template images that they look like the point. But how somebody uses a collaborative document tool doesn't split by age or hobby; it splits by team size and decision authority. Two sheets that differ only in age produce the same screens. A sheet built that way never gets quoted in a meeting, and six months on nobody remembers where the file lives.

The other frequent mistake is assuming more sheets are better. Six of them taped to a wall look like thorough preparation. In practice the meeting has to relitigate which sheet to decide against, so none of them gets used. Stop at two or three and treat the rest as variations of those. The page is a device for reaching decisions rather than an accurate record, and picking between six devices takes time.