07 Nov Personas That Aren’t Fiction: Building Useful User Personas for a Website
Part 4 of Start the UX Design Process — a series on the UX principles I use in client work.
Personas have a reputation problem, and honestly, they earned it. Too many of them read like short stories about imaginary people: a name, a stock photo, a favorite coffee order, and a paragraph of invented personality — and then they sit in a document nobody opens again. A website built from that kind of persona is still built from imagination, just imagination with a name tag on it.
A useful persona is a different animal. It is not a character. It is a summary of real research, boiled down to the handful of facts a design team actually needs to remember when they are deciding what goes where. If it does not change a design decision, it does not belong in the persona.
Start with the research, not the name
The personas in this series come from the work in the last two posts: the interviews, the empathy maps, and the pain points. You do not invent a persona and then look for evidence to support it. You look at the repeated patterns in what real visitors said and did, and you group them.
That order also clears up a confusion worth naming. The short, made-up sketches from post two — the ones you imagined before any interview to sharpen your questions — are not personas. They are warm-up guesses. A persona earns its name only after real research, when a group of visitors who share the same patterns can stand behind it. A persona built before the interviews is just a guess with a name tag, and it will mislead the project exactly as confidently as a guess without one.
A persona also represents a group, not one person, and it is tied to a context: how these people behave when they are using your site, not a general biography of their lives. That is why the same person can belong to different personas on different sites — the job and the context changed, even if the person did not.
For a festival site like NC Freedom Fest, the patterns split quickly. One group is planning weeks ahead — sponsors, vendors, families marking the calendar. Another group is deciding on the day, on a phone, in a car — they need the schedule, parking, and what is happening right now. Those are not two personalities. They are two jobs, two contexts, and two levels of urgency, and a site that treats them as one “attendee” will serve both badly.
For First Baptist Church of Goldsboro, the split is a first-time guest versus a long-time member. The guest wants to know what Sunday looks like, where their kids go, and whether they will feel out of place. The member wants the next event, the sign-up, and the announcement they missed. Same site, different anxieties, different first clicks. For United Way of Wayne County, the split is a first-time donor versus a first-time volunteer — one needs to trust where the money goes, the other needs to know what showing up actually involves. Different reassurance, different next step.
Notice that none of those personas needed a fictional name or a hobby to be useful. What made them useful was the job, the context, and the worry.
What belongs in a useful persona
Keep it to one page, and keep it to what changes design. I use five fields, and I am strict about them.
First, who they are in one line, defined by their job — not their demographics. “First-time guest deciding whether to visit on Sunday” beats “35-year-old female, likes brunch” for every design decision you will ever make.
Second, their goal on your site, in their words. “Find out what Sunday looks like and whether my kids are welcome.” If you cannot write the goal in words a visitor would actually use, you have not listened enough yet.
Third, their context. Phone or desktop? In a hurry or planning ahead? First visit or fiftieth? Alone or with family? Context decides more design than taste ever will — a phone user in a car needs a different page than a desktop user planning a month out.
Fourth, their top pain points, taken straight from the research. The exact stuck moments from the last post, attached to this person. This is what keeps the persona honest: every pain point should trace back to something a real visitor said or did.
Fifth, what “done” looks like for them. The action that means the site worked: they found the service time, they registered, they donated, they called. If you cannot name the success action, the persona is decoration.
That is it. No favorite color, no invented backstory, no stock photo. If a detail does not help somebody decide what goes on a page, it is clutter, and clutter in a persona is how a useful tool turns into fiction.
How many personas do you need?
For most small business and nonprofit sites, two or three. One primary — the visitor your business most needs to serve well — and one or two secondary. More than that, and the site tries to be everything to everybody again, which is the exact problem personas exist to solve.
The primary persona gets the clearest path on the homepage. The secondary personas get clear paths too, just not the top spot. Everybody else — the rare visitor with an unusual request — gets a working contact route, not a whole section. That is not exclusion. It is prioritization, and prioritization is what makes a homepage readable instead of overwhelming.
How personas actually get used
A persona earns its keep in the room where decisions happen. When somebody proposes a new section, a new button, or a new page, the question is not “do we like it?” It is “does it help the first-time guest finish her job, or does it get in her way?” When the team disagrees about a headline, the persona breaks the tie: which version answers the visitor’s actual worry?
That is also how you keep personas from going stale. Before you finalize them, compare them against what your team assumed about visitors before the research — and say out loud where the data confirmed those assumptions and where it contradicted them. Everybody on the project needs to understand the personas, not just the person who wrote them, or the team will quietly design for the old assumptions anyway. Then revisit them when the research changes — after a new event, a new service, a season of visitor questions. A persona built from last year’s interviews and never checked again quietly becomes fiction, too. The discipline is not writing personas once. It is keeping them tied to real people.
Used that way, personas are not a creative writing exercise. They are a memory aid for the whole project: a promise to design for the people you actually listened to, not the people you imagined. The next post turns those personas into something even more practical — user stories, one-sentence statements of what each person needs the site to do for them.
Want a site built around your real visitors, not guesses? I build and redesign websites for small businesses, non-profits, and churches across Eastern NC. Get a free consultation or see recent work.
Previous in this series: Finding Real Pain Points · Next: User Stories: Writing “As a [User], I Want…” for Real Website Goals
This article is my own take, in my own words, on UX principles I use in client work. It is not affiliated with or endorsed by Google or Coursera.