June 17, 2026
6 min read
Writing Personas That Actually Influence Design Decisions
Blue Monkey Makes
Most persona documents have the same trajectory. They get created during discovery, presented in a slide deck, acknowledged with polite nods, and never referenced again. The project moves into design, then development, and the personas sit in a shared folder gathering dust.
This isn't because the team doesn't care about users. It's because the personas were built for presentation, not for decision-making. They describe people in broad strokes — demographics, a stock photo, maybe a quote that reads like it was written by a copywriter — but they don't give a designer or developer anything concrete to evaluate against.
We've found that the personas that actually influence design decisions share a specific quality: they're specific enough to test pages against. Not "Emily is a 34-year-old professional who values quality." More like "Emily needs to see pricing and availability before she'll book, and right now the site asks her to call."
The test for a useful persona
Here's a simple litmus test. Take any page on the site and ask: does this serve Persona X's need at this stage of their journey? If the persona document doesn't give enough information to answer that question, it's too abstract to be useful.
A designer should be able to look at a landing page and say "this answers Persona A's core objection about pricing transparency" or "this doesn't give Persona B a reason to book online instead of calling." That level of specificity is what separates a reference document from a decoration.
Specificity matters more than creativity
There's a tendency to make personas feel like character sketches. A name, an age, a backstory, hobbies, a day-in-the-life narrative. Some of that context is fine — just enough to picture a real person. But the useful parts of a persona are almost always the structured fields, not the prose.
The format we've settled on after refining it across multiple discovery engagements:
- Who they are — role, age range, income bracket, location. Two to three sentences. Just enough to picture them, not a creative writing exercise.
- Motivations — what specifically brings them to the site. Not "wants a good experience" but "planning a weekend trip and looking for something to book in advance."
- Pain points — what's frustrating about the current experience. These come from real observations, not assumptions.
- Decision drivers — the factors that influence their buying decision, in priority order. Price sensitivity, social proof, convenience, exclusivity — whatever actually matters most to this person.
- Objections — the questions or hesitations they have at decision moments. "Is this worth the price?" or "Can I bring kids?" or "What if the weather is bad?"
- Entry points — how they arrive. Google search, Instagram, a friend's recommendation, a travel blog. This shapes which pages need to work hardest.
- Key pages they need — mapped against what currently exists. This is where the document becomes actionable.
- Desired conversions — primary, secondary, and tertiary. Not every visitor is ready to buy. What's the next-best action?
Most of these fields are straightforward. But three of them do more work than the others.
Pain points, objections, and decision drivers carry the weight
Demographics set the scene. Motivations explain why someone shows up. But pain points, objections, and decision drivers are what actually inform design choices.
Pain points reveal what the current site is getting wrong — or at least what it's not addressing. When a persona's pain point is "I can't find pricing without calling," that's a direct input into information architecture. When it's "the booking process requires too many steps," that's a direct input into interaction design.
Objections are the questions a visitor has right before they decide to convert or leave. These are gold for copywriting and page structure. If a persona's main objection is "I'm not sure this is worth the price," the page needs to build value before presenting the number. If the objection is "I don't know what to expect," the page needs imagery, testimonials, or a walkthrough.
Decision drivers tell the team what to emphasize and what to subordinate. If one persona prioritizes convenience and another prioritizes exclusivity, the same product page might need to serve both — or the site might need different entry paths for each. Knowing the priority order prevents the common mistake of treating every feature as equally important.
The key pages table is where personas become actionable
Of everything in the persona document, the most consistently useful element is the key pages table. This is a simple mapping: for each persona, what pages do they need, what does the site currently offer, and what's the gap?
Here's an example, anonymized from a recent discovery engagement for a small experiential business:
| Page need | Current state | Gap |
|---|---|---|
| Booking with dates, times, and pricing | Generic contact form | No self-service booking. Visitor must call or email. |
| Photo gallery of the experience | A few lifestyle shots on the homepage | No dedicated gallery. Nothing showing what to actually expect. |
| Private events page with group pricing | Brief mention in a FAQ | No dedicated page. No way to request a quote online. |
| Reviews or testimonials | None on site | Social proof exists on Google, but isn't surfaced on the site. |
That table takes about ten minutes to build for each persona. And it immediately surfaces the gaps between what the site provides and what people actually need. No interpretation required. A designer, a developer, or a business owner can look at it and understand exactly what's missing.
This is also where the conversation shifts from "what should the site look like" to "what should the site do." The table doesn't prescribe a visual direction — it defines functional requirements grounded in real user needs.
The persona coverage matrix — a quick health check
Once the individual personas are documented, it's worth building a simple coverage matrix. This is a grid that answers four questions for each persona:
| Weekend tourist | Event planner | Local regular | |
|---|---|---|---|
| Can find what they need | Partial — no pricing page | No — no events page | Yes — familiar with the site |
| Can convert online | No — must call to book | No — must email for quotes | No — same booking gap |
| Gets follow-up after visiting | No — no email capture | No — no CRM integration | No |
| Has a reason to return to the site | No — no seasonal content | No — no event calendar | No — nothing changes |
This matrix is intentionally blunt. It compresses a lot of analysis into a format that anyone on the team can read in thirty seconds. And it tends to reveal patterns that aren't visible when looking at personas individually.
In the example above, the pattern is clear: the site has partial content coverage but almost no conversion infrastructure and no retention mechanism. Every persona hits the same walls. That's a finding that shapes the entire project scope, not just individual page designs.
A persona is working when it becomes invisible
The best sign that personas are doing their job is when the team stops referring to the document and starts referring to the people. "Would the event planner find this?" becomes a natural question during design review. "This page doesn't answer the tourist's pricing objection" becomes a standard critique.
At that point, the persona has moved from a deliverable into a shared mental model. It's no longer a document someone created during discovery — it's a lens the team uses to evaluate every page, every flow, every piece of copy.
That only happens when the persona is specific enough to be useful and structured enough to be referenced quickly. The fields matter. The key pages table matters. The coverage matrix matters. The stock photo and the clever name — those are optional.
