Creative user persona discovery through ideation and exploration. Use for open-ended brainstorming sessions to elucidate and reveal user personas for cultural probes in research through design. This is useful for settings for thinking about a range of user personas that might be relevant to a design process.
User personas are research-based representations of key user groups that guide design, engineering, and decision-making. They are not fictional characters invented for creativity, but analytical tools grounded in evidence that help teams maintain a consistent focus on real user needs, goals, and constraints. This approach is complemented by a brainstorming approach via a conversational process for generating ideas, challenge assumptions about users personas and avoid sterotyping. Apply this skill for creative generation of user personas in a conversation form.
When to Use This Skill
This skill should be used when:
Generating novel research ideas or directions
Exploring interdisciplinary connections and analogies
Challenging assumptions in existing research frameworks
Developing new methodological approaches
Identifying research gaps or opportunities
Overcoming creative blocks in problem-solving
Brainstorming experimental designs or study plans
Core Principles
Related Skills
Evidence based
Ideally, these personas are based in evidence, but this approach requires you to imagine who might be consulted for interviews and digital probes.
Principle: Evidence bases should be used where possible vs. the imagination.
Goal-Oriented
At their core, personas represent what users are trying to accomplish, not just who they are.
Effective personas clearly articulate:
Primary and secondary goals
Success criteria from the user’s perspective
Motivations and values that shape decisions
Demographics are secondary to intent.
Principle: Design should optimize for user goals, not user traits.
Behavior-Centered
Personas focus on observable behaviors rather than abstract characteristics.
This includes:
How users interact with systems
Workflows and decision strategies
Coping mechanisms, shortcuts, and workarounds
Responses to constraints such as time, risk, or uncertainty
Principle: What users do matters more than what they say they prefer.
Representative, Not Exhaustive
A persona represents a meaningful user archetype, not every possible user.
Well-constructed personas:
Capture dominant patterns across many users
Abstract away irrelevant variation
Prioritize distinctions that affect design decisions
Too many personas dilute focus; too few oversimplify reality.
Principle: Personas trade completeness for clarity.
Contextually Grounded
Personas exist within specific contexts of use, including:
Physical, social, and organizational environments
Technical and regulatory constraints
Cultural norms and institutional practices
Without context, personas become generic and non-actionable.
Principle: Users cannot be understood outside the situations in which they act.
Actionable for Design Decisions
A persona is only valuable if it changes decisions.
Effective personas:
Highlight tensions, tradeoffs, and unmet needs
Inform requirements, feature prioritization, and evaluation
Enable teams to ask, “What would this persona need here?”
If a persona cannot be used to justify or reject a design choice, it is incomplete.
Principle: Personas exist to support action, not documentation.
Internally Coherent and Plausible
Each persona must present a consistent logic linking goals, behaviors, constraints, and motivations.
Contradictions should be intentional and explained (e.g., competing incentives), not accidental.
Principle: A persona should feel inevitable given its constraints.
Explicit About Assumptions and Limits
Personas always simplify reality. High-quality personas make this visible by:
Stating the data sources used
Identifying assumptions and uncertainties
Clarifying which populations are not represented
This transparency prevents misuse and overgeneralization.
Principle: Responsible personas acknowledge what they do not capture.
Living Artifacts
Personas are not static deliverables.
They should evolve as:
New data becomes available
Systems, users, or contexts change
Design questions shift over time
Principle: Personas are hypotheses that can be refined, not truths to be preserved.
Conversational Workflow
Phase 1: Align on Purpose
Conversation 1: Why Do We Need Personas Now?
Questions
What design decisions are we currently blocked on?
What do we disagree about regarding users?
What would a better understanding of users allow us to try or stop trying?
Capture decisions personas should inform (e.g., requirements, tradeoffs, evaluation criteria)
Output
A short statement:
“These personas exist to help us decide ______.”
Phase 2: Share Evidence, Not Opinions
Conversation 2: What Have We Actually Observed?
Each team member answers, in turn:
What user interactions, data, or experiences am I drawing from?
What surprised me?
What felt inconsistent or unresolved?
Rules
No interpretation yet
No persona names
No solutions
Artifacts
Markdown document with:
Observed behaviors
Goals expressed or implied
Constraints and workarounds
Emotional or cognitive tensions
Phase 3: Cluster and Name Patterns
Conversation 3: What Patterns Are Emerging?
Cluster observations by behavior and goal
Ignore demographics unless they directly affect behavior
Ask:
“If we designed for this cluster, what would change?”
Key Question
Are these differences meaningful for design?
Artifacts
2–4 candidate persona clusters, each defined by:
Core goal
Dominant behaviors
Primary constraints
Phase 4: Construct Persona Hypotheses
Conversation 4: Who Is This Persona, Really?
For each cluster, the team collaboratively answers:
What is this persona trying to accomplish?
What do they optimize for (time, safety, accuracy, cost, autonomy)?
What do they avoid?
What breaks when the system doesn’t support them?
Required Tension Question
What internal conflict does this persona live with?
Artifacts
Output (Draft Persona)
Name (functional, not cute)
One‑sentence goal statement
Behavioral summary
Key constraints
Design implications
Phase 5: Stress-Test with Design Scenarios
Conversation 5: Would This Persona Change Our Design?
Run 2–3 realistic scenarios:
How would this persona use our current design?
Where would they struggle?
What would they do instead?
Critical Question:
If this persona disappeared, would our design change?
If not, revise or discard.
Phase 6: Make Assumptions Explicit
Conversation 6: What Are We Guessing?
For each persona, identify:
Evidence sources
Weak or missing data
Assumptions carried forward
Label each persona with:
High confidence
Medium confidence
Exploratory
Phase 7: Reflect and Reposition
Conversation 7: What Did We Learn by Doing This?
Team reflection prompts:
How did persona construction reshape our understanding of the problem?
What surprised us?
What design questions became sharper?
Document:
How persona creation itself changed the design space