TL;DR
Personas, or user-role models, turn fragmented and sometimes contradictory research findings into concrete, empathetic representations of typical target users for product development and business strategy. A useful persona is not a meaningless “average user” invented from intuition, nor a decorative collection of attractive model photographs in a marketing presentation. It must be rooted in field research, user interviews, and behavioral event logs, clearly representing the audience's goals, pain points, capability limits, and decision-making paths. JVDS emphasizes that effective personas can anchor endless product and engineering debates, grounding every interaction trade-off in the objective question: whose specific problem are we solving?
1. From an Indistinct Audience to a Concrete Person: The Strategic Value of Personas
Without concrete personas, the most common product-planning mistake is that everyone assumes they are the user:
A Model for Building Personas and Connecting Them to Decisions
- Stage one: qualitative field research through in-depth interviews and real-world shadowing: Leave the air-conditioned meeting room. Use frontline interviews and unobtrusive shadowing to record actual behavior, authentic quotations, and operational blind spots.
- Stage two: quantitative validation through event clustering and behavioral evidence: Combine extensive production event logs with behavioral clustering to test qualitative assumptions against objective data and remove isolated extreme biases.
- Stage three: synthesize concrete roles with clear goals and pain-point boundaries: Reject the empty average person. Condense dispersed evidence into typical roles with specific names, clear business objectives, cognitive barriers, and defined hardware and software constraints.
- Stage four: use personas as a decision standard for features and priorities: Make personas an anchor for product and engineering teams. Every feature addition, removal, or scheduling decision should explicitly identify the role and pain point it serves.
- Three intertwined roles in a toy store: A typical online toy shop involves a network of very different yet mutually constraining roles:
- Amanda, a seven-year-old pupil and the person expressing desire: She has no credit card and may not understand complex checkout explanations, but she has a powerful wish for the product. She needs playful large-image presentations, video demonstrations, and a wishlist that lets her send favorite toys to her parents in one action.
- Gloria, a 34-year-old mother working part-time and the decision-maker and payer: She is exhausted and short of time while juggling school runs and household work. She does not visit to browse aimlessly. She wants to check safety certifications quickly, complete one-step checkout, and have access to mechanisms that limit excessive use and protect eyesight.
- Charles, a 66-year-old retired grandfather who occasionally buys gifts: He has a generous budget but little idea which toys are currently popular, and online shopping makes him anxious. He needs gift guides organized by age and a human customer-service telephone line that is easy to reach.
- The design lesson: A site built only around the average visitor's needs becomes an incoherent mixture: it does not engage Amanda, it feels cumbersome to Gloria, and it leaves Charles lost.
- Reject the empty abstraction of an average person: Personas replace abstraction with specificity. Asking whether users like a button can trap a team in subjective debate. Pointing to a persona and asking, “Can Gloria understand this message in the 30 seconds she is stopped at a red light while driving one-handed?” gives the discussion a concrete basis for agreement.
- A rule of thumb of three primary and up to four supporting personas: Too many roles undermine persona building. Within a particular version of a digital system, primary personas should not exceed three, and secondary personas should be kept to three or four. Beyond that cognitive limit, the personas risk becoming documents that no one uses.
2. Where Persona Practice Becomes an Empty Formality
In many large internet companies and traditional digital transformation projects, personas become an unproductive box-ticking exercise:
2.1 Essay-Like Personas Filled with Irrelevant Personal Trivia
Many persona cards read: “Li Lei, 28, Taurus, enjoys jazz and steak on weekends, and owns a corgi.” Yet the product is an enterprise tax-filing system. Designers spend 80% of the document on melodramatic lifestyle details and say nothing about the thousands of invoices he imports each month, the financial software he uses, or the audit penalties he fears. A persona detached from the business context serves only its creators.
2.2 Invented, All-Capable Superhuman Personas
Some product managers have never met a real customer. Working entirely from the meeting room, they invent someone who knows more than a dozen advanced algorithms, enjoys spending two hours every day providing software feedback, and has unlimited money and patience. A system designed for this fictional perfect angel will be rejected by actual users when it reaches the market.
3. A Four-Dimension Matrix for Professional Personas in Product Development
To help teams separate useful evidence from superficial detail and focus on business and experience value, we use the following four-dimension filter:
| Evaluation dimension | Frequent core functions or assets | Infrequent but necessary functions or assets | Redundant distractions, superficial functions, or formalities |
|---|---|---|---|
| Business goals and core motivations | Focus completely on the role's nonnegotiable goal in the current context, such as completing a batch reimbursement within 30 seconds | Explain reporting relationships and upstream and downstream collaboration dependencies | Describe zodiac signs, blood types, pet preferences, and other personal details unrelated to the business |
| Pain points and cognitive boundaries | Record real fears and friction, such as anxiety about deleting an entire dataset with the wrong click | Document everyday hardware and software conditions, such as an old Windows 7 browser or a weak connection | Assume an engineer's mental model of computing and the ability to troubleshoot low-level system error codes |
| Persona presentation and concision | Use a one-pager that can be read within one viewport, prominently highlighting core pain points and memorable quotations | Attach traceable interview-recording codes and quantitative sample-reference links | Produce a dry, lengthy report of dozens of pages that the team puts away and forgets |
| Closing the loop with design decisions | Explicitly identify “serves persona X” in the requirements document for each major feature addition or removal | Provide clear, lightweight fallback solutions for peripheral secondary personas | Forget the personas once finished and let subsequent meetings be decided entirely by leadership intuition |
4. JVDS Practice: Building Comprehensive, Empathetic Personas
In the high-end digital experiences and business-strategy UI/UX design that JVDS develops for enterprises, personas are designed to be practical decision-making tools:
- Triangulate evidence from the real working environment: JVDS rejects the simple assembly of secondhand information. Our researchers combine in-depth interviews, unobtrusive on-site shadowing, and clustering of production event logs to capture authentic quotations and operational blind spots. Each persona we produce connects to dozens of hours of detailed recordings and millions of real interaction events, giving it a strong objective basis.
- Simulate conflicting roles in a persona matrix: Our distinctive approach includes a Persona Battle Arena. We place roles with naturally conflicting interests—such as a risk officer demanding compliance and a salesperson seeking near-instant loan issuance, or a child wanting more toys and a cost-conscious mother—within the same workflow and test their competing needs. Information architecture and separated permissions help both sides achieve mutually beneficial outcomes within one product ecosystem. Explore our design case studies to see how complex role interests can be reconciled through carefully structured experiences.
- Update personas throughout their lifecycle: Markets and people change. JVDS helps clients establish a six-monthly persona review. After a major release or a doubling of business scale, the team returns to the frontline to check whether novices have become experts and whether a younger generation brings fundamentally new habits. Personas should stay current and continue guiding business strategy.
5. Frequently Asked Questions
Q1: Should a B2B software persona focus on the purchasing executive who approves the budget or the employee who uses the product every day?
Both must be represented, but each leads at different points in the journey. On the corporate website, pricing pages, and business proposal materials, the buyer persona takes center stage, with strong emphasis on ROI, data security and compliance, and cost and efficiency outcomes. Within the software's workspaces, data-entry forms, and approval flows, the frontline user persona takes priority, emphasizing ease of use, reduced fatigue, and efficient operation. Focusing only on executives can produce software that is purchased but unused; focusing only on employees can prevent the initial sale.
Q2: Should an early-stage company with little research budget still create personas?
Yes, but start quickly with proto-personas. Bring together core founders, the sales lead, and frontline support staff for half a day. Put characteristics of real customers they have encountered on sticky notes and group them into initial role hypotheses. The important thing is to give the team a shared language from the start. Once the product launches, use actual user feedback and online interviews to refine and enrich the personas through small, fast iterations.
Q3: How can we tell whether personas are actually useful within the team?
The test is simple and demanding: do product and engineering teams regularly mention persona names in weekly meetings and disputed reviews? If discussions still revolve around “I think we should add this feature” or “Users will definitely like that,” the personas have failed. If an engineer or product manager naturally says, “Wait—this cumbersome pop-up will infuriate Gloria while she is on the school run; we cannot do that,” the personas have become part of how the organization thinks and makes decisions.
