A Practical Guide to User Archetypes

The worst persona detail is not the stock photograph. It is the detail that sounds specific but changes no decision.

A name, age, job title, and preferred coffee can make a profile memorable. They can also make an invented character feel more certain than the evidence deserves.

A useful user archetype works differently. It describes a recurring pattern of behaviour, need, context, or constraint that should change how a team designs or prioritises the product.

If the archetype cannot alter a decision, it is decoration.

Begin with a decision the team cannot make

Do not start by asking how many archetypes the product needs. Start with a real tension.

• Should the default workflow favour occasional or intensive use?
• Do different users need different levels of control?
• Is one onboarding path serving people with incompatible starting knowledge?
• Which group is harmed by the complexity that helps another?
• Are adoption problems caused by motivation, capability, access, or context?

The decision determines which differences matter.

For a navigation redesign, frequency and familiarity may be important. For a data-export feature, responsibility, risk, and downstream workflow may matter more.

An archetype is therefore not a complete portrait of a person. It is a deliberately partial model built for a defined product purpose.

This work belongs in Discovery & Validation, where a model is valuable only to the extent that it makes uncertainty and evidence easier to act on.

Archetypes, personas, segments, and jobs are not interchangeable

Teams use these words inconsistently. A practical distinction can prevent the method from becoming muddled.

Segment

A segment groups people or organisations by characteristics relevant to a market or product choice. It may be measurable in a population and useful for targeting, sizing, or comparing outcomes.

Job or user need

A job describes progress someone is trying to make in a situation. Different people may share the same job, and one person may have several jobs.

Persona

A persona is a research-based representation of a user group. It often combines goals, behaviour, context, and a narrative form that helps a team remember the group.

Archetype

An archetype highlights a recurring pattern that affects product behaviour or design. It can be lighter than a persona and need not pretend to represent an entire life or identity.

The labels matter less than the discipline. Name the unit, evidence, intended decision, and limits of the model.

Do not use a behavioural archetype as if it were a market-size estimate. Do not treat a job as a permanent type of person.

Find behavioural patterns, then investigate why

Product data can reveal that people behave differently. It cannot, on its own, explain why.

Begin with evidence relevant to the decision:

• frequency and sequence of use;
• features or workflows used together;
• tasks completed and abandoned;
• support and service interactions;
• device, access, or environmental constraints;
• role in a wider workflow;
• experience level and change over time.

Then use qualitative research to understand context, motivation, workarounds, and meaning.

Two groups may have identical low usage for different reasons. One has completed a rare task successfully. Another cannot reach value. Labelling both “occasional users” would hide the product decision.

The reverse is also true. People with different job titles may follow the same workflow for the same reason. Separating them by title could create differences the product does not need to serve.

GOV.UK’s guidance on learning about users and their needs emphasises behaviour and the tasks people are trying to complete.

It also asks teams to understand all kinds of users rather than designing around a supposedly typical user.

Design Principles That Improve User Interviews can help collect the qualitative evidence without turning the conversation into a feature survey.

Better Products Start with Qualitative Research explains how to connect those observations to a product decision without overstating what a small sample can prove.

Build the smallest useful set

There is no universal correct number of archetypes.

Create a separate archetype only when a pattern is supported by evidence and produces a meaningful difference in the decision. Merge groups when the distinction changes language but not action.

A useful set should be:

• distinct: each archetype exposes a different product implication;
• recognisable: teams can identify the pattern in real evidence;
• bounded: the model states what it covers and what it does not;
• collectively useful: important users are not excluded merely because they are quieter;
• small enough to use: people can compare the trade-offs without consulting a taxonomy.

Do not force every user into exactly one permanent box. A person may move between archetypes as their task, responsibility, access, or expertise changes.

That movement can itself be a valuable product insight. The team may need to support a transition rather than design separate experiences forever.

Create a one-page evidence-backed archetype

A practical archetype document might contain:

1. Pattern name: descriptive, neutral, and based on behaviour;
2. Decision purpose: which choices the archetype should inform;
3. Situation: when and why the pattern appears;
4. Behaviour: what people do, including workarounds;
5. Need or desired progress: what a successful result means;
6. Constraints: access, time, knowledge, risk, or environment;
7. Product implications: decisions that should differ;
8. Evidence: research and data supporting the pattern;
9. Counterevidence: cases that do not fit neatly;
10. Review trigger: what would make the team revisit it.

Use direct research excerpts sparingly and with appropriate consent. A quote can make a need vivid, but one person’s phrasing should not become proof of a population-wide pattern.

Include an evidence date. An archetype derived before a major product or market change may no longer explain current behaviour.

The Microsoft Research paper Personas: Practice and Theory describes persona work as drawing on several data sources.

It also connects the artefacts to product-development activity.

The useful principle is not to make the profile richer for its own sake. It is to make the evidence and product implication traceable.

Use archetypes to expose trade-offs

Archetypes earn their maintenance cost inside real decisions.

For an initiative, ask:

