UX/UI Design, A to Z ┃ 1.8 Proto-Personas: Making Your Team's Assumptions Visible

Welcome back! How’s everything going?

A proto-persona doesn't describe your user. It describes what your team believes about your user — written down so you can go and check.

Ask three people on a product team to describe "our user," and you'll often get three different people. The PM pictures someone ready to pay. The designer pictures a daily power user. The engineer pictures whoever files the most bug reports.

Nobody is lying. Everyone is guessing — quietly, and differently.

A proto-persona drags those private guesses into the open.

What Is a Proto-Persona?

A proto-persona is a lightweight, provisional user model built from what your team already knows — or thinks it knows. The term was popularized by Jeff Gothelf and Josh Seiden in Lean UX, which reframed personas as hypotheses to be tested rather than deliverables to be admired.

The difference from a traditional persona is where it comes from:

• A research-based persona describes patterns found in actual user research.
• A proto-persona captures assumptions drawn from team experience, support tickets, analytics, and market knowledge.

Same format. Very different level of confidence. That's why a proto-persona should never be the final justification behind a design decision.

The question it answers:

Who do we currently believe our users are — and what have we not confirmed yet?

The Problem It Solves

Early in a project, misalignment is invisible. Everyone says "the user" and assumes they mean the same thing. Three months later it resurfaces as an argument about a feature — and by then it's expensive.

Making assumptions explicit lets the team decide, on purpose:

• Whose problem do we look at first?
• What goals and frustrations are we assuming they have?
• Which of these assumptions actually needs testing?
• Who should we recruit for research?

A proto-persona is not evidence that you understand your users. It's the starting line for going and finding out.

When Do You Make One?

Before research begins, or while you're still planning it. On the Double Diamond, that's the front end of Discover.

Reach for one when:

• Your target user is still fuzzy
• Team members clearly picture different people
• You need to decide who to recruit for interviews

Skip it when you already have solid research data — in that case, analyze what you have and build a research-based persona instead. A proto-persona is a tool, not a mandatory deliverable.

Rule of thumb:

Build it as a hypothesis before research. After research, confirm it, revise it, or throw it away.

What Goes on the Card

Keep it to what actually informs design and research. Five fields is plenty. Here it is filled in with a group-travel example:

1. User type — the situation and characteristics that define them

• Example: Small groups traveling together, planning the trip with people they've only just met.

2. Goal — what they're trying to achieve

• Example: Quickly agree on restaurants and attractions that everyone in the group is happy with.

3. Current behavior — how you think they solve this today

• Example: Drop several options into a group chat and watch for reactions.

4. Frustrations — the friction you expect them to hit

• Example: Differences in budget, distance, and taste make decisions drag on.

5. Assumptions to test — written as open questions

• Example: Is cost the main source of disagreement? Does one person usually end up making most of the decisions?

A note on demographics:

Age, job title, and hobbies belong here only when they directly affect the research. A name and a rough sketch can help the team refer to the persona in conversation — but pile on invented biographical detail and you'll find the team designing for a fictional character instead of a real behavior.

Building One: Five Steps

Step 1: Gather what you already have.

• Stakeholder experience, support tickets, product analytics, market reports, past research.

Step 2: Separate fact from assumption.

• Draw a literal line down the middle of the board. Observed evidence goes left; inference goes right. This step is the entire reason the exercise works — and it's the one teams skip.

Step 3: Group users into types.

• Cluster people with similar goals, behaviors, and problems. Two or three types is usually enough to start. Resist the urge to cover everyone.

Step 4: Convert assumptions into research questions.

• Every item in the right-hand column becomes something you can ask, observe, or survey.

Step 5: Update with what you learn.

• Right assumption? Sharpen it. Wrong? Rewrite or delete it. A proto-persona is a hypothesis you built to be tested — not a deliverable you defend.

Proto-Persona vs. Research-Based Persona

A proto-persona isn't a rough draft of a "real" persona. It's a different tool with a different job: surfacing assumptions so they can be tested.

If You Put It in Your Portfolio

Never present a proto-persona as if it came from research. Reviewers notice, and it costs you credibility.

Frame it honestly — and the honest version is the more impressive one anyway:

"With limited user data at the start of the project, I created proto-personas to document our assumptions. I used them to define recruiting criteria and draft interview questions, then revised those initial assumptions based on what the research showed."

The polished persona graphic is not the story. What you assumed, how you tested it, and what changed — that's the story.

Key Takeaways

• A proto-persona is a temporary user model built without research — a hypothesis, not a finding.
• Its job is to make the team's assumptions visible so they can be discussed and tested.
• Keep it lean: user type, goal, current behavior, frustrations, and assumptions to test.
• Every assumption should become a research question. If it can't, it probably isn't worth writing down.
• Revise or delete it once research comes in. Nothing about it is precious.
• Never present it as validated user data — not in a project, not in a portfolio.

Before You Go

A 15-minute exercise

Pick a product you use often — a delivery app, a note-taking tool, whatever's open on your phone right now.

1. Write a proto-persona for one of its user types using the five fields above. Give yourself 10 minutes, and don't look anything up.
2. Circle everything you wrote that you can't actually prove. (Expect this to be most of it.)
3. Turn your three shakiest circles into questions you could ask a real person.

A Worked Example — A Note-Taking App

Step 1 — the 10-minute draft

Step 2 — circle what I can't prove

• "Office workers" — this is actually me. A sample of one isn't evidence.
• "Find it quickly" — is retrieval really the goal? For plenty of people, the act of writing is the point.
• "Put off organizing" — postponing something and never intending to do it are different behaviors.
• "Hard to find anything" — this frustration rests entirely on the premise that users go back and look. I have never checked that premise.

That last one is the whole exercise. The problem I wrote down with total confidence was resting on a single unverified assumption.

Step 3 — turn them into interview questions

1. When was the last time you opened a note you'd written weeks earlier? Walk me through what was going on.
2. Could you show me a note you made last week? Tell me how it ended up looking the way it does.
3. Has there been a time you couldn't find a note you needed? What did you do instead?

All three ask what you actually did, not what you would do. To test an assumption, you have to ask about past behavior, not imagined behavior.

Notice that the third question leaves room for "no, that's never happened." That answer would demolish the assumption — which is exactly why the question has to allow it.

This isn't a model answer. Two people writing about the same app should end up with different cards.

That last list is what a proto-persona is really for. The card is just how you got there.

What's Next

User Interviews — Part 1

You're finishing this lesson holding a list of questions. Next up: how to ask them without getting the answer you were hoping for.

We'll cover:

• What a user interview is for — and what it genuinely can't tell you
• How a session runs, from the first question to the last
• How to plan one that gets past polite, agreeable, useless answers

Bring the three questions from your exercise. We'll put them to work.

If this helped, stick around — follow the blog for the next one, and send it to a friend who's just starting out.

Thank you! 🙌