Early in my career, I was caught in a kind of "functionalism" obsession: I believed the ultimate value of design lay in visual precision—rendering every pixel of a chart with perfect accuracy, or optimizing transaction flows for the shortest possible path. Efficiency, I thought, was the only truth.

But after years of working on large-scale data analytics systems and complex projects with strict safety and fault-tolerance requirements, my thinking underwent a fundamental shift. I came to realize that pure logical optimization, divorced from real human nature, often works against design. In a high-pressure operating environment, the shortest path may be the most dangerous one. In an information-overloaded decision context, the most precise chart may be the most confusing.

I came to understand deeply: if you cannot perceive the anxiety, desires, and cognitive limits behind the eyes on the other side of the screen, then all your design reasoning, aesthetic expression, and interaction innovation amount to nothing more than self-congratulatory noise. A designer's job is not to build perfect models in a vacuum—it's to find the most precise footing for a real, emotional, finite human being within a complex human-machine system.

This article is written to help myself and others develop a deeper understanding of user personas.

I. What Is a User Persona? (More Than Just Labeling)

A user persona is not a real person—it is a fictional archetype built from large amounts of real user data.

As defined in The Elements of User Experience: it is a character sketched from the genuine attributes of a target group—a composite prototype of real users. It clearly articulates user goals, helps us identify key needs, and defines what a product should and shouldn't do. It is also a visual communication tool that supports user-centered product decisions, design, and team alignment.

A well-built, high-quality persona should be composed of several core dimensions:

1. Basic Attributes

Start by recording the user's age, occupation, and location. This is the "skeleton" of the persona—it establishes the user's baseline cognitive context.

But more importantly, document their physical and soft environment. For example: are they operating a handheld device in glaring outdoor light, or working in a quiet multi-screen trading room? Are they using the latest flagship smartphone, or constrained by an outdated corporate intranet browser? These baseline constraints directly determine the design's "technical floor."

2. Behavioral Patterns

Behavioral patterns capture things like: "Do they prefer mobile or PC? When handling high-pressure tasks, do they anxiously hunt for shortcuts, or calmly browse through information?"

More importantly, observe their operational habits and frequency—specifically their proficiency and error tolerance:

Proficiency: Are they a "power user" processing hundreds of orders daily, or a "casual user" who logs in once a quarter?

Error Tolerance: When handling high-stakes tasks (such as large transfers or emergency system takeovers), do they tend to act quickly without looking, or do they need to confirm every single step?

3. Goals and Motivations

A user's goals and motivations aren't just "they want to buy something." What matters more is their ultimate value proposition—what is the deepest goal they want to achieve with this product? This can be broken down into functional goals, emotional goals, and motivational conflicts:

Functional Goals: The specific efficiency the user wants when completing tasks.

Emotional Goals: For example, when operating a complex analytics system, does the user need a sense of "control" and "professional competence"?

Motivational Conflict: Why did they choose your product over Excel or a competitor? What was the critical "push factor"?

4. Pain Points and Barriers

When analyzing pain points, focus on what is the biggest obstacle to completing their work—because this gets at their cognitive load and fears. Which steps leave them frustrated? Which technical terms exceed their comprehension? Identifying these barriers is where genuine design innovation begins.

II. How to Build a User Persona

In practice, there are many methodologies for building personas—and many projects use several in combination. But the overall process typically falls into four phases: qualitative discovery, quantitative validation, prototype development, and scenario simulation.

Drawing from my 8 years of experience, building personas is never about sitting in an office and guessing—it follows a concrete path:

1. Qualitative Research (Uncovering Deep Motivations)
This is the most critical step. Conduct user interviews or focus groups to gather first-hand material.

From experience: When working on financial systems, I would go observe the analyst's desk—how many windows did they have open? Were sticky notes covering their monitor? These details are more revealing than anything they'd say out loud.

2. Quantitative Validation (Eliminating Random Error)
Use surveys or backend analytics data to verify whether the findings from qualitative research hold broadly.

3. Cluster Analysis and Prototype Development
Group users with similar behavioral patterns together. Give each group a name and find a representative face.

4. Scenario Simulation
Place the persona in a specific use case. For example: "When an autonomous vehicle encounters an emergency obstacle, what emotional response would User A—a non-technical user—have?"

III. Leading Analytical Models

There are many models used in practice. The most representative ones are:

1. JTBD Model

If a persona describes "who the user is," then JTBD logic digs into "why the user would hire your product." In practice: don't just describe who your users are—describe what job they're "hiring" your product to do. This helps uncover the underlying motivations hidden beneath features.

To put this model into practice, the Job Stories formula is commonly used: When [situation/context], I want to [action/motivation], so that [expected outcome/value].

Traditional user story: "As a [user role], I want [feature], so that [value]."
(Focused on the person)

JTBD job story: "When [commuting in the morning], I want to [drink a milkshake], so that [I have something to do and won't be hungry until noon]."
(Focused on context and cause-and-effect)

2. Empathy Map Model

Developed by Dave Gray, this is a visual tool whose core purpose is to help teams shift from "bystanders" to "participants"—to genuinely immerse themselves in the user's sensory world and experience their subjective reality.

The map is typically drawn with a large circle (representing the user) surrounded by 6 quadrants:

① Hear——What is the user hearing in their social environment?
What do friends or family say? What do colleagues or managers think? What media (podcasts, social platforms) is influencing them?

② See——What does the user observe in their daily visual environment?
What does their physical environment look like (home, office, commute)? What products are their peers using? What ads and options surround them?

③ Think and Feel——The inner world—the most essential quadrant, often what users won't say aloud.
What do they truly care about? (Money, status, health) What keeps them up at night? What satisfaction would achieving their goal bring?

④ Say and Do——External behavior—what users say and do in public.
How do they describe their needs to others? What are their actual actions? (They might say they want to save money but buy expensive coffee.) What does their body language reveal (fatigue, excitement, hesitation)?

⑤ Pain——Obstacles.
What do they fear? What frustrations have they encountered completing their "job"? What is their risk tolerance?

⑥ Gain——Desires.
How do they define "success"? What solution do they dream of? What real value would achieving their goal bring?

IV. Pitfall Guide: How to Make Personas Come Alive

In practice, I've found designers easily fall into the "average user trap"—trying to create a perfectly balanced user who represents everyone. But real design often serves extreme archetypes. A system that works for both "the hyper-efficient expert" and "the impatient beginner" is what achieves true robustness.

Many designers shelve their personas once they're built—which is a real waste. Ongoing tracking and updates are essential steps that every designer should follow up on:

Reject vague generalities: Don't write information that's useless for design decisions (like "enjoys basketball"—unless you're building a sports app).

Keep it dynamic: Markets change, and so do users. During my time at Airwallex, as the cross-border e-commerce landscape shifted, we regularly revisited our personas to check their accuracy.

Bring it from the back room to the front stage: Just as I moved from back-end design to directly interfacing with clients, personas need to move from "documents" to "whiteboards." In design reviews, try stepping into the persona's shoes to challenge flawed logic.