Persona Design — Who Are You Building For?

In web production and new service launches, a policy of "want to reach a wide audience" or "want to make something anyone can use" often gets declared. These words carry no malice. But from a design perspective, they are among the most dangerous expressions for leaving target users formless.

In a BtoB portal site construction project, the client set a requirement that it should be "easy for everyone from executives to frontline staff." The result was a top page where high-level decision-making information for executives coexisted with operational manuals that frontline staff referenced daily. Pages too detailed for executives and too abstract for frontline staff coexisted, and both user groups rated it as "hard to use."

In another case, a project developing an app for a local community adopted the policy of "a design that a wide range from those in their 20s to 60s can use." When a minimal UI was adopted that people in their 20s could operate intuitively, those in their 60s found it difficult. When 60s' accessibility was prioritized, people in their 20s avoided it as "old-fashioned." Every time a feature was added, discussions about "who is this feature for" diverged, and the release was delayed by six months.

The structural problem common to these cases is "the absence of a user image that serves as the basis for production decisions." Design choices, feature prioritization, content granularity, and navigation design all fall into a state where "someone decides subjectively." As a result, decisions become person-dependent, newcomers cannot understand the rationale, and every change in direction causes significant rework.

Persona design is a method to resolve this structural problem. By defining "who we are building for" as one specific person, it creates a state where everyone involved in production can make judgments based on the same standard.

A persona is a fictional character that represents the target user. It is defined as "one specific person" whose name, age, occupation, behavior patterns, values, information-gathering habits, and challenges are concretely described.

"A company employee in their 30s" is not a persona. "Tanaka Mai, 32, living in Shinagawa-ku, Tokyo, a project manager at a mid-sized IT company. Every morning during her commute she checks news and Slack on her smartphone. She has a strong desire to learn professionally but cannot secure extended time, so she prefers content she can read in 5–10 minutes. She uses recommendations from colleagues as an important reference for decision-making" — this is closer to a persona that functions in practice.

The essential purpose of personas is "sharing decision criteria." When choosing a design, converting the question from "which is better for general users" to "which is easier for Tanaka-san to use" makes the discussion concrete. When prioritizing features, it allows judgment based on a verifiable criterion of "can Tanaka-san complete this in 5 minutes during her commute" rather than the vague standard of "features users need."

One important caution here is not to confuse personas with marketing segments or user attribute statistics. A segment definition of "30s–40s, annual income 500k+ JPY, urban residents" is effective for ad targeting but too abstract to use as a UX or design decision standard. Personas prioritize vividness as "a specific person the production team can concretely imagine" over statistical representativeness.

Also, personas are not "build-once, done" documents. They have value only when they are referenced throughout each production phase, updated, and function as a starting point for dialogue among team members.

The minimum condition for preventing personas from becoming "wallpaper" is building them from research data. Personas created from hypothesis alone only reinforce the creator's assumptions and carry a high risk of diverging from user reality. However, large research budgets are not always available. Here is a procedure for creating effective personas with minimal research.

Step 1: Collect and Analyze Existing Data

First, organize the data at hand. User attribute data from analytics tools, inquiry form submissions, existing customer survey results, and support inquiry content can all be utilized. Re-read these from the perspective of "who, seeking what, in what state, made contact."

For new projects with no existing data, collect user-generated first-party data from review sites for similar services (App Store ratings, Google Maps reviews, etc.) and statements in related hashtags or communities on social media.

Step 2: Conduct User Interviews (Minimum 3 People)

When possible, conduct 30–60 minute interviews with actual or potential users. Common patterns can be extracted from as few as three people. Key areas to focus on in interviews:

• At what point do they recognize the problem or challenge at hand?
• When searching for solutions, what information sources do they reference?
• Who is involved in the judgment and decision-making process? (especially in BtoB)
• Points of dissatisfaction with their current resolution method
• The deciding factor when choosing a product or service

Step 3: Define Required Persona Fields

Based on interviews and existing data, fill in the following fields to create the persona.

| Field | Purpose | |-------|---------| | Name, age, location, occupation | Gives concreteness for the team to vividly imagine | | Daily behavior pattern | Provides basis for context-sensitive design decisions | | Information habits and devices used | Provides basis for channel design and UI prioritization | | Main challenges and frustrations | Provides basis for feature prioritization and value proposition | | Decision-making influencers | Provides basis for content and flow design | | Goals and desired outcomes | Provides directional standard for the overall design |

