uw-ssec 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:
- The user asks to discover or create user personas
- The user asks for help brainstorming user personas
- The user asks to have a conversation about user persona discovery or creation or writing
- The user asks for help writing user personas and user stories
- Generating novel research ideas or directions that involve user personas
- Exploring interdisciplinary connections and analogies in user personas
- Challenging assumptions in user personas
- Identifying research gaps or opportunities in the context of user personas and user stories
- Overcoming creative blocks in problem-solving in user persona generation
Core Principles
- 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