Prototypes should have the lowest degree of fidelity possible to accomplish the needs of the test. Prototypes created at the Feature level should focus on more specific interactions and solving problems that are part of an existing system.
At the Program level, prototypes are built to explore smaller interactions within a larger system. These prototypes should allow (potential) users to solve problems that have already been established. A successful prototype test answers questions. Does the proposed solution solve the question established at the beginning of the test?
- Interactive prototypes: The most life-like prototypes are the easiest to test because users can interact with and experience them. These prototypes are easiest to qualitatively evaluate because you can observe users with the proposed solution and evaluate its success or shortcomings. If set up correctly, interactive prototypes also allow for quantitative testing via comparison, such as A/B tests.
- Paper prototypes: A low-fidelity version of the fully interactive prototype, paper prototypes allow one to quickly understand a feature’s viability. Paper prototypes are created by sketching the solution on paper or whiteboards and then walking a user through the experience. This type of prototyping provides the team with a high-level understanding of the viability of a solution. It will not inform the details required for the complete solution.
Prototypes built around features should always be shared/tested/shown internally as well as externally. By sharing prototypes internally, concepts that are overly complex and costly to produce can be discussed. Development problems can be identified early in the process and allow for a more streamlined production workflow.