itk-prototyping

name	itk-prototyping
description	Developing an early version of a product to convey the look (form-appearance) and feel (function-behavior); can be static or dynamic in nature but is typically built quickly.
intent	Directly evaluate user interaction with a product or design concept to shape future design directions. Assess whether or not requirements are being met. Take chances with ideas and explore “risky designs” with minimal investment.
type	component
phase	evaluate
outcome	evaluate
difficulty	intermediate
group_size	2+ people
time_required	60+ minutes
best_for	["Validating risky design assumptions before committing engineering capacity to build a feature","Testing user interaction flows when performance requirements are clear but form definition is immature","Exploring multiple solution directions in discovery before narrowing to a single PRD spec","Gathering early user feedback on look-and-feel when requirements are documented but unvalidated","De-risking 'big bet' concepts cheaply when stakeholders disagree on what the product should be"]
sources	["MITRE Innovation Toolkit (ITK)","https://itk.mitre.org/toolkit-tools/prototyping/"]

Prototyping

What Is It

Developing an early version of a product to convey the look (form-appearance) and feel (function-behavior); can be static or dynamic in nature but is typically built quickly.

Why Use It

Directly evaluate user interaction with a product or design concept to shape future design directions. Assess whether or not requirements are being met. Take chances with ideas and explore “risky designs” with minimal investment.

When to Use It

When the initial requirements and user needs have been documented but not fully validated. When performance requirements are well established but the form feature definition is still immature.

How to Do It

1. Start by filling out the “how might we…” statement at the top to define the problem and the goal of this prototype.
2. List requirements: Think back to the user needs and problem space to come up with requirements that this product needs to achieve.
3. Create vision board: What are current solutions to the above requirements? Think about products/solutions that currently exist in this space. What makes them not work for this application? Can designs from a completely different field be implemented in a novel way for this application?
4. Sketch mind map: Bring the list of requirements over into the sketch area. Do they roughly fall under “Looks Like” or “Works Like”? Start a mind map sketch to brainstorm individual features that can address these requirements. There can be multiple ways to solve a problem so feel free to write down and sketch out multiple features for each requirement.
5. Combine sketches: After having thought about individual features, explore how they would come together and integrate into a full product. How do they fit together? How would someone interact with it? Is there a particular order of operations for using this product?
6. Choose what to prototype: Is there a feature or interaction that should be explored more? What would benefit from viewing in 3D or acted out in an exercise?
7. Create paper/cardboard prototype: Gather some materials and resources that are easy to modify quickly, there are some suggestions on the worksheet. Use the prompts to think about what would be useful to physically prototype.
8. Collect feedback and make changes: Take these sketches and prototypes to the larger team and user groups to gather feedback. Iterate on the idea and design to mature prototype.

Key Concepts

Look-Like vs. Works-Like — Separating form-appearance (look) from function-behavior (works) lets you prototype each dimension independently. A foam mockup answers ergonomic questions while a clickable flow tests interaction logic — building both into one artifact wastes effort.

Fidelity — The degree of detail and realism in a prototype, ranging from paper sketches to interactive mockups. Match fidelity to the question being asked; high fidelity too early invites bikeshedding on polish instead of validating the core concept.

Prototype vs. MVP — A prototype is a throwaway learning artifact built to answer a specific question; an MVP is a shippable, minimal product that delivers real value. Conflating them leads to over-investing in code you intend to discard.

Risky Design Exploration — Deliberately testing the most uncertain or unconventional ideas first, where failure is cheapest. This front-loads learning and prevents discovering a fatal flaw after expensive development.

How Might We Framing — An opening statement that scopes the prototype to a specific problem and goal. Without it, prototypes drift into solving everything and produce diffuse, uninterpretable feedback.

Iterative Feedback Loop — The cycle of building, showing to users/stakeholders, and refining. Each loop should test one hypothesis so you can attribute feedback to a specific design decision.

PM Applications

• Build a low-fidelity clickable prototype during a discovery sprint to validate a user story flow before writing acceptance criteria in the backlog.
• Create paper or cardboard mockups to demo competing design directions in a roadmap review, letting stakeholders react to tangible options instead of abstract descriptions.
• Test risky interaction patterns with target users before committing them to a PRD, then attach validated prototype findings as supporting evidence in the spec.
• Use a vision board of competitive solutions during PAINstorming or problem-framing sessions to clarify what gaps the product must close.
• Prototype the look-and-feel for an executive briefing to align teams with conflicting priorities around a shared, concrete vision.
• Run a prototype walkthrough during backlog grooming to expose hidden requirements and missing edge cases before stories are estimated.

Benefits

• Encourages an experimentation mindset so you can test out ideas before implementing them Can be as lightweight or as complex as you need it to be

Common Pitfalls

• Building a high-fidelity prototype too early, which triggers stakeholder debates about colors and copy instead of validating whether the core concept works.
• Treating the prototype as a mini-MVP and writing production code, then feeling pressure to ship the throwaway artifact instead of discarding it after learning.
• Skipping the 'how might we' framing, so the prototype tries to demonstrate everything and yields vague feedback you can't act on.
• Showing the prototype only to internal stakeholders and never to actual users, producing confirmation bias rather than genuine interaction validation.
• Prototyping the easy, well-understood features instead of the riskiest assumptions, leaving the most expensive uncertainties unresolved until development.
• Failing to define what question each prototype answers, so feedback can't be attributed to a specific design decision and iteration stalls.

Combine With

Community Map, Stakeholder Identification, Personas, and PAINstorming to understand user needs Problem Framing to define the problem Simplicity Cycle to guide how much to simplify or mature your prototype

Assets

• PDF: Download
• Markdown Template: template.md

Metadata

Field	Value
ITK Phase	EVALUATE
Difficulty	Intermediate
Group Size	2+ people
Time Required	60+ minutes
Source	itk.mitre.org