The Persona Paradox in the Age of AI

From static user types to shifting behavioral states.

I've lost count of how many times a product manager has asked me, "Do we have a standard persona template?" It has become muscle memory inside organizations — the default first step of any design process.

For a long time, that question made complete sense. Personas gave structure to early research and, more importantly, gave teams a shared language, helping teams build empathy, and stopped engineers from designing only for themselves. They helped simplify complex audiences into something a team could act on.

They were one of the most effective tools we had for static interfaces and stable user goals. Today, the same question makes me pause.

Not because personas are useless. They are not.

But because the design problem has changed, and the tool has not.

We are still using a 30-year-old framework to design AI-driven, adaptive systems whose core value often lies in influencing behavior over time, not just supporting a single task on a screen. The assumptions baked into traditional personas have not kept pace with the realities of behavior change, anticipatory systems, and real-time personalization.

This article is an invitation to examine that gap — and to consider what we might need instead.

This is something I discuss at length in The Anticipatory Design Playbook. One of the central ideas in the book is that intent is not fixed. It evolves. It strengthens, weakens, and shifts depending on context, experience, and readiness. When we design systems that anticipate needs or support behavior change, we are no longer designing for a type of person. We are designing for a moving state.

And that creates a tension. Because the persona, by definition, freezes someone into a stable description.

What Cooper actually gave us — and why it worked

Before I critique personas, we need to understand what made them brilliant for their time. When Alan Cooper introduced personas in the late 1990s, he was solving a critical problem: engineers designing software had no mental model of actual users. They designed for themselves — technically sophisticated, patient with complexity, willing to read documentation.

Cooper's persona framework had three powerful elements:

1. Archetypes based on goals and behaviors, not just demographics. Focusing on what users were trying to accomplish and how they approached tasks.
2. Narrative descriptions that helped teams imagine real usage, not abstract requirements. Rich stories that built empathy and understanding about users' context.
3. One primary persona to design for, bringing focus. Preventing feature overload from trying to serve everyone.

This framework worked brilliantly in its original context because:

• Interfaces were largely static: one interface served all users.
• User goals were stable: "write documents," "manage email," "edit spreadsheets."
• The main challenge was empathy: helping engineers understand that users were not like them.
• Decision-making needed simplification: the team had to choose which user type the one design would primarily serve.

In that world, personas were segmentation tools for static interfaces. The key question was: "Which type of user should this one interface primarily serve?"

How the design problem has changed

Fast forward to now. We are no longer just designing static screens for well-defined user segments. We are designing:

• Adaptive AI systems that personalize flows and content at the individual level.
• Products whose core value proposition is behavior change, not just task completion.
• Experiences where systems intervene proactively based on inferred user state.

The shift looks something like this:

In this context, the strengths of personas turn into weaknesses:

1. Archetypes based on goals assume goals are stable, but in many AI products, goals evolve as people move through stages of change.
2. Narrative descriptions paint a rich picture of "who someone is," but tell AI systems nothing about what state that person is in right now.
3. Singular focus is powerful when you ship one interface; less helpful when your system must support many simultaneous states through hyper-personalization.

The very simplification that made personas powerful for static interface design becomes a liability when behavior is dynamic and systems can, and must, adapt.

What personas ignore about behavior change

Behavioral science has, for decades, told us that people do not relate to change in a single, linear way. Take the Transtheoretical Model, developed in the 1970s by Prochaska and DiClemente, which describes six stages of behavior change: precontemplation, contemplation, preparation, action, maintenance, and termination.

Each stage requires different interventions, different messaging, and different interface affordances. Yet somehow, in 2026, most design teams are still creating personas that ignore this fundamental human behavior.

Why? Because personas were never designed for behavior change. They were designed for market segmentation, empathy-building, and aligning static design decisions. All valuable — but insufficient when you are designing systems that must sense, interpret, and respond to behavior in motion.

Consider another foundational model, B.J. Fogg's Behavior Model: Behavior = Motivation × Ability × Prompt. Which describes behavior that only occurs when three elements converge simultaneously:

• Motivation — Does the user want this outcome right now?
• Ability — Can the user actually do this in the current context?
• Prompt — Is the system triggering action at the right moment?

In practice, this raises a simple question: does your persona document actually tell you…

