User Persona: How to Build One That Shapes Your Website

Every user persona starts life with good intentions. Then the redesign kickoff happens. Someone asks who the new homepage is really for. The CEO says investors. Sales says procurement teams. Marketing says "decision makers." Nobody mentions the persona deck from last spring.

That deck had stock photos, invented names and a favorite coffee order for each profile. It looked thorough. It settled nothing.

This is the quiet failure of most persona work. The problem is not the tool. It is what teams put inside it, and where they keep it afterward. This guide looks at user personas from the side of the people who design and build websites. You will see what belongs in a persona that actually shapes pages. You will also see how it pairs with jobs to be done, and how to stress-test your site before launch. If your brand positioning is settled, this is the logical next layer.

What does a user persona actually describe?

A user persona is a research-based archetype of a group of users who share goals, behaviors and expectations. Its job is to help a team make decisions on that group's behalf.

That definition sounds simple, yet most templates drift away from it. They ask for age, income, hobbies and a headshot. They rarely ask what the person is trying to get done.

Behavior beats biography

The Nielsen Norman Group is blunt on this point. In a 2017 piece on personas and jobs to be done, it argues that well-executed personas rest mostly on rich behavioral characteristics. Demographics, it adds, are troublesome for product and design decisions.

Its example is a power drill. A professional contractor and someone hanging a few pictures at home share the same job: making holes. They still judge the tool on different criteria. The contractor cares about durability. The homeowner cares more about price.

A website works the same way. Two visitors with identical job titles can arrive with opposite questions. The persona exists to capture that difference.

User persona, buyer persona, ICP

The vocabulary gets muddy, so it helps to separate three tools.

An ideal customer profile describes the companies worth pursuing. A buyer persona, the marketing version, describes how someone evaluates and purchases, and which messages move them. A user persona, the design version, describes how someone behaves inside the product or website.

For a brand website, the buyer and user personas overlap almost completely. The site is where evaluation actually happens. Keeping two separate decks for the same people usually means neither gets used.

Personas or jobs to be done: which does a website need?

A website needs both. The persona tells the team whose needs win when they conflict, and the job to be done tells each page what it must accomplish.

The debate has been running for a decade. It is worth understanding, because it explains why so many persona projects stall.

The case against personas

Intercom made the strongest version of the argument. In a 2016 post, Paul Adams explained that the company never used personas at all. He saw some value in empathy, but little help in generating new ideas.

His main objection was focus. Personas, he wrote, push teams toward attributes like role and age instead of motivation. Intercom built Job Stories instead, a format centered on situation, motivation and expected outcome:

• When a specific situation occurs,
• I want to accomplish something,
• So I can reach an outcome that matters to me.

The format is simple and hard to fake. It forces a team to describe a moment, not a mannequin.

Why we use both

The Nielsen Norman Group takes the opposite view: in its 2017 article, the two approaches are complementary, not rivals. Its view is that good personas already contain the jobs. Weak personas are the ones that need jobs bolted on.

Our position on website projects is more practical. A site has several audiences and dozens of pages. Jobs alone cannot tell you which audience gets the homepage hero. Personas alone cannot tell you what the pricing page must achieve.

So we pair them. Each persona carries a short list of job stories, one per moment that matters. Each key page is then assigned a primary persona and a primary job. That pairing becomes the page brief.

A typical pairing looks like this. Persona: the operations lead who will live with the tool daily. Page: the security overview. Job story: when my CFO asks whether this vendor is safe, I want to forward a single page, so I can stop being the bottleneck.

That sentence tells a designer and a copywriter more than any biography could.

Why the stakes rose in 2025 and 2026

Buyers now do most of their evaluation alone, often with AI tools in the loop. Your website increasingly has to persuade each persona without a salesperson in the room.

Decisions settle before the first call

Recent buyer research points in one direction. According to 6sense (2025 B2B Buyer Experience Report, 2025), buyers first contact a vendor 61% of the way through their buying journey, down from 69% in earlier editions. The vendor favored before that first contact wins roughly four deals out of five. By the time someone books a call, your site has usually done its work, or failed to.

AI now reads your site first

Generative AI adds a second reader. According to Gartner (Gartner Survey Finds 69% of B2B Buyers Turn to Sales Reps to Validate AI-Generated Insights, 2026), 67% of B2B buyers prefer a buying experience without sales reps. Among the 645 buyers surveyed in 2025, 45% used generative AI to research vendors and products.

In practice, an assistant may summarize your offer before a human ever lands on your homepage. A page built around one vague "visitor" gives that assistant nothing precise to repeat.

Mixed messages cost trust

Several personas reading the same site also exposes every inconsistency. According to Gartner (Gartner Sales Survey Finds 61% of B2B Buyers Prefer a Rep-Free Buying Experience, 2025), 69% of B2B buyers report inconsistencies between a vendor's website and what its sellers say. The survey covered 632 buyers in August and September 2024.

A pattern we see often in growing B2B companies goes like this. The website was written for the founder's favorite customer. The team assumes that profile still drives revenue. In reality, the deals now come from a different buyer who never finds their questions answered. Shared personas are the cheapest fix for that drift.

The persona stress test: running your pages through each user

A persona proves its worth when you use it to audit real pages. We call this the persona stress test, and it fits in a single afternoon.

How the test works

Pick your two or three key personas and your five most important pages. Then walk each persona through each page, one at a time, and answer four questions in writing.

