Proto-Personas: Hypotheses Before Research
A proto-persona is the team's best guess about who uses the product, written before research. How to build one, when it helps, and when it becomes decoration.
What is it, and where does it come from?
Userforge defines it as the team’s best guess about who is using the product, built in a workshop from existing assumptions with no new research. It credits Gothelf and Seiden’s book Lean UX (Userforge: Proto-personas).
For the data-based persona, see the article on personas. The idea fits the lean approach: instead of waiting months for perfect personas, the team writes down what it believes, tests it, and corrects it. Wikipedia describes personas in general as semi-fictional characterizations of a typical customer segment or end user, usually synthesized from interviews or surveys. That definition makes clear what sets the proto-persona apart: its origin is assumption, not data (Wikipedia: Persona (user experience)).
When does it help?
Userforge lists four concrete uses:
- Starting from zero, when the team has no data about its users.
- Aligning executives, who often picture different customers.
- Deciding whom to interview first, so research does not start at random.
- Teaching the habit of thinking about concrete people instead of “users.”
On a small team or with a limited budget, a proto-persona written in an hour can be the first useful step. Its weakness is that it leaves the team with an idea that looks real.
How do you build one?
Userforge proposes a central rule: each proto-persona card should be marked as an assumption, with its date and the team’s confidence level. Write what you believe about the persona, what they need, what slows them down, and which questions remain. Then turn each assumption into a hypothesis you can test.
The same site proposes an evidence ladder that runs from assumption to hypothesis, then to data signals, then to firsthand interviews, and finally to repeated patterns. The firsthand rung comes from talking to real people, typically five to eight interviews, and the top rung is reached when the behavior repeats across people and sources. As a stopping rule, saturation works better than a fixed number: keep interviewing until the themes stop changing. Use the research synthesis to organize what you find. See also how many users you need.
Userforge also asks you to avoid fake precision: no stock photos, invented ages, or made-up salaries that lend the card an authority it has not earned.
How do you share it with the team?
Hang the proto-persona on the project board or on an office wall, with its date. When an assumption is confirmed, change its marker; when it is discarded, cross it out and note why. That way the persona changes with what the team learns, and everyone can see how far the work has advanced without rereading documents.
When does it become harmful?
Userforge warns of several risks. The first is presenting an assumption as if it were research. The second is that the team stops at the proto-persona and never replaces it with data, or uses personas as an excuse to skip interviews. Wikipedia adds more serious critiques: Chapman and Milham argue there is no reliable procedure for deriving personas from data, and Portigal describes the appeal of a sanitized version of reality. According to Wikipedia, descriptions with too many attributes tend to describe very few, if any, real people.
NN/g offers a practical warning: a persona must be based on user research and carry only the details that change the design. If a detail would not affect the final design, remove it. The same article advises against getting too witty with a persona’s tagline, which can make it fun but not a useful tool (NN/g: Personas).
Illustrative example
Illustrative example: a team launching a recipe app for people with little time writes a proto-persona called “Laura works Monday to Friday and cooks on Sundays.” The card marks each detail as an assumption, with its date and medium confidence. Before designing, the team conducts six interviews. It finds that Laura does not cook on Sundays; she plans her week on her phone during the commute. The persona changes: now the key moment is the short planning session, not the weekend. Without the proto-persona, the team would not have known whom to interview; without the interviews, it would have designed for a Sunday that does not exist.
To move from the persona to a full journey, an experience map takes the same person and follows them over time. And before researching, the design brief should state which decision depends on the persona.
Common mistakes
- Writing a proto-persona and treating it as a research result.
- Filling the card with demographic data that changes no design.
- Using a persona to avoid talking to real users.
- Creating one persona per segment without deciding which one matters most.
- Leaving the card in a document nobody checks during design.
- Inventing precise details, such as age, salary, or a stock photo, that pass for real data.
What you can do tomorrow
- Write one proto-persona on a page, with each detail marked as an assumption and its confidence level.
- Pick three assumptions that, if false, would change your design. Those are the ones to research first.
- Ask two people on your team to write theirs separately, then compare the differences.