User personas are a fundamental part of UX design projects. They help us empathize with users, prioritize pain points and solutions, and store research learnings in a digestible format.
But not everyone is familiar with proto-personas. They’re, to say the least, a great tool in a designer’s toolset. Worse yet, some people confuse personas with proto-personas. Although similar, there are a few critical differences that, when ignored, can cause more chaos than good.
So, in this blog, I save you the chaos. I’ll talk about proto-personas — what they are, when and why to use them, and how they differ from typical user personas.
Editor’s note: This article was updated in September 2026 to clarify when proto-personas are useful and when they risk turning assumptions into apparent research. The update also adds guidance on AI-generated personas, including how AI can help organize hypotheses without validating that they represent real users, and expands the discussion around research risk, validation, and high-stakes design decisions.
A standard user persona is a snapshot summarizing key characteristics of a specific segment of users we are designing for. It includes information such as demographics, key pain points and needs, preferences, and skills.
Personas serve as a guiding light throughout the design process, helping ensure we’re designing for specific users, not for ourselves.
A proto-persona, on the other hand, may look identical to a traditional persona with similar content. But the difference comes in how they’re created.
A user persona is rooted in research and validated information about the user. A mixture of qualitative and quantitative research methods contributes to creating a well-informed, research-backed persona.
Proto-personas are primarily assumption-driven rather than research-backed. They’re more of a collection of assumptions and beliefs about the particular user. Insights may support some of these assumptions, but generally, they are far from “confirmed evidence” and closer to beliefs.
If you have ever been involved in creating a user persona based on high-level thoughts, some basic desk research, and stakeholders’ opinions, you actually created a proto persona.
I’ll put it simply — a proto-persona is, in fact, an inferior version of a proper user persona. But there are some major benefits of using proto-personas, which make them a tool worth considering:
If you don’t yet have solid research on your target audience, a proto-persona can give your team somewhere to begin — as long as everyone understands that it represents hypotheses, not users.
That distinction is more important than the artifact itself.
Teams already carry assumptions about who their users are. A proto-persona can make those assumptions visible, give the team something concrete to challenge, and expose where research is missing.
The goal isn’t to make an unvalidated persona feel real. It’s to turn implicit assumptions into explicit questions you can investigate.
Regardless, though, the sooner you switch from proto persona to real personas, the better.
With proto-personas, you can identify and prioritize. Think of answers to questions like:
Creating a proto-persona can actually speed up the process of building a fully developed user persona.
Building a proto-persona doesn’t take much time or cost. All you need to do is gather a few informed people and make the team’s assumptions about the audience explicit.
If resources are tight, that can be a useful way to decide what you need to learn next. But the value comes from exposing those assumptions, not from treating the resulting persona as a substitute for research.
Generative AI has made it incredibly easy to produce convincing personas. Give an AI tool a product description and a target market, and within seconds you can get names, biographies, frustrations, motivations, behaviors, quotes, and even profile images.
That speed is useful, but it can also make the core problem with proto-personas worse.
An AI-generated persona is not automatically a research-backed persona. If the model isn’t working from validated user research, it is essentially generating plausible hypotheses based on your prompt and the patterns in its training data.
And plausible isn’t the same thing as true.
AI can still be useful during this stage. For example, you can use it to:
What it can’t do is validate that a persona accurately represents your users.
I’d apply the same rule to AI-generated proto-personas as any other proto-persona: trace each important claim back to its source. If the source is “the model generated it,” treat it as a hypothesis that still needs evidence.
You might even add an evidence label next to individual attributes:
That makes it much harder for a polished AI-generated artifact to quietly turn speculation into “research.”
To put everything in context, I’ll now share an example of when using a proto persona helped us immensely,
My team was developing an EdTech mobile app that aimed to help students in Nigeria pass their university entrance exams.
We didn’t have strong research on our target audience and were under pressure to deliver before the next exam cycle. So, we started by gathering all the beliefs and assumptions.
We ended up with these insights into our end user:
We listed these assumptions and beliefs based on common knowledge and past experiences. They weren’t random guesses, but they weren’t validated statements either.
That distinction matters. A proto-persona should represent what your team thinks might be true about users, not what you claim to know about them.
The danger starts when that distinction disappears. Once assumptions are packaged into a polished persona with a name, photo, goals, frustrations, and behaviors, they can begin to look more authoritative than the evidence behind them actually is.
So, I find it useful to treat every proto-persona as a set of hypotheses waiting to be tested. If you can’t point to research behind a statement, label it as an assumption rather than letting the artifact masquerade as user research.
I am a huge proponent of a visual approach to creating UX artifacts. But a simple Excel template like this can help you structure your train of thought if you are looking for a quick starting point:
You might find information such as age or name superficial at this stage. However, if you are working with multiple (proto)personas simultaneously, this information will help create mental differentiation between them.
If you want to begin with something more robust, any standard user persona template will work.
Next, we prioritized the assumptions based on two things: how confident we were that they were true and how much the product depended on them being true.
An assumption with little evidence might not matter much to the design. Another assumption might seem fairly plausible but become much riskier if getting it wrong would fundamentally change the product.
Looking at both confidence and risk helped us decide what we could tentatively design around and what we needed to validate first.
Our next and last task was to validate the riskiest assumptions, update the proto-persona, and repeat the process.
After several interviews and surveys, we reinforced our belief that exam-takers are willing to practice daily. Surprisingly, though, we discovered that biology and chemistry were significantly more desirable subjects to pass than math and science. We also gathered a few other insights, which we added to the proto-persona for further validation.
We then continued work on developing our MVP (focusing on the most validated assumptions) while continuing our validation research around the proto-persona. This continuous iteration cycle helped us turn the proto-persona into an actual user persona step-by-step without needing all insights upfront.
Proto-personas are a great starting point and often better than a blank page. But they might not always be your best choice. I recommend avoiding them for a few situations:
When designing for a challenging project without much initial insight or even assumptions, you definitely need to put in hours for proper research.
Yes, proto-personas tend to speed up research by giving some guidance on structuring further research, but they might not be the best for complex and ambiguous challenges. You’ll likely be missing many important things.
Starting an exploratory project with an open mind is more efficient than putting preexisting assumptions into the picture.
There are situations when you can easily get access to important user data — say, if:
In such circumstances, you’re better off investing some extra time at the beginning to gather and use this data and starting with the proper persona from day one.
For projects where mistakes can have serious consequences — such as emergency-response or other safety-critical systems — assumptions about users shouldn’t drive consequential design decisions. These environments require rigorous user research and validation rather than relying on proto-personas as a shortcut.
Proto-personas are especially risky when stakeholders are looking for certainty. If an artifact is likely to get copied into strategy decks, requirements, AI prompts, segmentation models, or product decisions without its assumptions being questioned, creating a polished proto-persona might do more harm than good.
In those environments, a simpler assumptions map or research-question backlog might actually be safer because it doesn’t visually resemble validated research.
Proto-personas work best when everyone can still see the uncertainty inside them. Their purpose isn’t to give a team confidence that it understands its users. It’s to show the team exactly where that understanding is still incomplete.
Use them to expose assumptions, prioritize research, and get early conversations moving. Then replace those assumptions with evidence as quickly as you can.
And whether the persona was created by a workshop, a stakeholder, or an AI model, the rule stays the same: if you haven’t validated it with real users or reliable user data, it’s still a hypothesis.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Through this step-by-step guide, you can learn how to easily import files from Adobe Illustrator to Figma.
Growth design isn’t just about getting more users to convert. It’s about using research, experimentation, and data to improve activation, retention, and long-term user value without sacrificing trust or the quality of the experience.
Design thinking workshops are your key to turning big problems into clear solutions. In this blog, I share how to run them efficiently and keep your team aligned.
Conversion optimization works best when it improves the experience, not just the metric. This guide covers experimentation, accessibility, personalization, guardrails, and AI-assisted CRO without crossing into manipulation.
Learn more →
