NNGroup Personas (Essence / Three Types / Scope & Hierarchy / Creation / Comparison with JTBD, Archetypes, Segments / Application / Maintenance / 5 Major Failures)

A Persona = compressing "a large group of statistically defined users" into "a small number of fictional individuals that the team can remember and empathize with". It is not the kind of demographic label used by marketing departments (35-year-old woman, monthly income 20,000 yuan), but an intrinsic motivation model that answers "why does this person use us, what do they want to accomplish, and where are they stuck".

The core value is simply this: shifting design discussions from "I think users will…" (self-referential) to "Mary needs to complete the task quickly" (aligned to a specific person). The following is divided into eight sections: Essence → Types → Scope → Creation → Comparison with other tools → Three usage methods → Maintenance → Failures.

1. Essence: Personas depict the "inner self", not "behavioral data"

Dimension	Persona	Easily confused concepts
What it depicts	Inner: motivations, expectations, attitudes, key tasks to complete, ways of thinking when facing complex processes	Customer segmentation / analytical data depicts External: page visits, devices, frequency, geography
Data source	Qualitative research (interviews / field studies / usability testing) — because the "inner self" cannot be read out, it can only be learned through conversation	Large-scale behavioral data from analytics tools
Form	A fictional but realistic individual fictional but realistic individual	with a name, a photo, and a tagline; a pile of percentages and pie charts

Core mindset: A persona is "fictional, but must be as specific as a real person". Give it a name, photo, a life tagline, usage scenarios (active choice or forced use? Frequency? Device?), goals and concerns (speed or accuracy?), and a quote that reflects its attitude.Every piece of information must be relevant to design — don't write details like "likes drinking beer" unless they are truly related to the product.

Why it works: The human brain cannot remember "the statistical characteristics of user group A", but it can remember "Detailed Debbie needs to book a reasonably priced, well-reviewed hotel for a business trip". Concretization → memorability → the team can repeatedly reference it in every review, reducing self-referential design that treats oneself as the user.

2. Three types: classified by "data source", qualitative is the optimal choice for most teams

Type	Data source	How to create	Pros	Cons	Suitable for
Proto / Lightweight	The team's existing assumptions, no new research	2–4 hour workshop, each person draws 2–5 drafts, discuss and merge into 3–6 personas	Fast, cheap, makes implicit assumptions explicit, serves as a starting point for research	No research support, may amplify wrong assumptions; if the team finds it useless, they may reject the entire UX effort by association	Limited resources / low UX maturity / just getting started
Qualitative	5–30 person small-sample qualitative research	Interviews / usability testing / field studies → identify patterns of shared goals and pain points → generalize into personas	Based on real data, deep insights, moderate time investment	Cannot quantify the proportion of each persona, may miss niche groups	Best choice for most teams
Statistical	Qualitative foundation + large-sample survey (≥100, ideally 500+)	First define themes qualitatively → large survey → cluster analysis (latent class / factor / K-means)	Knows the proportion of each persona (facilitates design tradeoffs), eliminates outlier user bias	Expensive, requires statistical expertise, must complete qualitative work first, statistical clusters may lack design meaning	Sufficient resources / need precise distribution for tradeoffs

Decision mindset: Don't pursue the statistical type right from the start.First use the lightweight type to align the team, then upgrade to the qualitative type to get real insights; it is only worth spending money on the statistical type when "what proportion each persona accounts for" will directly change design tradeoffs.

3. Scope and hierarchy: Personas cannot be "one-size-fits-all"

A counterexample NNGroup repeatedly emphasizes: a financial company wanted to use "one set of personas" to cover all businesses of retirement savings + banking + funds — this is wrong.

Scope	Data characteristics	Suitable for	Not suitable for
Broad	High-level,shallow	Strategic decisions (marketing tone, educational content direction)	Specific design (what information should be displayed on the investment interface)
Narrow	Specific context,deep	Specific product / scenario design (what to highlight on the mobile banking app homepage)	Enterprise-level high-level decisions

Core rule:The narrower the scope, the deeper the understanding of that context; the broader the scope, the less information available for fine-grained design. The two are a tradeoff.

Hierarchical solution: Personas should be layered according to organizational structure — organizational level → business line level → product level → project level, with each level built separately for its own decision context. The ideal state is a one-to-one match between personas and design challenges. The same real person will present different faces at different levels: at the company level they are "Dan the frugal saver", while in the mobile banking app they may be "Quentin who distrusts mobile transactions".

4. Personas vs the other three user tools (clarify boundaries, can be combined)

