User Persona Development: A Research-Based Process

Researcher interviewing a small-business customer

Marketing
22.10.2026
Hunter Blake

User persona development is the practice of turning research on real users into a small set of fictional but realistic profiles that a product, design or marketing team can use to make decisions. A persona is only as good as the evidence behind it. A profile written from assumptions, with a stock photo and a name, is decoration. A profile built from interviews, behavioral data and a clear segmentation logic is a working tool.

This guide sets out a six-step process, the data each step needs, the adjustments required for B2B products, and the errors that most often make personas unusable.

Solution4guru

Build a Website Around Real Users

Solution4Guru provides UI/UX design and web development to help businesses shape digital experiences around their customers.

Explore digital solutions

TL;DR

A persona is a fictional, yet realistic, description of a typical or target user that supports empathy, prioritization and design decisions.
Research comes first: interviews, surveys, analytics and support or sales records. Segment the findings, then write the profiles.
Personas have faced criticism for weak scientific grounding. Systematic coding of field data and an explicit link from each attribute to evidence address that.
In B2B, a persona must reflect the buying situation and the role in a committee, not just a job title.
Treat personas as living documents: review them when the product, market or data changes.

What a user persona is, and what it is not
The evidence problem: why many personas fail
A six-step process for user persona development
Adapting persona development for B2B
Common mistakes in persona development
Putting personas to work
Our perspective
Turning personas into a working website and CRM
FAQ
Sources

What a user persona is, and what it is not

A persona represents a segment of users, not an individual and not an average. The Nielsen Norman Group describes its purpose as promoting empathy, making target users memorable, prioritizing features and informing design decisions.

Three distinctions help keep the scope clear:

Persona vs. market segment. A segment is a statistical group. A persona describes the goals, behaviors and frustrations that characterize it, in a form a team can picture.
Persona vs. demographic profile. Age, location and income describe who someone is. They rarely explain why that person uses a product in a particular way. Behavior and context do.
Persona vs. job to be done. Personas describe who the user is and what they need. A job to be done describes the situation and progress the user is seeking. Many teams use both.

A systematic review of persona use cases in design notes that personas are credited with building empathy and improving communication within teams. Those benefits depend on the persona being credible to the people who use it.

The evidence problem: why many personas fail

Personas are widely used and persistently questioned. White and Frank, writing in the Journal of Usability Studies, point out that personas have been criticized on scientific grounds. They propose grounded theory, a systematic approach to reducing and displaying field data, as a way to strengthen the method.

The practical lesson is simple. Every attribute in a persona should trace back to something observed: a quote, a behavior in the analytics, a pattern across several interviews. If an attribute cannot be traced, it is a guess, and it should either be removed or labeled as a hypothesis.

A study on constructing validated personas for medical equipment design makes a similar point from a regulated field. Its aim was to demonstrate a rigorous, grounded process, and it reports that checking persona content produced disparate, possibly incommensurable, results. Even careful work can yield conflicting findings, so the process must include a check.

A six-step process for user persona development

Most published methods, from design agencies to academic reviews, converge on the same sequence. A survey of 15 years of data-driven persona development describes the common pattern as three stages: collecting user data, segmenting or clustering it, and synthesizing the attributes into a profile. The steps below expand that into a workflow a small team can follow.

Step 1: Define the decision the personas must support

Before collecting anything, write down what the personas will be used for. A redesign of a checkout flow needs different persona content than a content strategy or a CRM rollout. The decision determines the scope: how many personas, how much detail and which behaviors to study.

A useful test: name two or three choices the team will make differently once the personas exist. If none come to mind, the project is not ready.

Step 2: Collect qualitative data

Interviews and observation reveal motivations that numbers cannot. Aim for real users or customers, not internal proxies. For each interview, capture:

The context in which the product is used (device, location, time pressure, other people involved)
The goals the user was trying to achieve, in their own words
Workarounds, frustrations and abandoned attempts
How the user found, evaluated and chose the product or its alternatives

One practitioner guide for B2B suggests 8 to 15 interviews per persona type. That is a rule of thumb from a single publisher, not a standard, so treat it as a starting range. Stop when new interviews stop producing new patterns.

Step 3: Add quantitative data

Quantitative sources test whether the patterns from interviews hold across a larger population. Typical sources include:

Web and product analytics (feature usage, paths, drop-off points)
Survey responses with closed questions
CRM records: industry, company size, deal stage, time to close
Support tickets and sales call notes

The literature review cited above cautions that organizations should realistically assess their internal data readiness before adopting automated, quantitative persona methods. If tracking is incomplete or the CRM fields are inconsistent, clean the data first or lean on qualitative work.

Step 4: Segment the findings

Group users by what they do and need, not by demographic convenience. Build an affinity map: write each observation on a note, cluster similar ones, and label the clusters. Two users of identical age and job title can belong to different segments if their goals differ. Two users of different ages can belong to the same one.

For most products, three to five personas are enough. If the number grows beyond that, the segmentation is probably too granular to guide decisions. Rank the segments by importance to the business and designate a primary persona.

Step 5: Write the persona profiles

Keep each profile to one page. Include only what a team member will use:

Element	What to include	What to avoid
Name and role	A representative label, a one-line description	Stereotyped photos and invented hobbies
Goals	The outcomes the user wants, ranked	Generic aims such as “be more efficient”
Behaviors	How the user currently works, tools used, frequency	Assumed habits with no source
Pain points	Specific obstacles with an example quote	Vague complaints
Context	Environment, devices, constraints, who influences them	Irrelevant demographics
Evidence	Number of interviews and data sources behind the profile	Unsourced claims

