Design for a person, not an average
When a team designs for “the user,” everyone pictures someone different and the product drifts. A user persona fixes a shared, memorable picture — a named individual with real goals, frustrations, and habits — so design and marketing decisions can be checked against a concrete person. This builder turns your research into a clean persona card.
What a persona card contains
A well-structured persona card has distinct sections that serve different audiences on the team:
| Section | Purpose |
|---|---|
| Identity (name, role, age, location) | Makes the persona memorable and human |
| Goals | Tells engineers and designers what success looks like for this user |
| Frustrations | Reveals where the product can create relief or differentiation |
| Behaviors | Describes how this person actually works — tools, habits, frequency |
| Preferred channels | Guides marketing on where to reach this person (email, social, video, etc.) |
| Representative quote | A one-line distillation of the persona’s mindset, in their own voice |
| Primary / secondary tag | Tells the team who the product is optimized for first |
This builder assembles all of these into a single, copy-ready card.
How it works
You enter the persona’s identity (name, role, age, location), then their goals, frustrations, behaviors, and preferred channels, plus a representative quote in their own voice. The tool assembles these into a structured persona card with clearly labelled sections and a photo-placeholder note (use a stock or illustrated avatar, never a real customer photo). It also tags the persona as primary or secondary so the team knows which user the product optimizes for first. The result is copy-ready for a design brief, pitch deck, or marketing plan.
Grounding personas in real research
The most common persona mistake is invention: building a persona from assumptions rather than evidence. An invented persona can feel specific while misleading an entire roadmap.
Strong sources for persona data:
- User interviews — 5 to 8 interviews per segment often reveal recurring patterns in goals and frustrations
- Support tickets — verbatim complaints reveal real frustrations better than surveys, because users describe problems in their own words
- Analytics — behavioral data (paths, drop-offs, usage frequency) reveals what users actually do, not what they say they do
- Sales call recordings — objections and questions reveal the mental model of a buyer before and after purchase
What makes each field effective:
Goals: Be specific. “Save time” is too vague. “Approve a purchase order without chasing four people” is a usable goal that engineering and design can build toward.
Frustrations: Distinguish frustrations with the current solution from frustrations with the problem category. “Our current tool requires a CSV export just to filter” is more useful than “our tools are slow.”
The representative quote: This is the highest-value field. A line like “I don’t want to learn another tool — just show me the answer” conveys an entire mindset in one sentence and helps the team make dozens of small decisions consistently.
How many personas?
Most products need three to five primary personas. Too many and the team cannot hold them in mind during decisions; too few and real differences between user types get averaged out. Mark exactly one persona as primary — the user the product is most optimized to serve. If everything is primary, the designation is meaningless.
Secondary personas are real users the product must not break, but they are not the design target. For example, a product built primarily for individual contributors might list managers as a secondary persona — their needs matter for buy-in, but individual contributor workflows take priority in tradeoffs.
The persona card is copy-ready for design briefs, pitch decks, onboarding documents, and marketing plans. Your persona data exists only in your browser — nothing is stored or transmitted.