Personas in UX Research: Data-Driven Instead of Invented

Persona photo, name, three sentences about hobbies, done. That is often the result when a persona is needed quickly for the next sprint planning. The problem: a persona without real user data is not a persona. It is an opinion with a face.

Short answer: a research-based persona in UX research comes from real interviews, observations, or usage data, and captures recurring behavior patterns rather than wishful thinking about a target group. The difference between an invented and a real persona is not the format of the card. It is the origin of the data.

Even the inventor of the method eventually had to clarify this. Alan Cooper described personas in 1999 in his book “The Inmates Are Running the Asylum” as a tool built from real field research. At his design firm Cooper, personas were synthesized from interviews to make the goals and motivations of real users tangible. When Microsoft adopted the method, something different happened, according to Cooper: personas were not derived from user data, but invented after the fact to justify features that engineering teams had already decided on. Cooper himself calls this a 180-degree inversion of reality.

This inversion still happens today. Less often at Microsoft, more often in your own sprint planning.

Key Takeaways

• A persona in UX research is based on real interviews, observations, or usage data, not on assumptions

• Even the inventor of the method, Alan Cooper, warned against personas that retroactively justify already-decided features

• According to an NN/G survey, roughly 54% of the personas studied were based on real empirical research

• Research-based personas take more time, up to 222% more than purely assumption-based ones

• Personas are not a one-time document, but an ongoing process with validation loops

• Criticism of personas usually stems from flawed application, not from the method itself

• AI-generated personas are just one of several forms of non-research-based personas

  
  

What is actually still a persona if nobody was ever asked?

At its core, a persona is a behavioral archetype. It summarizes how a specific group of users with similar goals, frustrations, and behavior patterns actually acts. Not how the team imagines that group.

That was exactly Cooper's original idea: personas as a distillation of field research, not a profile built on gut feeling. Once the data foundation is missing, only the shell remains. A name, an age, a stock photo. The card looks professional. The content is fiction with layout.

This does not mean every persona without a brand-new study is worthless. Assumptions and existing team knowledge can deliver a usable first version, as long as it is later checked against real data. The decisive point is the willingness to disprove your own assumption. Anyone who builds a persona and never checks it against real users does not have a persona. They have a claim.

How do you spot an invented persona?

The line between a marketing persona and a persona in UX research is not always obvious. A few traits help with the classification.

A persona that has existed unchanged in the same slide deck for two years is a warning sign. A persona that consists solely of demographic details but names no behavior patterns is a second one. And a persona that was created in a conference room, without anyone on the team ever talking to a real user, is the clearest one.

What data sources does a research-based persona need?

In reality, most teams mix both. According to an NN/G survey of 216 UX professionals (as of the 2015 survey; no comparably large follow-up study since), roughly 54% of personas were based on empirical research, regardless of whether the company was small or large. The rest relied mainly on existing team knowledge and assumptions.

For the empirical share, these sources typically come together:

Qualitative interviews provide depth: why does someone behave the way they behave? What frustration is behind a support ticket? Observations and field studies show what people actually do, not just what they report. Usage data and analytics add frequency and patterns across a larger sample. Support tickets and customer feedback provide additional context, especially for frustration points that are not spontaneously mentioned in interviews.

What matters is not the number of sources, but the consistency of patterns across multiple sources. A persona based on only five interviews that all show the same behavior is more reliable than a persona built from twenty interviews with completely contradictory statements.

How do you build a persona step by step from real data?

The process can be described in four steps, regardless of how much budget and time are available.

1. Gather data

Collect interviews, observations, or existing usage data. No minimum number of interviews guarantees quality, but a clear goal helps: enough conversations until patterns repeat and no new surprises appear.

2. Cluster patterns

Group recurring goals, frustrations, and behaviors. Who solves which problem in which way? Where do users actually differ in their behavior, not just in their demographics?

3. Formulate the behavioral archetype

The cluster becomes a persona: a name, one central goal, the biggest frustration, a typical scenario. Demographic details only when they actually influence behavior, not as decoration.

4. Validate with the team

Show the persona to the people who deal with users daily (support, sales, research). Does the picture match their experience? Does anything contradict it?

This process takes time, and that is no coincidence. According to the same NN/G survey, a predominantly empirical approach increased the time investment by 86% for large companies and by 222% for small companies, compared to purely assumption-based personas. Most of that time goes into step one, data gathering, not into the nice layout of the finished card.

For data gathering and analysis, it is worth taking a look at quantitative UX methods, especially when personas are later meant to be checked against larger samples.

How often does a persona need to be validated or updated?

A persona is not a final result, but a snapshot. User behavior changes, products evolve, new target groups emerge. A persona that was excellent when created can miss reality two years later.

A fixed rhythm helps more than a one-time “done”. A review makes sense whenever the product changes structurally (a new target group, a new core feature), or whenever the team repeatedly doubts whether the persona is still current. Anyone who is already in continuous contact with users, for instance through Continuous Discovery, gets this validation almost as a byproduct instead of having to plan it as a separate project.

Why do personas fail in everyday team work even when they were built correctly?

A recent study asked exactly this question. Nielsen and Madsen analyzed three LinkedIn discussions in 2026 involving a total of 75 UX practitioners about their real-world experiences with personas. The result: personas demonstrably support user-centered decisions in the design process. The criticism, mainly poor data quality and misconceptions about the method, mostly stemmed from flawed application rather than from the method itself.

This matches my own observation from many projects: when teams say “personas don't do anything for us,” the first thing I ask is how the persona was created. The answer is almost always the same: in a workshop, without new interviews, three years ago. That is not a failure of the method. That is a method that never got the chance to work.

A brief note on AI-generated personas

AI tools can generate personas in minutes today, usually based on training data or existing texts, not on original user research. That makes them just another variant of the non-research-based persona, alongside the classic gut feeling in a marketing meeting. The risks involved differ enough from those described here that they deserve their own article: AI Personas: What They Can Do, and What They Shouldn't.

Conclusion

A persona in UX research is not a deliverable you check off once. It is a distillation process built from real user data that has to be reviewed again and again. The difference between a good persona and an invented one does not show on the card. It shows in the question of who ever actually talked to real users to create it.

If you want to approach this process systematically instead of once: in our workshop “Mastering Continuous Discovery,” we show how to build ongoing user research into everyday team work, so personas (and other research artifacts) never again sit untouched for two years.

Where does your team stand right now: do you have personas that have never been checked against real users? Or is the opposite your problem, too much effort for too little day-to-day use?

FAQ

What is the difference between a marketing persona and a persona in UX research?

A marketing persona is usually based on assumptions and demographic wishful thinking about the target group. A persona in UX research is based on real interviews, observations, or usage data and describes behavior rather than demographics.

How many interviews does a reliable user persona in UX research need?

There is no fixed number. What matters is whether behavior patterns repeat across multiple conversations. Once new interviews stop revealing new patterns, the data foundation is usually sufficient.

Can a persona in UX research be created without a large study?

Yes, using existing team knowledge as a starting point. It is important to clearly mark this first version as provisional and to check it against real users soon after.

How often does a persona in the user experience need to be updated?

Whenever the product or target group changes structurally, or whenever the team repeatedly doubts its accuracy. A fixed schedule alone is rarely enough.

Do AI tools replace user research for personas?

No. AI-generated personas are usually not based on original user research and carry their own risks. More on this in the article on AI personas.