The most frequently asked question is "Should I use personas or X?" — one table makes it clear.They are not mutually exclusive; they are different levels of abstraction and can be used in combination.

Tool	What it is	Strengths	Weaknesses	Relationship with personas
Archetypes	Abstract user type labels (e.g., "reliability optimizer"),retaining only behaviors/attitudes, no names or photos	Concise; an alternative when the team is averse to "personas" (avoids the side effects of personification)	Lacks humanized details, difficult to evoke emotional empathy	Two expressions of the same set of insights: archetypes are used for behavioral pattern analysis, personas add specific context. You can start with archetypes and gradually transition to personas
JTBD (Jobs To Be Done)	Users "hire" a product to complete a certain "job/outcome" (e.g., "I need navigation" rather than "I need to print directions")	Outcome-centered, challenges existing solutions, stimulates innovation	Lacks user background and segmentation, design may not be personalized enough	Complementary:First use JTBD to define core needs, then use personas to add details and empathy. Personas can absorb JTBD's functional + emotional success criteria
Customer Segments	External behavior groupings based on analytical data analytical data(device / frequency / geography)	Quantitative, shows the full picture, reveals proportions	Cannot reveal inner motivations and attitudes	Complementary: segments provide the "full picture of external behavior", personas provide "inner motivations". Combining them gives the complete picture (see Section 5 "Segment Analytics")

5. Three ways to actually "use" personas

The biggest failure of personas is "building them but not using them" (see Section 8). These are the most practical application methods:

1. Prioritize Features Matrix — a quantitative method for ranking requirements using personas:

Rows = all features / user stories, columns = each persona, assign priority weights to each persona (primary 50% / secondary 30% / tertiary 20%, total 100%)
Score each feature for each persona:+2 至关重要 / +1 有正面但非关键 / 0 无影响 / −1 负面
Weighted total score = Σ(score × weight of that persona), rank by total score
Why: Turns "whose needs are more important" from guesswork into discussable numbers; can also be reused for content idea evaluation and design solution comparison

2. Scenario Mapping Workshop — using personas for design ideation:

