What Are Personas?
Personas represent the different types of people who use your product. They are not individual users. Each one is a composite that captures the goals, behaviors, and pain points of a user segment.
Common examples are “Power User,” “New Hire,” “Admin,” or “Casual Browser.” Each persona has a name, an optional description for goals, context, and behaviors, and an optional color for grouping on the board.
Why Personas Matter for Story Mapping
A story map shows a user’s journey through your product. But which user? Different personas follow different paths, hit different pain points, and need different features.
Without personas, a story map assumes one generic user. Personas make the differences visible:
- Visibility. Tag cards with the personas they serve. You can see at a glance which parts of the map matter to which user types.
- Gap detection. Filter the board by persona to see their journey on its own. If a persona has few cards, you may be under-serving that user type.
- Prioritization. When deciding what to build next, it matters whether a feature serves one small persona or is critical to your primary persona.
- Cross-cutting context. Personas span journeys and steps. They give you a horizontal view across the vertical structure of the map.
How Personas Work
Creating Personas
Personas are created at the space level. Every project in that space shares the same persona definitions, so related projects use the same set of user types.
Each persona has a name, an optional description, and an optional color. Use the description for the persona’s goals, frustrations, and key behaviors. Keep it short. A few sentences is enough to remind the team who this persona is.
Associating with Cards
Once personas exist in a space, you can attach them to any story card on any project in that space. A card can have more than one persona. A login screen, for example, serves both the admin and the end user.
Persona associations appear in card details and in the MCP server’s projects_get_card_details response, so AI assistants can see which personas a card is for.
Filtering by Persona
Board views support persona filters. Select one or more personas to see only the cards for those user types. This is useful during:
- Discovery workshops. Focus on one persona at a time and walk through their journey from start to end.
- Sprint planning. See what is planned for your primary persona compared to secondary personas.
- Stakeholder reviews. Show a filtered view of the experience for a specific audience.
Best Practices
- Keep the set small. Two to four personas works well for most teams. More than that and the distinctions start to blur. If you have six or more, consider merging some.
- Name them clearly. Use short, distinctive names: “Power User” is better than “Persona A.” Some teams use real names, like “Sarah the Admin.”
- Do not over-tag. Not every card needs a persona. Infrastructure work, tech debt, and internal tooling often do not map to a user type. That is fine.
- Use colors sparingly. Persona colors work best as a quick visual cue across the board. Limit yourself to two to four colors so the board stays easy to scan.
- Revisit them periodically. Personas should change as you learn more about your users. After a round of user research, check whether your personas still match reality.
MCP Tools
Manage personas programmatically through the MCP server:
personas_list. List all personas in a space.personas_create. Create a new persona.personas_update. Update name, description, or color.personas_delete. Soft-delete a persona.cards_personas_set. Associate personas with a card.