Setting too many fields increases management costs and stalls updates. Limiting to required fields, at a density that fits on a single A4 sheet, is the condition for sustained operation.

Step 4: Explicitly Label Hypotheses and Set Review Cycles

Mark areas where research data is insufficient as hypotheses. Whether "views content on smartphone during commute" is based on real data or hypothesis changes the weight of the judgment. Label hypothesis sections and set a cycle of verification and updates through user testing or additional interviews as the project progresses.

Creating a persona tends to generate a sense of reassurance that "we're designing from the user's perspective." However, many projects have personas that don't function in actual decision-making. There are typical patterns for becoming "wallpaper."

Failure Pattern 1: Created Once at Kickoff, Never Referenced Afterward

Cases where a persona was created in a workshop at project start but was never referenced in subsequent production meetings happen frequently. When personas are cut off from the decision-making context, they become mere procedural artifacts.

As a countermeasure, establish as a team protocol that every design review, spec confirmation, and content selection session includes the question: "How is this for our persona [Name]-san?"

Failure Pattern 2: Converging on an 'Average User' Everyone Can Agree On

When a team creates personas in a workshop format, they tend to become "a collection of attributes no one can object to" in order to avoid disagreement. As a result, an unlifelike, middle-ground persona is born that doesn't function as a design decision standard.

A good persona, precisely because it is specific, will generate objections like "this doesn't fit this project." Personas that generate no objections whatsoever are likely too abstract.

Failure Pattern 3: Stakeholders Project Their Own Image

Cases arise where a responsible person on the client side projects their own values and behavior patterns onto the persona, on the premise that "I'm a typical user." In particular, founders and executives have strong attachment to their product or service and may advocate an image that diverges from the actual target user as the "correct persona."

Showing user interview data to build consensus, or explicitly declaring the principle "we are not the user" at project start, is effective.

Failure Pattern 4: Persona Becomes an Approval Document

The more detailed the persona description, the more time approval takes, and once approved it becomes difficult to update. Personas are tools for production decisions, not documents to be fixed after approval. Lightweight operation design premised on "explicit hypotheses" and "regular updates" is important.

In most projects, investigation reveals multiple user images. The idea that "we have to accommodate all personas" draws you back into the trap of "designed for everyone." Here is how to handle multiple personas.

Selecting the Primary Persona

First, select one primary persona. The selection criterion is "the user we most want to deliver value to in this project." Judge from both business metrics such as revenue scale, contract numbers, and usage frequency, and from the design difficulty perspective of "a design that satisfies this person guarantees the overall quality of the product."

Aim for a state where the design optimized for the primary persona is broadly acceptable to other users as well.

Handling Secondary Personas

Define the next most important user image after the primary as the secondary persona. The secondary is positioned as "accommodated within the range that doesn't break the design for the primary" and is not treated with equal priority.

For example, if the primary is a "smartphone-centered user in their 30s," setting a "desktop user in their 60s" as secondary means adjusting font size and color contrast ratios within the range that doesn't sacrifice smartphone usability.

Integrating Personas Into Production Phases

For personas to function effectively, specific reference scenes must be designed for each production phase.

• Information Architecture Phase: When laying out options for site maps and navigation structures, use "Can Tanaka-san reach the target information in 3 clicks or fewer on first access?" as an evaluation criterion
• Visual Design Phase: When presenting options for colors, fonts, and spacing, use the persona's usage context (on the go, bright vs. dark environment, sensitivity to readability) as the basis for judgment
• Content Production Phase: When choosing heading expressions and body text length and granularity, use "Can Tanaka-san read this in 5 minutes? Does this expression communicate clearly?" as the standard
• User Testing Phase: Recruit users with attributes as close to the persona as possible and use "Does this resolve the challenges the persona faces?" as the verification axis

The persona is a device for maintaining throughout the project the answer to the question "who are we building for?" The purpose is not the act of creating it, but that it continues to function as a basis for production decisions. Getting every member of the production team to hold that understanding, and building the habit of repeatedly referencing it in decision-making — that is the only way to draw out the essential value of persona design.

References

About Face 4: The Essentials of Interaction Design (2014)

Personas: Study Guide (2024)

Persona Types: Lightweight, Qualitative, and Statistical (2022)