• The user's current motivation level and how it fluctuates.
• Their real-world ability in context, not a generic "tech-savvy" rating.
• The conditions under which prompts will be helpful rather than intrusive.

Most personas don't. Because most personas are demographic snapshots, not behavioral maps. For AI-driven systems, that is a serious gap. Your system should not just try to "motivate" users in the abstract. It needs to detect current motivation, identify ability barriers, and choose whether to prompt at all in a particular moment.

Static personas cannot do that work for you.

The AI fitness coach problem

Let me show you where this breaks down with a real AI product challenge. Imagine you are designing an AI-powered fitness coaching app. You follow standard practice and create a persona:

Persona: "Busy Professional Sarah"
Age: 34
Goal: Get fit, but has limited time
Behavior: Starts workout programs but doesn't maintain them
Pain point: Inconsistent motivation
Tech savviness: High

From this, your AI design follows from the persona:

• Schedule workouts for early morning (when busy professionals have time)
• Send motivational notifications
• Track progress to maintain accountability
• Offer 20-minute "efficient" workouts

On paper, it looks reasonable. Here's the problem: this AI will fail Sarah 80% of the time.

Why? Because "Sarah the busy professional" isn't one person on one journey — she's actually five different users depending on where she is in behavior change:

Sarah in Precontemplation (not thinking about exercise):

• Your AI: "Time for your 6 AM run!"
• Sarah's response: Deletes app. She's not ready. The prompt creates guilt and resistance.
• What she needed: No prompts. Just educational content if she happens to open the app.

Sarah in Contemplation (thinking about it but ambivalent):

• Your AI: "Your workout streak is broken!"
• Sarah's response: Shame spiral. Uninstalls.
• What she needed: Barrier reduction. "What's stopping you?" Understanding obstacles, not pressure.

Sarah in Preparation (decided to start, making plans):

• Your AI: "Complete this 30-day challenge!"
• Sarah's response: Overwhelmed by commitment. Freezes.
• What she needed: Micro-commitment. "Just walk 10 minutes today. That's it."

Sarah in Action (just started working out):

• Your AI: "Great job! See you tomorrow!"
• Sarah's response: Tomorrow is hard. Falls off.
• What she needed: Immediate, frequent reinforcement. Daily check-ins. Early relapse prevention.

Sarah in Maintenance (exercising consistently for months):

• Your AI: "Don't forget to work out today!"
• Sarah's response: Annoyed. It's patronizing.
• What she needed: Variety, challenge, community — not basic motivation.

Same person. Same demographic persona. Five fundamentally different AI behavior requirements.

The persona tells you she is a "busy professional with inconsistent motivation." It does not tell you how motivation fluctuates across predictable stages, nor how your system should adapt to those shifts in real time.

This is the persona paradox for AI: the moment you freeze someone into a static description, you lose the dynamic state information AI systems need to personalize effectively.

From demographic snapshots to dynamic state maps

Look at a traditional persona: "Sarah, 34, Busy Professional. Goals: get fit, lose weight. Pain points: no time, low motivation. Behaviors: starts programs but doesn't finish."

Now compare that with what an AI system needs to know to act intelligently:

• Current stage of change: contemplation, preparation, action, etc.
• Current motivation: low, medium, high, and how it changes throughout the week.
• Current ability: time, energy, stress level, environmental constraints.
• Contextual triggers: recent health scare, social proof, looming deadlines.
• Barriers: shame, past failures, environmental friction, conflicting priorities.

Personas give you a static, narrative snapshot. Behavioral frameworks give you a dynamic state map that AI can actually use.

In practice, teams notice this when personas start multiplying. One persona does not feel accurate, so you add more and more variants: "young professionals," "older beginners," "time-poor parents," and so on. Soon, you are managing a cast of fictional characters that still fails to predict real behavior.

Personas don't capture this. They can't. They were designed for market segmentation and empathy-building in static interface design, not for mapping dynamic behavioral states in adaptive AI systems.

At that point, the problem is not that you picked "the wrong" persona template. It's recognizing this fundamental issue — people aren't demographic types. They're combinations of behavioral attributes that interact in unpredictable ways.

A different approach: audience factors

So if static personas are misaligned with adaptive systems, what can we use instead? We need a better framework in UX research, one that's particularly suited for AI product design.

