Prototyping is invaluable for getting feedback on a design. It is also great for getting validation of requirements. It can even be used as a means to document the requirements. What level of fidelity should be used when getting feedback? Jan Miksovsky provides some guidance from the real world.
Jan’s Article
Jan provides great visuals with his article, so you have to read his article first, to get the images in your head. We won’t copy them here to avoid any creative-commons mistakes. Jan was generous enough to share the prototypes with us on his page. Thanks Jan.
Summing Up:
Lower fidelity prototypes are more effective at getting feedback on the design, because people assume that a less-polished prototype represents a less-complete design. People are generally nice. They don’t want to make us “throw away work” and start over. If a prototype looks too refined, people are more reluctant to share criticisms about the design. If you skipped Jan’s article, go back and compare his experiences with the images of the different prototypes.
Sneaky Idea
Jan also shared a sneaky idea with us at the end of his article:
If you’re intrigued by the idea of presenting rough sketches early in the development cycle, but appalled by the idea of manually drafting paper sketches, you might consider modifications to your own design process. This past week I conducted design reviews of a PowerPoint prototype that used a free handwriting font (at a suitably legible point size) for the UI text. The feedback collected during the reviews was at the right level for this stage of the process, and it was easy to refine the design between reviews, so I’m likely to use this approach again in the future.
Fidelity And Requirements
Prototypes are very powerful for eliciting requirements because they engender a visceral response. People who are otherwise unable to visualize how they might use a solution often have moments of clarity when they see a mockup, or use an interactive prototype.
This clarity can lead to great feedback about requirements correctness and completeness. The challenge is that it makes it much harder to avoid specifying the design (or mis-setting expectations) with the prototype.
We think that the less (visual / design) data we provide, the more effective we will be at gathering requirements. We occasionally use whiteboards to sketch out OOA diagrams, wireframes of relevant, possible ways to present information, and activity diagrams that demonstrate how users might adapt their existing business processes into solutions.
We do this because we think that interaction design has merit as an approach to developing software. We’re still trying to figure out a good way to combine the best elements of interaction design with traditional structured requirements approaches.
A Different Factor
We think the premise of “we’re gathering requirements, it might look like this” will serve to negate the reluctance that Jan describes for “design feedback.” When we are getting feedback, we are explicitly “pre-design.” However, we think the reduced fidelity of a prototype reduces the risk of implying design decisions that may influence requirements. The essential information can be presented without creating design refinements.
Summary
The level of fidelity of a prototype matters, because it influences the willingness of a reviewer to give critical feedback. Lower fidelity prototypes also reduce the risk of having implied design specifications influence our requirements.