• Which archetype experiences the problem?
• In what context and with what evidence?
• Which group benefits from this response?
• Does the response add cost or harm for another group?
• Are we choosing a default, a variation, or a separate workflow?
• Which group are we deliberately not optimising for now?

This is more useful than adding an “Archetype: Power User” label to a feature brief. The label should reveal a trade-off, not provide ceremonial evidence of user focus.

Archetypes can inform:

• default settings and progressive disclosure;
• information architecture and navigation;
• onboarding paths;
• permission and control models;
• performance and accessibility requirements;
• support and service design;
• prioritisation and research recruitment.

They should not automatically produce personalised experiences. Sometimes one inclusive design serves several patterns better than branching the product.

A hypothetical example

Imagine a planning tool with people who all create project updates. The example below is invented to show the method.

Usage data suggests two patterns. One group creates updates occasionally, usually after a reminder. Another prepares several updates before a weekly portfolio review.

Interviews reveal that frequency is not the most important difference.

The occasional group works from memory and needs confidence that required information is complete. The intensive group coordinates inputs from several people and needs to see what changed since the previous review.

The team names the patterns single-context reporters and multi-source coordinators. The names describe the workflow, not seniority or personality.

The first archetype suggests a clear completion state and prompts for missing information. The second suggests change tracking, ownership, and review across several updates.

A dense dashboard for “power users” would have been the wrong abstraction. The evidence points to coordination, not expertise.

The team also records a limitation: all current participants belong to established customers. The archetypes should not yet guide first-time onboarding.

Avoid fabricated precision and stereotypes

An archetype can harm a decision when its specificity exceeds the evidence.

Invented biography

Personal details are added to make the character feel human, even though they were not observed and have no product implication.

Keep only relevant, supported context. Humanity comes from understanding real situations, not from fictional hobbies.

Demographic shortcut

Age, location, disability, or job title is used as a proxy for behaviour without evidence.

Some characteristics do affect access and experience. Research the mechanism rather than relying on a stereotype.

Technical pseudo-precision

The document claims exact performance tolerance or device conditions without measurement.

If a technical constraint matters, test it and cite the evidence. Do not translate “busy” into an invented two-second abandonment threshold.

Average-user fiction

The team blends conflicting needs into one safe profile. Nobody strongly resembles it, and every product implication becomes generic.

Preserve differences that matter. Do not average away the trade-off the model exists to reveal.

Visibility bias

The loudest customers or most active users become the only archetypes. Non-users, people who failed, and people affected indirectly disappear.

Actively look for missing patterns. The ONS user-persona guidance provides a public example of describing different user tasks and levels of familiarity with data.

Review, split, merge, or retire

Do not schedule a quarterly review simply because “quarterly” sounds responsible. Review when evidence or a decision demands it.

Useful triggers include:

• a new market or workflow;
• a major product or pricing change;
• behaviour that no longer fits the model;
• repeated exceptions in product decisions;
• an archetype that nobody references;
• a distinction that no longer changes action.

Split an archetype when one label hides two materially different needs. Merge archetypes when the difference no longer produces a product consequence. Retire one when the behaviour disappears or falls outside strategy.

Keep a short change log: what changed, which evidence caused it, and which decisions may need review.

Ownership should sit with a team that can connect research, product data, and decisions. The artefact should remain shared; no specialist can keep it useful alone.

Working artefact: the Archetype Evidence Card

Create one card per meaningful pattern. Leave biography out unless a personal characteristic directly changes access, behaviour, risk, or the product decision.

Card field	Evidence to preserve
Decision served	The exact trade-off this archetype should improve
Observable pattern	Repeated behaviour, need, context, or constraint
Conditions	When the pattern appears and when it does not
Supporting evidence	Research sessions, product data, service evidence, and dates
Counterevidence	People or situations that do not fit the current explanation
Product consequence	Default, workflow, control, content, or priority that should differ
Sample boundary	Who was missing, overrepresented, or outside scope
Review trigger	New evidence or decision that could split, merge, or retire the card

The counterevidence and sample-boundary rows stop a memorable profile from becoming an overconfident claim. The product-consequence row proves whether the distinction deserves to exist.

A practical archetype checklist

Before using an archetype, ask:

• Which decision is it meant to improve?
• Is the pattern based on observed behaviour, need, or context?
• Have we investigated why the behaviour occurs?
• Does the distinction change a product choice?
• Are data sources, sample limits, and dates visible?
• Have we looked beyond current and vocal users?
• Are demographic details relevant and supported?
• Does the profile avoid fabricated biography and false precision?
• Can people move between archetypes?
• Do we know when to split, merge, review, or retire it?

The point is not to capture everything about a user. It is to preserve the differences a product decision must not ignore.

A good archetype makes a trade-off clearer. A great one also reminds the team where its understanding is incomplete.

Sources

• Personas: Practice and Theory — Microsoft Research
• Start by learning user needs — GOV.UK Service Manual
• Understanding your users: User personas — Office for National Statistics

Read next

Design Principles That Improve User Interviews shows how to gather evidence about behaviour and context without asking people to design the product for you.

• B2B Product Discovery When Buyers and Users Disagree