One promising direction is: instead of creating personas (fictional people representing user types), we can identify the audience factors that actually drive behavior in your product context — the specific attributes that influence whether someone will succeed or struggle with your product or service in a given context.

The core shift is subtle but important:

• Personas ask: "What type of person is this?"
• Audience Factors ask: "What attributes meaningfully shape behavior here?"

1. Base factors on behavioral attributes, not demographics.

• Not "age 25–35," but comfort with workouts, tolerance to physical activity, or past exposure to similar tools.
• Not "busy professional," but time availability and decision-making bandwidth across a typical week.
• Not "tech-savvy," but observed digital literacy across key tasks.

2. Treat factors as spectrums, not categories.

• Not "fit vs. unfit," but a continuum from "avoids health metrics entirely" to "actively optimizes physical performance."
• Not "motivated vs. unmotivated," but a scale that can rise and fall with context.

3. Assume factors are independent and can combine in unexpected ways.

• High fitness literacy + training anxiety: understands the mechanics of high-performance training but avoids the actual physical exertion or "getting started."
• Low time + optimization behavior: has a very limited schedule but demands the absolute maximum physical ROI for every minute spent.
• High coachability + low health literacy: eager to follow a plan and trusts the process but lacks the foundational knowledge to distinguish between good and bad advice.

4. Recognize that factors are contextual and temporal.

• The same person has different capabilities under stress vs. relaxed.
• Motivation fluctuates based on recent experiences and key life events.
• Stage of change progresses (or regresses) over time.

For our AI fitness coach, the factors that matter are exactly the ones the Transtheoretical Model and Fogg's Behavior Model highlight — stage, motivation, ability, and the conditions for effective prompts. Instead of a single "busy professional" persona, the system needs to track, for example:

• Stage of change: Is this user in precontemplation, contemplation, preparation, action, or maintenance right now, and how is that shifting over time?
• Current motivation: Are we closer to "I know I should, but I don't feel like it" or "I actively want this today," and what recent events moved that up or down?
• Current ability: Given today's time, energy, and constraints, is this a high-ability moment (easy to act) or a low-ability moment (high friction, low bandwidth)?
• Prompt conditions: Is this a moment when a prompt will help (motivation × ability above the action threshold) or a moment when silence or reassurance is safer than pressure?

Two "Sarahs" can look identical on a persona slide — same age, same job, same goal of "getting fit" — and sit in completely different places on these spectrums. One is in contemplation with low ability and needs barrier reduction; the other is in action with high ability and needs challenge and relapse prevention.

Personas cannot show you that distinction. Behavioral factors grounded in stage and in the motivation–ability–prompt triad can.

Why this matters more for AI than ever before

All of this would be interesting, but optional, if we were still shipping static interfaces. But we are not. Here's why this matters more urgently than ever:

AI systems are anticipatory by nature. They predict, personalize, and intervene based on patterns in behavior. Feed them static personas, and they'll optimize around fictional averages. Feed them behavioral factors, and they can adapt to real individuals.

The mismatch shows up in four ways:

• Personas are categorical; AI works best with continuous variables. "Tech-savvy" is not enough. Systems need graded signals that they can update over time.
• Personas are static; AI must respond dynamically. "Wants to get fit but lacks motivation" does not tell you what to do with today's data point.
• Personas assume homogeneity; AI personalizes to individuals. Not all "busy professionals" benefit from the same schedule or prompts.
• Personas lean demographic; AI needs behavioral and contextual signals. Age, job title, and family status are weak predictors of readiness to change.

Consider a fitness AI designed around personas:

• "Busy Professional Sarah" gets morning workout prompts
• "Stay-at-Home Parent Mike" gets afternoon workout prompts

Now consider the same AI designed around behavioral factors:

• Users in precontemplation get educational content, not workout prompts
• Users in preparation get habit-stacking suggestions based on their actual daily routines
• Users in action get just-in-time encouragement at their personal friction points
• Users in maintenance get variety and a challenge to prevent plateaus

One approach treats users as demographic categories. The other treats them as individuals on behavior change journeys. Same product. Completely different logic.

The inclusion problem hidden in personas

There is another reason to be cautious with personas around AI: inclusion. Here's the critical issue: personas tend to reinforce stereotypes, especially around vulnerability.

