Proto-Personas: How to Create User Alignments in Under an Hour

Traditional user personas are valuable tools when they are done well: research-grounded representations of real user segments, built from interview data, behavioral analytics, and observational research, that help teams make design and product decisions from a shared user model. They are also expensive, time-consuming, and frequently wrong in ways that are not apparent until late in the product development cycle. A persona built from three weeks of research and documented in a beautifully designed twelve-page PDF represents a significant investment in a snapshot of user understanding that will be outdated by the time the team has finished reading it.

Proto-personas are the lean alternative: assumption-based user archetypes that a cross-functional team creates collaboratively in under an hour, explicitly acknowledging that they reflect the team's current best guesses rather than validated research findings. They serve the same purpose as traditional personas — aligning the team around a shared model of who they are designing for — without requiring weeks of research as a prerequisite. The critical discipline is in the labeling: proto-personas must be explicitly identified as assumption-based, with a clear plan for how and when they will be validated against real user data.

Team members creating user persona sketches on sticky notes during a workshop

A proto-persona workshop surfaces and aligns the team's user assumptions in under an hour.

When Proto-Personas Are the Right Tool

Proto-personas are appropriate at the beginning of a new product initiative, when the team has limited prior user research but needs to start making design decisions. They are appropriate when an existing product is being extended to a new user segment that has not yet been formally researched. They are appropriate when the team's existing personas are outdated or contested, and the team needs a shared starting point for alignment while new research is being planned. In each of these situations, the alternative to proto-personas is not traditional research-based personas — it is implicit, unexamined assumptions about users that different team members hold independently and that will diverge over the course of the project in ways nobody will notice until the product is in front of real users.

Proto-personas are not appropriate as permanent replacements for research-based personas. They are starting points that must be validated against real user data as the project progresses. The explicit commitment to validation is what distinguishes proto-personas from lazy persona work: a proto-persona is a documented hypothesis about who your users are and what they need, accompanied by a specific research plan for testing that hypothesis. Without the validation commitment, a proto-persona is just an assumption that has been given a name and a face — which is worse than acknowledging the assumption explicitly, because it creates the false appearance of research-based confidence.

Running a Proto-Persona Workshop: A 45-Minute Process

The proto-persona workshop begins with a brief framing: 'We are going to create initial user archetypes based on what we collectively know and believe about our users. These are starting points, not conclusions. We will validate them through research over the next few sprints.' This framing sets the expectation that the exercise is about surfacing and aligning assumptions, not documenting facts. Divide the team into groups of two to three people. Each group has ten minutes to sketch a user archetype on a large sticky note or whiteboard section: a rough drawing of the person, a name, a demographic summary, their goals related to the product space, their frustrations or pain points, and their current behaviors. No more than ten minutes — the time constraint prevents over-elaboration.

After the sketching round, groups share their archetypes with the full team. The facilitator looks for convergence and divergence: Where do teams agree on who the users are? Where do they disagree? Disagreements are the most valuable output of the workshop — they surface the assumptions that are most contested and therefore most in need of validation. The team works together to synthesize the archetypes into two to four distinct proto-personas that represent the major user segments the product needs to serve. Each proto-persona is documented on a single page with the sketch, the name, the key attributes, and a list of the assumptions embedded in the archetype that have not yet been validated.

UX researcher reviewing user interview notes to validate persona assumptions

Proto-personas are starting points — they must be validated through research as the project progresses

Validating Proto-Personas Through Research

The validation plan for proto-personas should be built into the initial workshop output. For each proto-persona, the team identifies the three most important assumptions embedded in the archetype — the things that, if wrong, would most significantly affect the product direction. These assumptions become the first priorities for the discovery backlog's research queue. Within the first two to three sprints of the project, the team should be running user interviews specifically designed to test whether the proto-persona's demographics, goals, frustrations, and behaviors match reality.

The expected and healthy outcome of proto-persona validation is that some aspects of the archetypes are confirmed and others are revised or replaced. A proto-persona whose demographic assumptions are confirmed but whose behavioral assumptions are significantly wrong is not a failure — it is a learning. The team updates the persona to reflect the validated understanding and identifies the next set of assumptions to test. This iterative validation process gradually transforms the proto-persona from an assumption-based starting point into a research-grounded understanding of real user segments. The proto-persona is not replaced by a traditional persona — it evolves into one through the accumulation of validated evidence.

Using Proto-Personas to Drive Team Decisions

Proto-personas are most valuable when they are used actively in product and design conversations rather than documented and forgotten. The simplest mechanism for active use is the 'persona check' — a question asked at the beginning of any significant design or product decision: 'Which of our proto-personas does this decision primarily serve? What would [Persona Name] find valuable or frustrating about this approach?' This question grounds the conversation in user terms and makes persona assumptions explicit and challengeable.

The proto-persona should also be visible in the team's physical or digital workspace. A poster on the wall, a pinned document in the shared workspace, a card in every design review slide deck — whatever format ensures that the persona is referenced rather than merely acknowledged. Teams that keep their proto-personas visible find that the personas naturally become part of the team's shared language: 'This is a Sarah workflow' or 'Marcus would never navigate through four levels of settings to find this.' This shared language is the practical evidence that the persona exercise achieved its goal of aligning the team around a common user model.

The Bottom Line

Proto-personas give product teams the user alignment they need to make coherent decisions, at a fraction of the time and cost of traditional persona research, as long as they are treated as what they are: documented hypotheses, not validated facts. The discipline of explicit assumption-labeling and systematic validation is what prevents proto-personas from becoming the kind of research theater that gives personas a bad reputation. Done well, proto-personas are not a shortcut — they are the right starting point for teams that need alignment before they have research, and a commitment to replace assumption with evidence as quickly as the work allows.



Want to go deeper? This post is part of the Sense & Respond Learning resource library — practical frameworks for product managers, transformation leads and executives who want to lead with outcomes, not outputs.

Explore the full library at https://www.senseandrespond.co/blog


Josh Seiden

Josh is a designer, strategy consultant and coach who helps organizations design and launch successful products and services. He has worked with clients including Johnson & Johnson, JP Morgan Chase, SAP, American Express, Fidelity, PayPal, Hearst and 3M.Josh partners with leaders to clarify strategy, drive alignment and create more agile, entrepreneurial organizations. He also works hands-on with teams to help them become more customer- and user-centric in pursuit of meaningful outcomes. Josh is a highly sought-after international speaker and workshop facilitator and is a co-founder of Sense & Respond Learning.

Previous
Previous

The Portfolio View: How CPOs Balance Explore vs. Exploit Across Product Lines

Next
Next

Writing Better User Stories: Why You Need 'Hypothesis Statements' Instead