A persona represents a pattern found across research, expressed in a form a team can remember and use. It might describe someone who checks every figure before sharing a report or someone who depends on a colleague to approve account changes. The useful detail explains behaviour and design needs.

A name, photograph, and invented biography can make the document look complete without supplying that explanation. The work of persona development lies in identifying and supporting the pattern, not in decorating the character.

Choose the decisions the personas should support

A persona for broad market planning may need different detail from one used to redesign a technical workflow. Set the scope first, then examine research for differences that matter within it.

Nielsen Norman Group’s account of persona types distinguishes approaches based on different levels and kinds of evidence. Assumption-based proto-personas can help expose what a team believes, provided they are clearly labelled and treated as starting points for research.

For an illustrative reporting product, interviews and observation might reveal two patterns: people preparing recurring reports for others, and people exploring data to answer new questions. These needs may cut across age or job title. Demographic differences should appear when they matter to the experience, rather than because a template has an empty field for them.

Build the representation from traceable patterns

Compare cases before deciding how many personas are useful. Look for combinations of goals, behaviour, constraints, and knowledge, along with exceptions that challenge a simple grouping. Affinity mapping can support this organisation, but a cluster of notes still needs interpretation.

Each persona should explain the relevant circumstances, typical goals, obstacles, and implications for the decisions in scope. Keep links to the supporting studies and make uncertain details visible. A fictional name should not be accompanied by an invented quotation presented as participant evidence.

Avoid treating the categories as permanent identities. The same person may behave differently when preparing a routine report and investigating an urgent problem. A Jobs to be Done account can help preserve that situational variation.

Test whether the personas earn their place

Ask colleagues to use the personas in a real decision. If every persona leads to the same recommendation, the distinctions may be too vague or unrelated to the work. If people cannot connect a claim to evidence, the representation may be too confident.

Update the personas as the audience or product changes, and record their scope and date. They are a maintained research synthesis, not a replacement for future contact with users. Their value is the specific perspective they keep available when a team is deciding whose experience a design needs to support.