Structured personas grounded in Jobs-to-be-Done and behavioural frameworks. Six inputs in, a fully-formed persona out — quote, motivations, frustrations, behaviours, accessibility considerations, triggers, and a JTBD statement.
Fill in what you know about the audience. The model grounds the output in JTBD and observable behaviours, not personality archetypes.
Most personas designers inherit are unusable. They're glossy one-pagers full of demographics that don't change a single design decision. "Sarah, 34, two kids, lives in Bristol, drinks oat lattes" — none of which tells you whether her form fields should be larger, whether she'll trust an unverified review, or whether your error message is too cold.
Useful personas focus on three things, in this order:
The model behind this tool runs on Google Gemini, but the structure is anchored in published frameworks rather than vibes:
Treat the generated persona as a strong first draft, not a finished artefact. The model is good at structure and observable specificity, but it doesn't know your particular research, edge cases, or proprietary segment data.
What we'd suggest:
Age, location and family status rarely drive design decisions on their own. Where this tool includes them, they're context, not the substance. The substance lives in the behaviours and JTBD.
Most stakeholder-generated personas describe the user the team wishes they had. The output here is intentionally a little inconvenient — it surfaces real frustrations and trust hesitations rather than smoothing them over.
If you're using a single persona to represent a product with millions of users, you're flattening the dataset until it's useless. Generate two or three and let them disagree.
Once you have a persona, the natural next moves are an empathy map for the same user (says, thinks, does, feels) and an accessibility audit on the surfaces they'll actually touch. The same Gemini-grounded approach runs through all the tools.
Run the generator a few more times on adjacent segments. Personas earn their keep when they disagree with each other.
The category of "user persona" has taken a legitimate beating over the past decade. Too many personas ended up as fabricated demographic caricatures pinned to a wall, cited once at project kickoff, and never referenced during the actual design decisions they were meant to inform. The failure mode is real. But the reaction — abandoning personas entirely — throws out a genuinely useful thinking artefact along with the bad practice.
This generator produces personas designed to be used, not framed. Each persona names the specific job the user is hiring the product for, the alternatives they're weighing, the trigger that brings them to the moment of decision, and the anxieties they carry into that moment. Those four attributes drive design decisions in a way that "35-year-old marketing manager in London" never has.
Demographics as personality. Personas that reduce a person to age, gender, income and job title. These attributes rarely predict behaviour on a specific product, but they anchor the team's mental model in ways that quietly bias every subsequent decision. Prefer behavioural, contextual and motivational framing.
Aspirational rather than observed. Personas describing who the team wishes was using the product rather than who is. The team ends up designing for a hypothetical ideal user while the actual user base disengages.
One persona to rule them all. The composite persona built to represent "the average user." Almost no user is average. A single persona hides the disagreement between real user segments, which is exactly where product prioritisation decisions should be made.
Static across contexts. The same persona applied to onboarding, mid-funnel, and post-purchase. Users behave differently across contexts; a persona that doesn't distinguish is unfit for design decisions at any specific moment. Pair the persona with an empathy map per critical moment for the missing dimension.
Fabricated at kickoff, never revisited. Personas built once at project inception and never revisited against real research or behavioural evidence. Personas are hypotheses; they need testing and updating like any hypothesis. See the longer read on persona mistakes for the recurring failure patterns.
Generate three to five personas covering distinct segments — not one persona covering an averaged blend. Adjacent generations should disagree with each other in useful ways: different jobs-to-be-done, different anxieties, different alternatives on their shortlist. If two generated personas look substantially similar, they are the same segment; drop one and generate a genuinely different one.
Treat AI-generated output as a scaffold, not a finished artefact. The scaffold is useful because it forces you to state assumptions in specific terms — but every persona should be pressure-tested against real research before informing design decisions. Interview five real users in each segment, then edit the persona against what those interviews surface. The generator provides the starting draft; user interviews provide the truth.
Personas pair with empathy maps (per-moment emotional and cognitive detail), user interviews (the primary evidence source for validating personas), wider UX research methods (the toolbox for gathering the observations behind them), and AI-assisted UX research (where AI helps in the persona workflow, and where it introduces risk).