Stepping into the world of product development, whether as a UX Researcher, Product Designer, or Product Manager, you will inevitably encounter the concept of “Personas.”
In this article, I will briefly introduce the psychological origins of Personas and share some common mistakes when using them in UX, based on both theory and practical experience.
By addressing common misconceptions and real-world practices, I hope to help you build a more solid and nuanced understanding of Personas.

Preface

This is an article I’ve been wanting to write for a long time.
While interviewing candidates or discussing portfolios with mentees, I’ve often noticed common mistakes that unfortunately undermine the power of Personas.
Funny story — there was even a night when I couldn’t fall asleep because I was overthinking how to open this piece.
I even considered starting with a reference to the Persona game series (yes, I’m that much of a nerdXD)… and then, well, the idea got postponed for almost a year.

Today, I’m finally gathering my thoughts and hitting “Publish.”
And honestly? I’ve completely forgotten the “brilliant opening” I was losing sleep over.
So let’s just dive right in.

From Latin “Masks” to UX: The Evolution of “Persona”

While I’m not a psychology major, there are plenty of great resources that explain Jung’s theory of “Persona” more thoroughly.
Here, I’ll share my somewhat nerdy interpretation of its core idea.

The word “Persona” comes from Latin, originally meaning “mask.”
Renowned psychologist Carl Jung used it metaphorically to describe the different roles we present in various social contexts.
In short, a Persona is not our true self — it’s the version of ourselves that we show to the world.

For example, at home, I — “Iju” — might just be scatterbrained mom’s helper.
At work, however, I switch to a different Persona: more diligent, passionate about research, and (hopefully) good at analysis.

