Short answer
Prototyping creates fit-for-purpose representations that make ideas testable before full implementation. It measures how well a prototype answers a question, not how closely every prototype resembles finished work.
About Prototyping
Creates fit-for-purpose representations that make ideas testable before full implementation. The competency covers choosing fidelity, representing relevant behavior, managing prototype limits, and learning efficiently from use.
Use this competency for
- Roles expected to make concepts, flows, services, or technical behavior testable before delivery.
- Roles accountable for choosing prototype fidelity based on a decision or learning question.
Do not use this competency for
- Roles that only review prototypes and do not create or adapt representations for testing.
Important distinctions
Interaction design
Prototyping creates a representation used to test an idea. Interaction design defines the intended behavior and task flow that a prototype may represent.
Visual design
Prototyping chooses enough fidelity to answer a question. Visual design determines composition, type, color, and hierarchy in the intended experience.
Expectations by level
IC1
Individual contributor 1
Builds a bounded prototype with guidance, uses the requested fidelity, represents the critical path, and states which parts are functional, simulated, or omitted.
Observable behaviors
- Connects the screens or steps needed to test the assigned task.
- Labels simulated behavior and unavailable paths before a session or review.
- Checks the prototype from its starting point through the intended outcome.
Examples
- Builds a clickable flow for a checkout question and marks payment processing as simulated.
- Before testing, fixes a broken path that prevented participants from completing the critical task.
IC2
Individual contributor 2
Independently chooses and builds prototypes for bounded decisions, balances speed with realism, includes relevant alternate states, and revises the representation as questions change.
Observable behaviors
- Chooses prototype fidelity by naming the question and the realism needed to answer it.
- Represents alternate paths that could materially affect the result.
- Removes detail that adds production effort without improving the planned test.
Examples
- Uses a low-fidelity service walkthrough to test handoffs before investing in interface detail.
- Adds realistic data and a failure state when both are necessary to evaluate a reporting workflow.
IC3
Individual contributor 3
Leads prototyping for ambiguous or cross-team questions, selects among representation approaches, enables others to test complex behavior, and improves shared prototyping practices.
Observable behaviors
- Breaks a broad uncertainty into prototypes that test separate decisions in a useful order.
- Coordinates prototype boundaries when several teams own parts of the represented experience.
- Creates reusable methods or components that reduce effort without constraining the question.
Examples
- Sequences a storyboard, interactive flow, and technical spike to test desirability, usability, and feasibility separately.
- Defines shared prototype data and states so three teams can test one end-to-end service journey.