user-persona-discovery

name: user-persona-discovery description: 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. license: MIT license metadata: skill-author: dacb@uw.edu

User Persona Discovery

Overview

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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

Resources

references/user-persona-examples.md