We do a lot of rapid prototyping, so we’ve picked up several tips along the way that save both time and money. Our founder, Erin Young, recently wrote a guest article for InVision that outlines some of our time-saving lessons for rapid prototyping.
1. Think of rapid prototypes as disposable artifacts.
A prototype is a means to an end: feedback. So only prototype what you need. Trying to prototype a full product all at once could cause problems when you receive feedback or need to change one thing. Complex prototypes further increase your risks. Limiting the scope in a KISS-style approach. If you build small chunks of work, they’re easier to throw away - especially in an Agile world.
2. Establish a clear purpose for your prototype.
Before you begin prototyping, make sure there’s a clear understanding of who the audience is and what the prototype will be used for. This helps determine the proper level of fidelity before any time is invested.
3. Define the prototype requirements early.
The scope and fidelity of a prototype determine its cost and timeline. Use the prototype’s purpose to help set these boundaries and communicate them to project stakeholders early on. Alignment prevents added last-minute stress and missed expectations.
4. Stay in flat design as long as possible.
Gather input on your designs before adding interactivity. Any rework or adjustments to visual designs has at least 2x impact to costs because you're doing rework in two places: the visual design files and the prototype. This can increase costs, take longer, and keep you up later than you’d like.
5. Test your prototype's interactions while you build it.
There’s nothing worse than getting to the end of a prototype build and realizing that something went awry in the interactions early in your building process. It can be disheartening and time-consuming to track down the source of the problems. As all developers recommend, test early and often.
6. Don't expect your prototype to communicate all your edge cases to development.
Prototypes are great at bringing questions to the surface about “unhappy paths” or edge cases. We encourage our team to stay on the “happy path” when building rapid prototypes - unless an edge case is the whole purpose. A development specification documents unhappy flows in a more complete way, which saves developers from trying to discover all potential alternative flows through clicks and taps.
Want more detail? Read the full piece over at Invision.com.