When we create a persona for "vulnerable customers," we often default to stereotypical markers: elderly, rural, technologically inexperienced, low-income. But vulnerability is situational, not demographic. Designing for vulnerability factors — like anxiety, information overload, trust calibration, and cognitive load under stress — forces us to grapple with the actual mechanics of harm and support.

For example, a 30-year-old academic can be financially vulnerable despite having a stable income — if they struggle with math anxiety and avoid financial products because of overwhelming numerical displays. Or a 65-year-old retiree can be digitally capable and financially sophisticated — but vulnerable to scams because they trust institutional messaging too readily.

Audience factors push us toward that granularity. Personas tend to pull us back toward archetypes. Vulnerability emerges from the interaction between person and system, not from inherent user characteristics.

The standard persona template question

If you're a product manager reading this and thinking, "But we need something simple to align stakeholders," I hear you. Simplification has value. But there's a difference between useful simplification and harmful oversimplification.

One honest answer might be: "We can share high-level personas for storytelling and stakeholder empathy. But for designing AI behavior, we should work from behavioral factors and states, not static user types."

So push towards: "I have something better — a framework for understanding what actually drives behavior in our users. It's not about creating fictional characters. It's about mapping the factors that determine whether someone succeeds or struggles with our product, and designing systems that adapt to individual combinations of those factors."

Make them see that the tools we used in 2005 made sense for static websites designed around demographic segments. The systems we are building now — anticipatory, adaptive, AI-driven — require us to understand people not as fixed types, but as individuals moving through stages, contexts, and constraints.

In summary

Instead of: "Design for Busy Professional Sarah Persona"

Design AI that detects and responds to:

1. Stage Detection (through behavioral signals):

IF user hasn't opened the app in 2 weeks AND ignored the last 5 prompts
THEN infer: Precontemplation
THEN adapt: Stop prompts. If the user opens the app, show educational content only.

IF user opens the app 3x this week AND reads the content but hasn't started the workout
THEN infer: Contemplation
THEN adapt: Offer barrier reduction. "What's stopping you?" Survey. Simplified first step.

IF user completed the first workout this week
THEN infer: Action (early)
THEN adapt: Immediate reinforcement. Daily check-ins. Early relapse prevention.

IF user completed workouts consistently for 3 months
THEN infer: Maintenance
THEN adapt: Introduce variation, challenge, community features. Reduce basic motivation prompts.

2. Ability Detection (through context and behavior):

IF user typically works out at 6 AM on weekdays
AND today is a weekday at 6 AM
AND phone movement patterns suggest the user is awake
AND calendar shows no early meeting
THEN infer: High ability right now
THEN decision: Okay to prompt

IF user typically works out at 6 AM
BUT today the user is still in bed at 7:30 AM
OR calendar shows an early meeting
THEN infer: Low ability right now (unusual situation)
THEN decision: Do not prompt. Wait for a higher-ability window.

3. Motivation Detection (through engagement patterns):

IF user completed the workout yesterday without a prompt
AND opened the app today to log exercise
AND browsed advanced features
THEN infer: High current motivation
THEN adapt: Offer challenge. "Ready for next level?"

IF user skipped last 2 workouts
AND only opens app when prompted
AND exits quickly
THEN infer: Low current motivation
THEN adapt: Reduce expectations. "5-minute walk today?" Lower barrier.

4. Capability Detection (through performance):

IF user completes beginner workouts easily (short duration, no breaks, browses next workout)
THEN infer: Higher capability than current workout level
THEN adapt: Suggest progression. "Ready for intermediate?"

IF user frequently pauses mid-workout OR doesn't complete OR requests easier modifications
THEN infer: Current workouts exceed capability
THEN adapt: Offer easier modifications. Adjust the difficulty down.

Same AI product. Infinite personalized journeys based on detected factor states. No static personas required.

The AI isn't designing for "Sarah the busy professional." It's detecting that this user is currently in the Action stage, with high motivation, medium ability, at a high-ability time of day, showing engagement patterns that suggest readiness for challenge.

That's the user model AI needs. Personas can't provide it.

It's time to let go of the template and embrace the complexity. Not because complexity is good — but because your users are already complex, and pretending they're not is costing you adoption, trust, and impact.

The persona era served us well. The audience factor era is just beginning.