The Pitfalls of Designing Without Persona

Let’s start with a statement that, in my point of view, frames the discussion well: Personas are not useful at all.

Believe in what you do and trust your approach before changing your habits for others.

Nobody uses them, and everyone skips this phase to jump straight into designing screens, flows, and maybe testing — if not just spending some time on an internal critique before shipping. So why create personas that end up as a simple checkbox, with no real connection to how we design?

What I have learned from my 12 years in design is that, when you need to pay strong attention to users’ needs and expectations, you also need to pay attention to your stakeholders’ internal behaviours and habits.
The main problem I see when you treat internal stakeholders’ needs as user needs is that you design based on habits and reinforce the wrong behaviours internally. Instead, what we need to do is push new behaviours and inspire others to do the same.

The classical sentences — “We never did this” or “We used to” — do not mean these are the right approaches to deliver qualitative work and outcomes.

So instead of changing your design process just because stakeholders around the table are not informed or aware of what is best to do and rely only on what they currently know, focus more on change management and behaviour-guiding through examples and inspiration.

One example comes directly from my last experience:

All my designs and user journeys are in Figma. For every user journey I craft, there are linked design explorations, prototypes for testing, and final designs with all requirements and user flows ready to be implemented (with Desktop & Mobile instances + Dark Mode versions). For microcopy it’s the same: every word is chosen to convey a single message and broken down into the reasoning behind it (for example, the double-validation message before deleting a core object), stored directly in the Figma file.

BUT for heavy content — articles, important information requiring validation from experts (financial, medical, etc.) — I do not like to have them in Figma. For this type of content, I prefer a document in Google Drive or Notion where everyone can update the copy, decoupled from the design. The design can change, but the content must remain consistent, especially when it appears across multiple instances.

The fact was that all my stakeholders wanted the content directly in Figma instead of in a Notion page. I did not push my point of view — this would have created more barriers — but I started explaining why core content should be stored in a document (easy access and centralized documentation) versus Figma (more volatile because design can change every three months). I added the content in four different Figma screens about the same topic but also in the dedicated Notion page.

My next step is to tag them and ask questions about content in Notion, not Figma, so they gradually shift their perception and habits about where information should live. Over time, comments will appear in Notion rather than Figma, turning Notion into the main source of truth.

Why teams stop using Persona

This example can be applied to personas as well. More and more design teams do not use personas — not because they don’t value them, but because stakeholders don’t value them. They trust more in quantitative behavioural data (product usage data mining) and do not rely on personas when making business decisions.

According to the 2024 UXPA Salary Survey (analyzed by MeasuringU), approximately 41% of UX and design professionals report that they do not use personas or user profiles in their work.

Stakeholders — especially engineers and executives — often view personas as “creative writing methods” rather than data-driven tools. When personas include irrelevant details (e.g., “Marketing Mary owns a golden retriever”), stakeholders dismiss the entire document as fluffy.

Personas are often produced by the UX team in isolation and then “revealed” to the organization. Because stakeholders were not involved in research or synthesis, they feel no ownership over them.

The pitfall of not using Persona (or any equivalent tool)

When you do not use the right persona — or whatever method you use to understand users first — you end up designing for “everyone,” which means designing for no one.
You choose a single point of view using the worst thing to say: “OR.”
This makes you think in silos and assume there is only one way to design.

The mindset shift needed is from “OR” to “AND.”
You need to design for Persona A and Persona B. This adds complexity, but this is part of the job: simplifying complexity for yourself and for your users.

Your impact will be reduced when everything becomes oversimplified and generalized, when we know that thousands of situations and contexts exist. This is the beauty of design: to understand these contexts before making decisions.

How I pushed a Persona Archetype approach in my work

Recently I focused on the mental health domain. We deliver physical and mental health support for our members.
Historically, the journey was simplified around one outcome: reducing complexity and time to complete the intake in order to book a consultation.
This has logical roots: people want to feel better and reduce distress.

But this is not everything.

Through qualitative and quantitative research, I found that more than 60% of users are not emotionally ready to book a consultation.
“Not emotionally ready” covers many conditions, so I explored deeply and found that these people go through a real journey before deciding to speak with someone, moving through five emotional stages.

