| 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
- Start by filling out the “how might we…” statement at the top to define the problem and the goal of this prototype.
- List requirements: Think back to the user needs and problem space to come up with requirements that this product needs to achieve.
- 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?
- 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.
- 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?
- 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?
- 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.
- 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.
