UX Persona Generator

What makes a persona useful

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:

1. Job to be done. The functional, emotional and social work the user is hiring your product to perform. Ideally written as "When [situation], I want [motivation], so I can [outcome]."
2. Observable behaviours. What they actually do, not what they say. "Reads three reviews on lunch breaks" beats "research-oriented".
3. Frictions and frustrations. What's failing in their current process. This is usually where design opportunities hide.

How this generator is grounded

The model behind this tool runs on Google Gemini, but the structure is anchored in published frameworks rather than vibes:

• Jobs-to-be-Done (Christensen, Ulwick) — the JTBD statement at the bottom of every output is the spine. It forces the persona to articulate functional purpose, not personality.
• Behavioural over attitudinal (Cooper, Buley) — the Behaviours section names concrete, observable actions instead of attitude labels. "Reopens the app three times before depositing" is testable; "anxious about money" is not.
• Accessibility-first signalling — every persona includes accessibility considerations relevant to the segment. This isn't decoration; it's a forcing function for inclusive design upstream of the audit.
• Digital and domain confidence ratings — two separate 1–10 scales. A user can be highly digitally fluent (uses ten apps a day) but completely uncertain in your domain (has never invested before). Most personas conflate these.

How to use the output

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:

1. Run it past one piece of real research. One transcript, one survey result, one analytics segment. If the persona contradicts the data you actually have, edit it.
2. Cut the items that don't change a decision. If a frustration wouldn't change what you'd build, it's noise. Be ruthless.
3. Pair it with the empathy map. Personas tell you who; empathy maps tell you what they say, think, do and feel in the moment of use. They reinforce each other.
4. Re-run it for adjacent segments. Most products serve more than one persona. Generate two or three and look for the tensions between them — that's where the hardest design tradeoffs live.

Common persona mistakes this tool tries to avoid

Demographics-as-personality

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.

Aspirational rather than observed

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.

One persona to rule them all

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.

What's next

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.