itk-personas

name	itk-personas
description	A descriptive model of a person (user, stakeholder, team member, etc), this tool is most often used to help a team define and understand the needs of its customer.
intent	Understand users’ needs, motivations, limitations, and capabilities. Represent the full range of diversity among stakeholders, customers, or other groups. Ensure the final product is something a human being will need or want.
type	component
phase	understand
outcome	understand
difficulty	intermediate
group_size	6+ people
time_required	45+ minutes
best_for	["Early discovery when you need to align engineering, design, and sales on who the actual target user is","Translating raw user research from interviews and surveys into shareable archetypes the whole team references","Prioritizing a backlog when competing feature requests serve different user segments with conflicting needs","Onboarding new team members or stakeholders who lack context on who the product actually serves","Pressure-testing a roadmap assumption that 'users want X' before committing engineering capacity"]
sources	["MITRE Innovation Toolkit (ITK)","https://itk.mitre.org/toolkit-tools/personas/"]

PERSONAS

What Is It

A descriptive model of a person (user, stakeholder, team member, etc), this tool is most often used to help a team define and understand the needs of its customer.

Why Use It

Understand users’ needs, motivations, limitations, and capabilities. Represent the full range of diversity among stakeholders, customers, or other groups. Ensure the final product is something a human being will need or want.

When to Use It

When exploring new ideas or potential applications.

How to Do It

1. Assemble existing research into current or potential users.
2. As needed, add your own evidence and data to the existing research by observing, interviewing, and/or profiling potential users. Be sure the cohort of users you interview represent the full diversity of your user group.
3. Build a collection of user archetypes, based on various categories of users. Give each one a specific name (e.g., Acquisition Amy), rather than a generic title (e.g., Military Technologist), and ensure each Persona represents a unique use-case. TIP: The most useful personas are specific, not general. For example, rather than creating a persona of a “military member,” specify the persona’s service (Army, Navy, Air Force, Marine), rank, specialty, level of experience, etc.
4. Add a stock photo or cartoon sketch of the described personas. You may want to add an invented quotation that summarizes a key issue, concern, or priority for the persona.

Key Concepts

Archetype vs. Stereotype — A persona is a research-grounded composite of real behaviors and goals, not a demographic caricature. Stereotypes built on assumptions produce decisions that fail the actual user base.

Goals and Motivations — The core of a persona is what the user is trying to accomplish and why, not their job title. This maps directly to Jobs-to-be-Done and drives feature prioritization.

Specificity Principle — Useful personas are narrow (rank, specialty, experience level) rather than generic ('military member'). Specificity forces concrete design tradeoffs instead of designing for an impossible everyone.

Primary vs. Secondary Personas — One persona should be the primary design target whose needs the product must satisfy; secondary personas are accommodated but never drive core decisions. Without this hierarchy, scope balloons.

Diversity Coverage — The persona set must span the real range of users — edge cases, accessibility needs, varied expertise — so the product isn't optimized only for the loudest or most convenient cohort.

Evidence Grounding — Every persona attribute should trace back to observed data from interviews, analytics, or field research. Invented quotes and traits are acceptable only as summaries of real patterns, not fabrications.