# Persona Builder > Creates clear, evidence-based UX personas that represent the key user segments of a product, and a discussion guide for developing them from research. Use this whenever the user wants to create, write, structure, or improve personas, user profiles, or audience segments; needs a template or format for personas; wants to turn user research or interviews into personas; or asks who their users are and how to represent them for a design/product team. Also use to critique existing personas or convert demographic profiles into task- and goal-focused ones. Steer users away from inventing personas from thin air — push toward grounding them in real evidence. - Skill: `joaomonteiro100/persona-builder` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add joaomonteiro100/persona-builder` - Raw SKILL.md: https://api.skillmd.com/api/skills/joaomonteiro100/persona-builder/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: JoaoMonteiro100 (https://skillmd.com/u/joaomonteiro100) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/joaomonteiro100/persona-builder --- # Persona Builder A persona is a concise, believable portrait of a key user segment — a tool that keeps a team designing for real people with real goals instead of a vague "average user" (which is really everyone, i.e. no one). A good persona is a decision aid: when someone asks "would Maya actually use this?", the persona should be vivid and specific enough to answer. The main failure modes are worth naming up front, because this skill exists to avoid them: - **Personas invented from imagination.** A made-up persona launders assumptions into something that looks like evidence and is worse than none. Personas should come from research — interviews, support tickets, analytics, sales/CS knowledge, existing user data. When real research doesn't exist, say so, label the result a **provisional/assumption-based persona**, and frame it as a hypothesis to validate, not fact. - **Demographic trivia instead of behavior.** Age, gender, and a stock photo rarely change a design decision. What the person is trying to accomplish, why, what gets in their way, and how they work does. Lead with goals and behavior. - **Too many personas.** Each one you add fragments the team's focus. Aim for the 3–4 segments that matter most; it's better to serve the primary audiences well than to model everyone. ## How to build personas ### 1. Ground them in evidence Start from whatever the user actually has: user interviews, usability sessions, survey data, analytics, support/sales insight, or notes from people who talk to users. Identify the **distinct behavioral patterns** — clusters of people who approach the product with similar goals, contexts, and frustrations. Personas come from those clusters, not from demographic buckets. If the user has **no research**, help them anyway — but this is the moment where personas most often go wrong, so handle it deliberately: - Label the output clearly as **provisional / assumption-based**, up top, so no one downstream mistakes it for validated fact. - **Always end with an explicit, enumerated "Assumptions to validate" list** — each invented specific (a goal, a frustration, a behavior, a number) written as a concrete, testable statement the user can go confirm or kill. This is the single most valuable thing you produce for a research-free persona, and it is not optional. A blanket disclaimer ("these are illustrative") is **not** enough — it lets fabricated specifics like an invented salary or city read as facts under a vague caveat. Turn each of those specifics into a numbered assumption instead. - Point at the fastest way to test the biggest assumptions (a few interviews, a support-ticket scan, an analytics query). The rule of thumb: for a provisional persona, a reader should be able to tell at a glance exactly which parts are grounded and which are guesses to be checked. ### 2. Decide how many and which type - Limit to the **3–4 primary segments** unless there's a strong reason for more. - Distinguish **primary** personas (the ones the design must serve — if they fail, the product fails) from **secondary** ones (important but accommodated around the primary), and note any **anti-personas** (people you're explicitly *not* designing for) when that clarity helps. ### 3. Fill the persona structure Keep each persona to roughly a page — long enough to be real, short enough to be remembered. A dependable structure: - **Name + role + a one-line descriptor.** A memorable name and a snapshot ("Maya, freelance bookkeeper juggling 15 small clients"). The role/segment matters more than the name. - **A representative quote** that captures their attitude or core need in their own voice. Often the most-remembered line on the page. - **Background / context** — the situational facts that actually bear on the product: their expertise level, their environment, how the product fits their day, relevant constraints. - **Goals** — what they're ultimately trying to achieve (both the concrete task goal and the deeper motivation behind it). This is the heart of the persona. - **Key tasks / behaviors** — what they actually do with (or around) the product, and how often. - **Frustrations / pain points** — where today's experience or the problem space fights them. These map directly to design opportunities. - **Tools & alternatives** — what they use now to get the job done, including competitors and workarounds. Reveals expectations and switching costs. - **Influences / decision drivers** (when relevant) — what shapes their choices (cost, trust, speed, peers, compliance). Only include a demographic detail if it genuinely affects a design decision. Everything on the page should earn its place by informing what the team builds. ### 4. Keep them honest and useful - Base every attribute on evidence where you can; flag the ones that are assumptions. - Make them **specific** — "reconciles accounts every Friday afternoon under time pressure" beats "detail-oriented." - Separate **primary** from **secondary** so the team knows who wins in a conflict. - Revisit personas as you learn more; they're living tools, not deliverables you file away. ## Persona development discussion guide When the user is developing personas *from* research (or planning research to build them), these are the questions to work through for each candidate segment. Offer this as a working guide: - **Purpose:** What is this product for, and what are we trying to achieve with it? (Personas exist relative to that.) - **Who they are:** What's their role and relevant background? How much relevant experience or expertise do they have? - **Goals & motivation:** Why do they engage with this product or problem? What does success look like for them? What deeper need sits under the surface task? - **Behavior & context:** What do they actually do, when, where, and how often? What's their environment and situation when they use it? - **Tools & information:** What do they use today to accomplish this? Where do they get information or help? Who or what influences their decisions? - **Frustrations:** What's hardest, most annoying, or most error-prone about how they do this now? - **Technical context** (if relevant): What devices, platforms, and constraints shape how they can use the product? ## Producing the deliverables Generate personas as clean, scannable documents (default Markdown, one persona per section or file; offer `.docx` if the user wants a polished handout). Use `[placeholders]` for specifics the user hasn't supplied rather than inventing them, and clearly mark any persona built without research as **provisional** with its assumptions listed. When you do have research, tie attributes back to what the evidence supports. ## Pairs well with - **ux-usability-study** — personas define who you recruit and screen for. - **competitive-analysis** — understand the market and alternatives your personas live in. - **inclusive-design** — pressure-test personas against who they might leave out. ## Sensitivity Grounding personas in the user's **own** research — interviews, analytics, support data — is exactly right and encouraged. Personas are normally de-identified aggregates, so summarize patterns rather than carrying real individuals' names or contact details into the output. Two cautions about *other people's* material: don't reproduce a third party's copyrighted persona template, and in a generic illustrative example use fictional data, not real people's personal information.