7 Tips For Better Prototypes

I love developing prototypes. I love the challenge of teasing out insights with a super low-fidelity prototype. Most of all I like keeping prototypes squarely focused on reducing risk, and making sure the process benefits the customer.

Too often I feel like the prototyping process becomes a blocker unto itself. Competing goals muddy the waters, confirmation bias rules the roost, and feature creep turns a throwaway prototype into a big undertaking.

Below are a couple thoughts on how to keep the prototyping process free from bias, and focused squarely on the needs of your customers.

1. Decide On A Driver
Is the prototype designed to elicit meaningful feedback? We build prototypes because we lack decision-making information. A shotgun approach makes it difficult to filter the signal from the noise. Consider instead building multiple prototypes that individually address key areas of uncertainty. Decide on a driver. Is your goal to experiment with different technical approaches? Are you validating usability, adoptability, or business value? Prototypes don’t multi-task well. “All of the above” is not a great answer. Stick to a single driver, and at most a “nice to have” side benefit.

2. Defeat Confirmation Bias
Ask how the data you intend to gather will ultimately change your behavior. Most people assume they’ll “just know” when they’ve nailed a feature. Right off the bat that thought process is setting in motion a strong confirmation bias. As I’ve mentioned in previous posts, there is a big difference between exploratory testing (where you’re looking for unexpected failures and successes) and validation tests that are designed to validate a system is working correctly.

Can you move the needle with a single, low-lift enhancement? That would be a good one to try first because an affirmative response would be surprising, and therefore valuable. Also, consider having someone with less skin in the game lead the validation efforts with users. You might already be too close to your solution.

3. Throwaway Prototype?
Are you willing to throw away your prototype and start over? Make it clear if you’re building a [throwaway prototype](http://blog.codinghorror.com/the- prototype-pitfall/) meant to be discarded, or an [evolutionary prototype](http://www.exforsys.com/career-center/project-management-life-cycle /the-evolutionary-prototyping-model.html) meant to be refined and rebuilt into the final solution. The middle ground is not a great place to be. A throwaway prototype lets you work quickly and focus on the big, risky unknowns. An evolutionary prototype focuses on better understood features and delays decisions on less clearly understood features. If you are juggling unknowns AND knowns in a single feature, then consider running two prototyping tracks in parallel.

4. Simplicity
Don’t prototype a more complex feature, when a simpler feature might achieve the same effect. Why? Even cheap complex features can have an adverse effect on the user experience and make future iterations more difficult.

5. Small and Timeboxed
Keep the team small and [timebox](http://www.techwell.com/2014/01/use- timeboxing-boost-your-efficiency) your efforts. The value of prototyping is that you discover information quickly and cheaply. All too often this turns into a prototyping death march, where vague feedback triggers a never-ending escalation of complexity, minor iterations, and increasingly vague and misleading feedback. Don’t go there! Cut it short. Don’t expand the scope because you lack clear feedback. If anything, remove variables. Stick to discreet questions and areas of uncertainty.

A small expeditionary force keeps you lean, and defeats analysis paralysis. A timebox keeps you focused, and forces you to paint with a limited palette.

6. Tweaking vs. Prototyping
Differentiate optimization/tweaking from prototyping. Are you 90% of the way there? Then by all means release your feature and tweak. Are there large, lingering areas of uncertainty? Then continue to prototype. The team should have a solid sense of turning the corner before releasing code to a broad user-base. The larger sample size will help when it comes to optimizing and detecting small differences. But processing broad feedback at scale can be difficult. And why wait that long to root out problems that can be more easily and cheaply caught earlier in the process? Broad strokes first. Fine print last.

7. Have A Plan
Don’t pressure teams into prototyping for the wrong reasons. I’ve caught myself in the past using the “fail fast / learn” mantra to justify cranking out poorly planned prototypes. The reality was that I wanted something sexy to show customers, and that I didn’t really have a plan for testing my assumptions. Don’t let this happen. Have a plan. Engage with your team to uncover what is blocking data-driven decision making, and together plan the prototype. If you are making the executive decision to “just start building”, then at least be transparent about that.

Let me know what you think in the comments below! Happy prototyping!