1. Does the page answer their first question within one screen? If the opening speaks to someone else, the persona leaves before scrolling.
2. Does it show the proof they trust? Some personas trust case studies, others trust process, pricing or named clients.
3. Does it defuse their main objection? Every persona has one reason to walk away. The page should meet it before it surfaces.
4. Does it use their words? Labels and headlines written in internal jargon fail even when the content is right.

Record each answer as pass, partial or fail. A grid of personas against pages shows the weak spots at a glance. The opening screen is usually where most failures cluster, which is why the hero section deserves more debate than any other block.

What the test usually reveals

The most common finding is not a missing feature. It is a page that answers the wrong persona's question beautifully.

What we hear most often in a first briefing is "our homepage is fine, we just need more traffic." The stress test then shows the homepage speaking fluently to investors while buyers find nothing to act on. The fix is rarely more content. It is reordering what already exists.

Turning failures into a fix list

A grid full of red marks can feel overwhelming. Sort the failures by two criteria: how many personas a failure affects, and how close the page sits to a conversion.

A missing objection on the pricing page outranks a vocabulary issue on the about page. A hero that fails every persona outranks everything else. Most teams find that three or four fixes resolve the majority of red cells.

Treat each fix as a hypothesis, not a verdict. Ship it, then watch whether the behavior of that persona's segment changes in your analytics. If it does not, the persona itself may need another round of interviews.

The Techunt case: one brand, two very different readers

The Techunt project shows why a single generic visitor does not work. Techunt is a recruitment firm specialized in AI, Web3 and blockchain talent. Its challenge, as the project page describes it, was to move beyond the role of intermediary in a saturated market.

The site had to earn credibility with two groups at once. On one side, rare technical profiles. On the other, the companies shaping those emerging markets. The delivered site includes a dedicated company page and a dedicated candidate page.

The project page also states the goal plainly. The positioning had to read instantly: a recruitment partner that masters deep tech and speaks the language of the sector. Run through the stress test, that goal translates into the fourth question. A senior engineer who sees generic recruiting language leaves. The vocabulary is the proof.

The expert view

Where user personas go wrong

Persona work rarely fails because of bad research. It fails in how the personas are made, borrowed or trusted.

Mistake 1: building them in a silo

The Nielsen Norman Group lists the most common causes of persona failure in a 2018 article. Its main culprit is personas built by the UX team alone, then handed to everyone else. The result is a deck people admire once and never open again.

A familiar scene in companies preparing a redesign makes the point. The design team spends weeks on research and presents polished profiles. The instinct is to treat the presentation as the finish line. In reality, sales and support were never involved, so they keep using their own mental models. Involve them in the interviews, and the personas become shared vocabulary.

Mistake 2: borrowing personas made for something else

The same article warns against reusing personas built for another purpose. Marketing personas built for ad targeting rarely help a design team choose a navigation structure.

Free generators make the problem worse. Tools like HubSpot's Make My Persona are useful for marketing alignment. You describe your ideal customer in plain language, and AI fills fields such as age range, job title, company size and communication channels. Those fields help a campaign planner. They say little about how someone moves through a pricing page.

Mistake 3: trusting personas invented from scratch by AI

Synthetic users promise research in minutes, with no recruiting. The research behind them deserves a closer look before anyone replaces interviews.

A team led by Joon Sung Park built AI agents simulating more than a thousand real people. According to their paper on arXiv (LLM Agents Grounded in Self-Reports Enable General-Purpose Simulation of Individuals, revised 2026), agents built from two-hour interviews reached 83% of participants' own answer consistency. Agents given demographics alone reached 74%.

The lesson cuts both ways. AI can simulate people credibly, but only when fed real conversations. A persona prompted from nothing is a guess written in confident prose.

How do you build a user persona on a lean budget?

Start from the decisions your site must make, interview a handful of real users per group, and write personas around behavior and job stories. A small team can do this in a few weeks.

Start from evidence, not opinion

The UK government offers a useful discipline here. Its Service Manual asks teams to base user needs on evidence from research, not assumptions. It goes further: any opinion that does not come from users should be treated as an assumption to test.

That rule applies to every internal stakeholder, including the founder. Especially the founder.

A five-step plan for website projects

1. List the decisions first. Which offer leads the homepage? Do you show pricing? Which audience gets its own section? These questions also belong in your website project brief.
2. Draft hypotheses with the whole team. Sales, support and leadership each sketch who they think the site serves. Disagreements show where research must focus.
3. Interview five to eight people per assumed persona. Ask about their last real purchase, not their preferences. Include a few prospects you lost.
4. Cluster by behavior and write job stories. Group people by how they search and decide. Attach two or three job stories to each persona.
5. Run the stress test and keep it running. Audit your key pages, then repeat after every major release or offer change.

If your current site already has traffic, behavioral data sharpens step three. A UX audit shows where real visitors hesitate, which tells you which persona to interview first.

Keep personas in the design file

Personas die in slide decks. They live when they sit next to the work: pinned in the design file, quoted in page briefs, named in review comments. A persona nobody mentions in a design review has already been retired.

A persona earns its place in the design file

A user persona is not a portrait. It is a decision tool, and it should be judged by the decisions it changes.

Pair each persona with the jobs it needs done. Assign every key page a primary persona and a primary job. Then stress-test those pages before launch, with the people who will use them in mind.

Buyers now make up their minds alone, often with an AI assistant summarizing your site first. Pages that answer each persona's real questions, in their words, are the ones that get shortlisted. That is where personas stop being research artifacts and become part of UX design built for real outcomes.

Your most common questions about user personas