If you’ve played the Persona game series (highly recommended, by the way — or you can check out the Persona 5 anime adaptation, full of psychological concepts >///<), you’ll probably feel this concept vividly:
In the game, each character suppresses a part of themselves because of personal struggles.
When they finally confront and accept their true feelings, they awaken and summon their Persona — a manifestation of their true inner self.

Given how closely UX and psychology are intertwined, it’s no surprise that the term “Persona” was borrowed into UX design.
In UX, a Persona represents a fictional yet research-based archetype of your key users.

So the “Personas” we refer to here are firmly within the UX field — no need to worry if you’re not deeply versed in Jungian psychology. 😛

One simple and clear definition I like comes from Nielsen Norman Group:

Personas are fictional characters, which you create based on your research in order to represent the different user types that might use your service, product, site, or brand in a similar way. – Personas Make Users Memorable for Product Team Members, by Nielsen Norman Group

In short: From psychology to UX, “Persona” has evolved, but its core spirit remains —
It helps us bridge the understanding between different facets of our users.

5 Common Mistakes When Using Personas

Now, let’s circle back to the UX field. When we talk about “Personas” in UX, we generally mean the types of target users.
To put it simply:
Imagine you have 1,000 users interacting with your product. Each of them may differ by demographics, lifestyle, habits, and motivations. By creating Personas, we group and represent the most critical segments among these diverse users.

So, what exactly should a Persona include?

Honestly — it depends.

It all comes down to how you define the critical distinctive features that effectively differentiate your user groups (we’ll talk more about this in Mistake #4). In general, Personas often include:

• Demographics: Basic user info like age, gender, income, marital status, etc.
• Behavioral patterns: Product usage frequency, preferences, shopping habits, etc.
• Psychological motivations: Usage purposes,Jobs-to-be-done, etc.
• Needs and pain points: Core challenges and unmet needs
• Goals and expectations: What users aim to achieve with the product

Mistake 1 – Assuming Only One Persona Is Enough

In some portfolio presentations, I often see candidates list only a single Persona.
Now, I’m not saying it’s impossible to have just one Persona — if your product targets a very niche group, one Persona might be sufficient.
However, in most cases, having only one Persona is highly unlikely.

Take coffee shop customers, for example:
Are all customers the same?
Some sit there working or studying for hours;
some gather in groups to chat;
some just rush in for a quick coffee to power through the afternoon slump.
Even just by looking at their intentions, their needs are very different.

Thus, in reality, most products require multiple Personas to accurately reflect user diversity.

If a candidate clearly states during an interview that they’re only showcasing one Persona for simplicity, that’s totally fine. What worries me is when people don’t seem aware that multiple Personas should exist at all.

You might wonder — then how many Personas should we create?

In practice, statistical methods like Clustering Analysis can help determine the ideal number of Personas.
That said, a typical working range is 3 to 5 Personas:

• Too many = overwhelming and hard to apply effectively
• Too few = unable to meaningfully distinguish between user types

Mistake 2 – Confusing Target Audience with Persona

Another common mistake: Confusing Target Audience with Persona.

You often see statements like:

“Our Persona is women aged 20-40, working professionals.”

What they probably meant to describe was their Target Audience — but that’s not the same as a Persona.
(And often, this confusion overlaps with Mistake #1.)

A useful distinction comes from Target Audience vs. Buyer Persona—What’s the Difference?

A target audience is a list of demographic and psychographic traits shared by a business’s typical customers.

Buyer personas differ from target audiences in that they are much more focused. Whereas a target audience defines a crowd of customers, a buyer persona zooms in to look at specific members of that crowd.

I personally interpret it this way:

Target Audience represents the “average traits” of the target group, often based on demographic descriptions.
Persona, however, captures the “distinctive differences” within the group — based on deeper research and analysis, representing real, nuanced user archetypes.

See the difference?

Describing your users as “20–40-year-old working women” gives you an overall snapshot. But a proper Persona would dig deeper:

• How do their goals, behaviors, or pain points differ?
• What different user types exist within this demographic?

Mistake 3 – Creating Imaginary Personas

This is arguably the most common issue I see: Personas created purely from imagination.

During interviews, if a candidate doesn’t have real-world industry experience yet, it’s understandable if they present a hypothetical Persona (what we often call a Proto-Persona).
In these cases, we usually won’t be too harsh — although candidates who conducted actual user research definitely earn extra points!

However, if the portfolio is showcasing a Persona for a real product that’s already in use,
then relying solely on an imagined Persona becomes a much bigger red flag.

You might ask:

Wait, didn’t Nielsen Norman Group define Personas as “fictional characters”?
If they’re fictional anyway, why can’t we just make them up?

The key lies in the second half of their definition:

“…based on your research.“

In UX, Personas should be derived from actual understanding, research, and analysis of your users. Whether through qualitative research, quantitative surveys, or a mixed-methods approach, a credible Persona must be grounded in real user data.

This situation reminds me of a concept in linguistics called “Armchair Linguistics” —
In the past, some linguists made theoretical claims about language based purely on their imagination and intuition, without conducting any real fieldwork or analyzing authentic language data. As a result, their findings often remained in the realm of speculation, unable to accurately reflect reality.

Similarly, when Personas are purely imagined without research validation, they can never truly represent actual user behavior or needs.

(In my next post, I’ll share a real-world project where we built Personas grounded in user research — stay tuned! 🙂)

Mistake 4 – Flashy but Useless Personas

Suppose you’ve correctly distinguished Personas from Target Audiences, and you’ve successfully used research and analysis to build multiple user Personas. Congratulations!

But — sometimes, another problem sneaks in: Personas that look fancy but aren’t actionable.

Let’s look at a simplified example (note: not all fields are shown):

	Remote worker	Social gatherer	Office worker
Name	Lisa	Joel	David
Age*	36	62	48
Zodiac sign	Aries	Virgo	Aquarius
Gender	Female	Male	Male
MBTI	INTJ	ENFP	INFP
Visit time*	10:00 – 18:00	14:00 – 16:30	13:30 – 15:00
Psychological motifcation*	Needs a focused environment away from home	Wants a lively yet loud gathering space	Needs caffeine boost to stay alert after lunch

At first glance, it looks rich and detailed, right? But if you pay closer attention, only a few fields (marked with *) truly help distinguish these user types:

• Age: Might hint at life stages (e.g., retirement), but beware of relying on stereotypes without proper validation.
• Visit Time: Tightly linked to their psychological motivations (e.g., post-lunch drowsiness for office workers).
• Psychological Motivation: Crucial for identifying needs, pain points, and even driving service design.

Meanwhile, fields like:

• Gender: Could be relevant if gender significantly influences behavior (not in this case).
• Name: Helps humanize the Persona (good to keep).

But information like:

• Zodiac Sign
• MBTI type

…adds unnecessary noise.
Unless research directly shows these traits meaningfully impact user behavior, such details are distracting rather than helpful.

Similarly, in your Persona profiles, apart from humanizing details like name, gender, or photos,
non-critical traits should be left out.

Why?

• They may cause misinterpretations — for example, falsely believing that MBTI types meaningfully influence user behavior.
• They obstruct quick reading — making it harder to instantly distinguish between different Personas.

If you’ve studied linguistics, this principle is very much like Semantic Feature Analysis or Phonetic Feature Analysis:
When we want to differentiate two concepts, we emphasize their differences, not their similarities.

If you’re curious, I explored this idea more in my earlier blog post (“The Great Dumpling Battle — Northern Zongzi vs. Southern Zongzi“).

Here’s a simple linguistic analogy:
For example, let’s say a friend asks: “What’s the difference between an alligator and a crocodile?”

	Alligator	Crocodile
Reptile	+	+
Aquatic	+	+
Snout shape = U	+	– (V-shape)
Habitate in freshwater	+	– (Brackish/saltwater)
Teeth visible when mouth closed	–	+

You’ll notice — we don’t need to state the obvious (both are reptiles, both live near water).
The critical differences lie in their snout shape, habitat, and tooth visibility.

Similarly, when building Personas: Don’t overload them with common traits. Focus on clearly highlighting what sets each user group apart, so stakeholders can quickly and accurately grasp key distinctions.

Mistake 5 – Personas Without Actionable Outcomes

If you’ve avoided all the earlier common mistakes— congratulations! You likely have a well-crafted Persona.

Now for the final mistake: Treating Personas as a portfolio checkbox, without connecting them to actionable outcomes.

What do I mean by that?

If your Personas were created for product design purposes, they should naturally lead to tangible design actions.

For example:

• Remote worker Lisa: Provide quiet working zones, integrated power outlets, and strong Wi-Fi.
• Social gatherer Joel: Set up clusters of four-person tables for groups, separated from quiet zones.
• Office worker David: Open extra takeaway counters during peak hours for quick coffee pickups.

If your Personas are being applied to marketing purposes, they should guide targeted marketing strategies.

• Remote worker Lisa: Promote second-cup discounts for long-stay customers.
• Social gatherer Joel: Offer drink-and-dessert bundle discounts for afternoon group gatherings.
• Office worker David: Launch “buy 3 get 1 free” caffeine drink promotions for office workers.

If your Personas are actionable, they empower teams to better understand user needs — and translate that understanding into real business results.

Final thoughts

In this article, we explored:

• The psychological origins of Personas
• How the concept evolved in the UX field
• 5 common mistakes to watch out for when creating and using Personas

Here are some recommended resources if you want to dive deeper:

• Personas: Study Guide
• Personas Make Users Memorable for Product Team Members
• Why Personas Fail
• User Personas for UX, Product, and Design Teams
• Target Audience vs. Buyer Persona—What’s the Difference?
• Make your personas great again in 7 simple steps

Next, I plan to share my personal experience building research-driven Personas from scratch, and common challenges along the way. (If I don’t procrastinate again… XD)

Thanks for reading:D

If you enjoyed this article, feel free to buy me a coffee — and a treat for my lovely dog Lottery! 🐾