Profile
Name, age range, job title, company size, and a one-line description. Give the persona a real-sounding name (not 'User A'). The profile should describe a real type of person you've talked to — not an average or a composite of everyone.
A user persona is the shared reference card for who you're building for. One board, one session, the whole team walking out with the same mental model of the user.
Build user personas at the start of a product initiative, after a round of customer discovery interviews, or whenever the team is making product decisions without a shared understanding of who they're making them for.
Personas built from real research are powerful. Personas built from assumptions are dangerous — they can anchor the team to a fictional user. If you don't have research yet, run the session anyway but label every field as a hypothesis and commit to validating it.
Name, age range, job title, company size, and a one-line description. Give the persona a real-sounding name (not 'User A'). The profile should describe a real type of person you've talked to — not an average or a composite of everyone.
What this person is trying to accomplish — professionally and personally. Goals connect to motivation: why does this person care about getting better at their job? What does success look like for them in six months? Three goals maximum.
The specific pain points this person experiences in the context relevant to your product. Quote from actual interviews where possible. The frustrations column is the most important one for product decisions — they drive purchase and adoption more than goals do.
Observable habits and patterns: tools they use, how they spend their workday, how they learn new skills, how they make buying decisions. These come from observation, not self-report — 'checks Slack first thing in the morning' beats 'says they prioritize async communication.'
One verbatim quote from a real customer interview that captures the essence of this persona's frustration or goal. This quote should be the one that made everyone in the room lean forward. Post it prominently — it's the most humanizing element of the persona.
What tools does this person actually use? What's their comfort level with new software? Are they an early adopter or a reluctant adopter? For a B2B product, this determines your onboarding approach. For a consumer product, it shapes feature complexity.
Before the session, pull relevant quotes and observations from customer interviews. Print or write them on stickies. You can't build a good persona without raw material — the session synthesizes research, it doesn't generate it.
Divide the whiteboard into sections: profile photo area, name/title, goals, frustrations, behaviors, quote, tech comfort. You're building a reference card, not a document — visual layout matters.
This is the most important section. Pull quotes from interviews, cluster the pain points, pick the top three that drove purchase consideration or churn. Frustrations first prevents the team from building a persona around their favorite customer rather than their most representative one.
Goals follow from frustrations — what are they trying to accomplish despite the obstacles? Behaviors come from observation and analytics — what do they actually do?
Debate which verbatim quote best captures this persona. The right quote makes someone who wasn't in the research sessions immediately understand the user. Read it aloud — it should land.
Snap the persona with BoardSnap. Post the resulting summary in the team's shared workspace. The persona should be the first thing new team members read and the reference point for every product decision.
A persona built collaboratively on a whiteboard has buy-in that a Figma file doesn't. When engineering builds the persona alongside design and product, everyone owns it. The physical act of writing, arguing, and placing stickies produces shared understanding that a read-only document cannot.
Personas are reference tools — they need to be accessible at the moment of a decision, not buried in a Figma library. BoardSnap reads the full persona card and outputs a clean structured summary that lives in the team's notes, gets pasted into PRDs, and gets snapped again as it evolves through research rounds.
One to three for most products. If you have more than three, you're either targeting too broad a market or you're not making hard choices about who you're primarily building for. Each additional persona dilutes focus. Start with one — the person who most urgently needs what you're building — and add only when the first one is validated.
The primary persona is who you design for when you have to make a choice — when a feature can't serve everyone equally, the primary persona wins. Secondary personas are real user types you care about but whose needs don't take precedence in conflicts. Most products can manage one primary and one secondary persona without losing focus.
Well-built personas are composite archetypes built from patterns across multiple real customer interviews — not a single person and not a demographic average. If your persona describes only one specific customer, it's too narrow. If it describes everyone, it's too broad.
Revisit after every significant round of customer research — typically quarterly for an active product. Snap each revision with BoardSnap so you have a history of how your understanding of the user evolved. Personas that never change suggest the team has stopped learning from customers.
Yes, but B2B products typically need multiple personas for the buying committee — economic buyer, end user, IT admin, and champion. Each plays a different role in the purchase and usage journey. Map them separately; they have very different goals and frustrations.
No exporting, no transcription. Snap the board, get the action plan.