How to Build a Persona from Scratch Using Interview Transcripts

A persona turns scattered interview evidence into a practical representation of a user group. It describes the people behind behaviours, needs, frustrations and goals, helping a product team make decisions with real-world users in mind. When built carefully, a persona is more than a fictional profile: it is a concise interpretation of recurring patterns in qualitative research.

Interview transcripts are a strong foundation because they preserve participants’ own language. Notes often capture a researcher’s summary, while transcripts reveal hesitation, workarounds, emotional reactions and the reasons behind a particular choice. Those details can expose needs that direct survey responses may miss.

The process works for a new website, mobile service, internal system or accessibility project. For example, an Australian team might interview customers in Sydney, Melbourne, Perth and regional communities to understand how location, connectivity and service expectations influence behaviour.

A persona should remain grounded in evidence. It should not become a convenient stereotype based on age, job title or assumptions about technology. The aim is to identify meaningful behavioural patterns and make those patterns easy for designers, analysts and developers to use.

Prepare the transcripts and research context

Begin by gathering the complete interview set, participant screener, discussion guide and any contextual notes. Record useful metadata for each participant, such as their broad role, experience level, location, device preference and relationship with the service. Avoid adding personally identifying information that the project does not need.

Clean the transcripts lightly rather than rewriting them. Correct obvious transcription errors, label speakers consistently and mark important moments with timestamps. Keep the participant’s wording intact where it communicates motivation or frustration. A quote such as “I check it on the train, then finish it at home” may reveal a stronger usage pattern than a general statement about mobile access.

Before coding, clarify the research question. A project exploring online banking may focus on trust and security, while a usability study for a government service may examine form completion, language clarity and document requirements. In Australia, access conditions can vary significantly between inner-city users and people in regional or remote areas, so connectivity and travel time may be relevant research dimensions.

It is also useful to separate user roles from personas. A role describes responsibilities or participation in a system, while a persona represents a research-backed user type. The difference between roles and personas can help prevent a project from treating every job title as a distinct persona.

Code behaviour rather than demographic labels

Read each transcript more than once. During the first pass, highlight statements about goals, tasks, obstacles, triggers, workarounds, expectations and emotional responses. During the second pass, assign short codes such as “needs reassurance”, “switches between devices”, “relies on staff help” or “abandons lengthy forms”.

Keep codes close to the evidence. “Busy parent” is a broad description, but “completes applications after children are asleep” identifies a specific context that can affect design decisions. Likewise, “older user” says little about behaviour, while “prints instructions before starting an unfamiliar process” provides a useful product insight.

Look for repeated patterns across participants, including contradictions. Several people may value self-service but still want a phone number when something goes wrong. Others may describe a feature positively while quietly avoiding it. These tensions are valuable because they reveal where stated preferences and actual behaviour differ.

Do not count every repeated word as an important theme. A participant may mention price frequently because the interviewer asked about it several times. Give greater weight to patterns connected with actions, decisions, pain points or unmet needs.

Cluster evidence into behavioural groups

Transfer your codes into a simple affinity map. Place similar observations together and name each cluster with a clear behavioural statement, such as “needs progress visibility” or “checks information through trusted channels”. Digital whiteboards, spreadsheets or a collaborative UCD tool can support this stage.

Compare participants by behaviour instead of sorting them first by age, gender or location. Two people in Brisbane may have entirely different levels of confidence, while a university student in Adelaide and a small-business owner in Newcastle may share the same need for quick, interruption-friendly tasks.

Create a provisional segment when a cluster has enough supporting evidence and a meaningful difference from other clusters. A segment should explain why users act differently, not simply describe who they are. If one group needs extensive guidance and another prioritises speed, those distinctions may justify separate personas.

Record the evidence behind each cluster. Note which interviews support the pattern, whether the finding is strong or tentative, and what evidence might challenge it. This audit trail makes the persona more credible and allows the team to revise it when new research arrives.

Write a usable persona profile

Give the persona a realistic name and a descriptive label, such as “Priya, the time-poor coordinator”. Use a representative image only as a memory aid; it should not imply that the persona literally depicts one participant. Include a short background, relevant context, goals, behaviours, frustrations, needs and preferred ways of completing tasks.

Add two or three carefully selected quotations from the transcripts. Quotes should sound natural and express the persona’s perspective, but never expose private information. If transcripts contain names, account details or sensitive health information, anonymise them before publication or sharing.

A strong profile explains how the persona behaves in a situation. For instance, a regional Australian customer might save a service page because mobile coverage is unreliable during travel, while a Melbourne office worker may begin the same task on a phone and complete it on a desktop. These details connect the persona to design requirements.

Keep the profile concise enough to use during workshops and reviews. A long biography can distract from the evidence. Prioritise details that affect product decisions, such as accessibility needs, digital confidence, language preferences, device constraints and the consequences of failure.

Validate and apply the persona

Return to the transcripts and test every important claim. Can the team identify supporting excerpts? Is the persona based on several participants rather than one memorable interview? Does it describe behaviour that matters to the product? Remove attractive details that cannot be justified by the research.

Validate the draft with colleagues who understand the interviews, then compare it with usability findings, analytics and support records. Synthetic records can help test whether a persona-based scenario works in a prototype, and online faker tools may provide safe sample data without exposing real customer information.

Use the persona to shape requirements, content, navigation and test scenarios. If the persona needs reassurance before submitting a form, the interface may require clearer status messages and error recovery. When documenting those interactions, testable use-case scenarios can turn persona needs into observable acceptance criteria.

Store the transcript references, assumptions and revision date with the profile. Treat the persona as a living research artefact rather than a permanent label. As the product reaches more users across Australian cities, suburbs and regional areas, new evidence can refine its priorities and reveal when another persona is genuinely needed.