One scenario = five elements: Actor (use a specific persona) → Motivator → Intention → Action → Resolution
Workshop: 4–6 cross-functional participants + facilitator + 1–2 high-priority personas' key task scenarios + whiteboard and sticky notes. Split the scenario into small segments and post them horizontally on the wall; different colored sticky notes = ideas / problems / considerations, brainstorm segment by segment
Key discipline: Scenarios must stay high-level and not touch on specific design solutions(don't prematurely write "use a dropdown menu"), otherwise it will limit creativity rather than stimulate it. Then converge by finding commonalities across solutions for multiple personas

3. Segment Analytics by Persona — using personas to read data in reverse:

Looking at overall site data broadly will mask group differences. Define segmentation rules by persona (e.g., David = "return visit + email source + mobile access"), making each segment cover 7–10% of the total population
Classic case: A page bounce rate of 65% shows no obvious problem → split by persona: loyal users bounce at 83% (normal, they only view specific content) vs search visitors at 37.5% (low, but the content does not match their expectations) → identified that "content matching for search visitors needs to be changed"
Dual benefit: both optimizes design and reverse-verifies whether the personas are still accurate

6. Maintenance: Personas are "living documents", not final drafts

Question	NNGroup conclusion
When to update	In response to significant changes in the business environment or user groups(business pivot, competitors launching new features that change expectations, demographic shifts, analytics/testing/customer service data deviating from personas). Small feature changes do not require updates;don't update for the sake of updating
How often to update	There is no fixed schedule. Survey of 156 companies: 46% update every 1–4 years, 28% quarterly or more frequently, 26% every 5+ years or never
Is updating worth it	Frequency is positively correlated with impact: the quarterly update group self-reported an impact score of 5.5/7, the 1–4 year group 4.5, and the 5+ year group only 3.9
Side effects of updating	Updating too frequently / too drastically will make it hard for the team to remember and internalize personas, reducing acceptance instead — balance must be found between stability and flexibility

Easily overlooked design detail: format is a signal.

Using hard-to-edit formats (Photoshop files, printed posters, PDFs) = sends the implicit signal to the team that "this is the final version, don't change it" → personas will be treated as finished products, becoming rigid, outdated, and unused
Conversely, Google Docs / PPT / Slides = "feedback and modifications are welcome".For teams without professional design capabilities, simple editable formats are more valuable in the long run than gorgeous, polished ones
The early view that "the best personas are ugly" (because they are easy to modify) has softened now, but over-investing in visuals still carries risks: subsequent updates become expensive and difficult. Polished design is only worth it when personas are new to the company and support from leadership needs to be won

7. 5 major failure causes + solutions (Why Personas Fail)

#	Failure	Solution
1	Built but no one uses them, seen as a waste of time	Educate the team and stakeholders on the actual value; share success cases (preferably from within the same organization); review past failures
2	Lack of senior support(leaders think "I already understand users")	Position personas as "a tool to align existing cognition" rather than pure research output; emphasize that they help the team focus on specific users and reduce egocentric design
3	Created in isolation then imposed on other teams	Invite stakeholders to participate in creation (observe user research / receive daily updates); publish research data to enhance credibility
4	Lack of communication, no one knows what personas are for	Hold training to explain the creation process and usage methods; proactively use personas as the basis for discussion in meetings; teach everyone how to use them in testing / task design / data analysis
5	The personas themselves have fundamental flaws(too broad / based on irrelevant data)	Return to Section 3: clarify goals and scope, ensure personas target specific design challenges
(Hidden)	Personas are outdated	See Section 6 — future updatability should be considered during initial design

8. Underlying principle: Design for "the users you actually have"

"You have the users you have." What you have are existing users, not ideal users.

This is the worldview that runs through all persona work. Real users are in a hurry, click things they think might be useful, understand technology far less than designers expect, and don't care that much about your product. The line in design meetings, "By now everyone should know how to use this control, right?" is almost always wrong — usability research has repeatedly proven that many people don't.

Accept reality, don't idealize: design for users' actual behaviors, not the behaviors you expect
One exception: When launching new products or running new-user acquisition marketing, personas must be updated — new users usually have less motivation and less domain knowledge than existing users(people who join later often do so because they were not interested in the first place). In this case, usability testing should recruit two groups: existing users familiar with the old design (who may struggle to adapt to the new design due to path dependence) + zero-experience new users (who have a steeper learning curve)

IX. Special Populations: Designing and Testing for Children (Persona Extension)

Will groups the two "children"-themed articles under personas — the essence is "modeling for a specific user group with extremely large differences in physical/cognitive developmental stages".

Design for Kids by Physical Developmental Stages:

Age	Motor Ability	Design Key Points
3–5 years old	Dominated by gross motor skills	Large, simple gestures (tap, swipe);Buttons ≥ 2cm×2cm (4 times the recommended size for adults); avoid small targets (counterexample: a 5mm close-ad button forced a 7-year-old to use an Apple Pencil to tap it successfully)
6–8 years old	Fine motor skills developing	Start to be able to click with trackpads and simple mice; friend-paired testing yields better results
9–12 years old	Fine motor skills and coordination improve significantly	Able to proficiently use a mouse and keyboard for complex operations

Universal: support multiple gestures to complete the same task (forgiving); reduce requirements for precise dragging (5-year-olds repeatedly fail at dragging tape measures/dragging food to targets → frustration); avoid tasks requiring bimanual coordination or fast response (a single large button is most friendly, e.g., the one-button design in Lego Juniors).

16 Tips for Usability Testing with Minors(Essentials across three phases: recruitment/tasks/facilitation):

Recruitment: recruit extra (high no-show rate), group by age + maturity, provide age-appropriate rewards, prioritize outgoing children
Tasks: use age-appropriate concise language,do not use interface terminology as clues, add variety to prevent boredom, limit sessions to ≤60 minutes for children / ≤90 minutes for adolescents, allow friend pairing for 6–8 year olds, set up a child-friendly lab
Facilitation:parents sign consent forms(minors cannot sign for themselves), allow family members to be present without interrupting, use neutral praise to encourage think-aloud, dress casually to avoid appearing authoritative, warm up with simple tasks to build confidence

Sourced from NNGroup Topics / Personas - User Roles (15 articles). For user research methods, see NNGroup Qualitative Research and Research Methods Toolbox (method landscape/interviews/empathy maps/sample sizes/task design/moderation/expert evaluation/workshops/ethics) / NNGroup Customer Journeys (five elements of journey maps/seven analysis methods · four mapping methods vs service blueprints/experience maps/empathy maps · journey vs process vs story maps · three-line five-step service design and blueprints · project methodology current state-future state&hypotheses-research · CX transformation and journey-centered design · research foundation CUEs/user panels · real-world practice luxury/healthcare/AI image generation); complementary to Will's Google UX Certificate course notes Google UX Certificate / UX Research and Empathy-Define. Images and original documents are retained in sources.