This insight opened an important question:
Who do we want to design for?

• Those emotionally ready who already decided to talk? (40%)
• Or those not ready who need support before considering therapy? (60%)

Both groups ultimately want the same thing: solve mental health conditions affecting their life.

Even more, I discovered two additional criteria based on mindset:
Some users seek information, others seek treatment.

This leads to four archetypes:

Goal: Solve my mental health conditions to live better.

Criteria:

• Emotional Readiness: Ready vs. Not Ready
• Treatment Readiness: Information vs. Treatment

Archetypes:

1. High Emotional Readiness — High Treatment Readiness: The treatment seeker
2. High Emotional Readiness — Low Treatment Readiness: The information seeker
3. Low Emotional Readiness — High Treatment Readiness: The stigma reliever seeker
4. Low Emotional Readiness — Low Treatment Readiness: The first-stage explorer

Understanding the emotional readiness journey

These archetypes are not isolated. They follow an evolution, a connected journey.

Linked Archetype: The first-stage explorer
Stage 1: Awareness
Insecure, gathering information, exploring whether the condition is real and affects daily life, with no expectation to engage.

Linked Archetype: The first-stage explorer
Stage 2: Understand emotions
The hardest stage. Emotions are unstructured, stigma and fear peak. Personal beliefs fight against the need for support. High engagement can push people away. They need low-engagement, self-led tools to structure emotions.

Linked Archetype: The stigma reliever seeker
Stage 3: Seek options
Once stigma breaks down and readiness grows, people compare services and make decisions based on preferences.

Linked Archetype: The information seeker
Stage 4: Engage with therapy
The person is ready to book and choose a therapist. No emotional tools needed anymore — only efficient booking and selection.

If you design only for the second archetype, you create barriers for the last one. If you design only for booking, you lose opportunities to support the first two. When designing for archetypes, avoid siloed flows.
Create a common flow with elements tailored optionally for each archetype.

Example: self-serve tools should be optional. People in early emotional stages can use them; those ready can book directly.

If you want to design for everyone, ensure you understand what “everyone” truly means.

To create strong personas, be sure to:

Select the right criteria before designing your personas.
Demographics are often not useful, but in healthcare they can matter (e.g., menopause-related design considerations).

Add quantitative data.
To gain stakeholder alignment, include percentages to prioritize design decisions. Qualitative interviews + surveys (500–1,000 responses) make persona insights credible.

Break down JTBD personas into archetypes based on needs and situations.
Define the Job-to-be-Done at the right level, then break down performers based on needs and preferences.

Example: birth experiences

• Pregnant women who feel safe in a hospital environment
• Pregnant women who feel safe in a calm, home-like environment

Both needs coexist, and both must be addressed — “AND,” not “OR.”

Create principles first, design second.
Translate core archetype needs into principles that guide design decisions.

Example principles for Stage 2 (Understand emotions):

• Normalize hesitation through universalizing language
• Safe pause to reframe leaving the flow as self-awareness, not failure
• Grounding exercises to reduce emotional overwhelm
• Structured preparation with optional journaling tools

These principles offer designers:

• Clear direction
• Inspiration
• Actionable guidance
• Confidence that design serves real needs
• Measurable outcomes tied to needs

So what:

• Personas fail when stakeholders see no value, no data, or no connection to decisions.
• Designing without personas pushes teams into an “OR” mindset, oversimplifying diverse needs.
• Strong personas require selecting meaningful criteria, often behavioural and emotional.
• Quantitative validation increases trust and organizational adoption.
• Archetypes allow designing for multiple states of readiness within the same journey.
• Mental health journeys require emotional readiness as a key axis for segmentation.
• The four archetypes (treatment seeker, information seeker, stigma reliever, first-stage explorer) reflect real differences in needs.
• Design must support an evolving journey, not isolated states.
• Avoid siloed flows; create flexible, adaptable frameworks within a shared journey.
• JTBD combined with archetypes provides deeper insight than demographics alone.
• Principles translate insights into actionable design decisions.
• Design must embrace complexity and turn it into simplicity for users.

Fredy Pascal

Principal Service Designer

Ciao ciao

The Pitfalls of Designing Without Persona was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.