The evidence row is the most commonly omitted and the most valuable. It tells a stakeholder how much weight the persona can bear.

Test the draft profiles against people who were not part of the research: ask a few users whether they recognize themselves, and ask sales or support staff whether the profiles match the customers they meet. Then put the personas where decisions are made: in design briefs, backlog refinement, campaign planning and onboarding of new staff.

Set a review date. Personas drift as products, competitors and customer expectations change.

Adapting persona development for B2B

B2B personas carry an additional layer of complexity: one purchase involves several people with different priorities. Researchers working on B2B SaaS user personas observe that persona research has been done mostly on consumer products, often by interviews, surveys or clickstream data alone, which is why the B2B case deserves its own method.

Three adjustments make a practical difference.

Separate users, buyers and influencers. The person who uses a platform daily may not sign the contract. Create profiles for each role that shapes the outcome, and show how they interact.

User buyer and influencer linked to one outcome

Add firmographic and situational context. Industry, company size and revenue shape needs. Forrester’s buyer insights research lists firmographics alongside demographics as inputs for segmenting buyers by persona, industry, region and company size.

Map personas to buying situations. Gartner’s guidance on aligning buyer personas with how buyers actually make decisions observes that personas are often used to find sales-ready buyers without accounting for behavior during the sales cycle. A persona for a first-time purchase differs from one for a renewal or an expansion.

For teams building buyer personas for demand generation, Forrester also publishes a B2B buyer persona interview guide that argues for a standardized, diagnostic approach to gathering buyer data.

How AI is changing the buyer side

Forrester’s 2026 buyer research reports that AI is reshaping B2B buying and that go-to-market strategies need to move beyond static, role-based archetypes. Personas should now include how buyers research, evaluate and use AI in their decisions, often long before they contact a vendor. In practice, add questions to interviews about which tools and sources a buyer consults first, and whether AI assistants appear in that process.

Common mistakes in persona development

Starting with a template. Templates are useful for layout, not for content. Filling in boxes without research produces fiction.
Too many personas. Teams cannot hold ten profiles in mind. Prioritize.
Demographics as the organizing principle. Behavior and goals predict product use better than age or gender.
No stated evidence. A persona with no sample size or source invites dismissal.
One-off projects. A persona that is never revisited ages quickly.
No connection to action. If personas do not appear in briefs, roadmaps and campaign plans, they will not change decisions.
Ignoring inclusivity. The review of 77 articles in the survey cited earlier notes research gaps in standardization and inclusivity. Recruit participants across abilities, ages and contexts that match the real user base.

Putting personas to work

Once validated, personas inform several workstreams:

Interface and information design. Personas set priorities for navigation, content and feature order. The distinction between visual interface and overall experience is covered in our comparison of UX and UI.
Marketing and content. Personas determine which questions content should answer and which channels deserve budget.
CRM and sales processes. Persona attributes can become CRM properties, used for lead routing, segmentation and messaging. Linking those records to site behavior is discussed in our guide to integrating CRM with your website and SEO.
Vendor selection. Briefing an outside team is far easier with personas in hand. If that applies, see how to choose a digital customer experience agency.

Our perspective

We build websites, CRM implementations and automation for businesses, and personas are rarely the problem we are asked to solve. The problem is usually downstream: a site that serves nobody in particular, or a CRM whose fields do not reflect how customers actually buy.

Our experience is that personas pay off when they are tied to a system. A persona that lives in a slide deck is forgotten within a quarter. A persona that becomes a set of CRM properties, a content map and a navigation structure keeps shaping decisions. That is why we approach projects strategy first, tailored to a client’s business model and workflows rather than a template, and why we favor ongoing optimization over a one-time setup.

We also hold to a simple rule: a persona should be small enough to challenge. If a profile cannot tell a team that a planned feature is unnecessary, it is too vague. Mark which attributes are verified and which are hypotheses, and revisit them as data arrives.

— Vadim

Turning personas into a working website and CRM

If your research is complete and the next question is implementation, our team can translate personas into site architecture, UI/UX design, CRM configuration and automation. See our full range of digital services, or our HubSpot implementation and integration services if your customer data lives, or should live, in a CRM. A free consultation is available to scope what your personas mean for your digital roadmap.

FAQ

What is a user persona in development?

It is a fictional but realistic profile representing a segment of users, built from research so that designers, developers and marketers can make decisions with a specific person in mind. It records goals, behaviors, frustrations and context, not just demographics. In software projects it often feeds requirements, prioritization and interface decisions.

How many personas does a product need?

There is no fixed number, but three to five covers most products. The right count depends on how many distinct behavioral segments the research reveals and how many the team can realistically design for. Designate a primary persona so conflicts between needs can be resolved.

How many interviews are enough?

Stop when new interviews no longer reveal new patterns. One B2B practitioner guide suggests 8 to 15 interviews per persona type as a starting range. Combine interviews with analytics or survey data to confirm patterns at scale.

How often should personas be updated?

Review them whenever the product, market or customer base changes materially, and on a fixed schedule, such as annually, as a minimum. Check them against fresh CRM and analytics data and against what sales and support teams report. Retire or merge profiles that no longer drive decisions.