Prototyping is a key element to the requirements discovery, definition, and validation process when building web applications. However, it’s all too common for teams to spend too much time in the prototyping phase, thereby defeating the purpose of creating a prototype in the first place. Here are several best practices to ensure you and your team get the most from your prototyping process.
The Six Best Practices of Prototyping:
Prototype just enough.
You need to get your point across to stakeholders so they can make informed decisions. Simple wireframes often aren’t enough to convey understanding, but don’t fall victim to over-prototyping (from both a functional and graphical fidelity perspective). Remember, the prototype is not the final product. Those who want to create a hi-fi prototype that “fools the end user” into thinking the prototype is actually the final product are setting themselves up for failure. The goal is to effectively communicate ideas so that you can get feedback, not to waste time trying to build a pixel perfect representation of the final product.
Know your audience.
Who is your audience and what do you need to communicate to them? What type of feedback do you want from them at this stage? What are your objectives? With a tech savvy internal team, low-fi may be enough to get the job done. If you’re working with non-technical stakeholders, a greater level of interactivity is likely needed to get everyone on the same page and eliminate the usual interpretations/assumptions. Knowing your audience will help you determine what level of fidelity will be required to communicate your concepts effectively.
Set the stage.
Prepping your audience by setting the right expectations is important. They need to know that they’re experiencing a prototype and not the final product. They also need direction from you on what feedback you need at this stage. (Is this what you meant? Layout architecture vs. design details? Where would you go to do X? How would you complete task Y? Internal team/exec stakeholder/end user?)
Plan less, prototype more.
Prototyping is a perfect way to validate and refine existing assumptions and requirements. However, it is also a very efficient tool for eliciting superior requirements. Heavy documentation leaves far too much room for interpretation and assumptions that won’t be revealed until late in the development process. Less documentation and more prototyping will get everyone on the same page much faster. A solid prototype can quickly deliver universal understanding to all stakeholders and trigger the valuable feedback you need to make good decisions early in the process.
Share early and often.
Prototyping is a cyclical process. Start with basic wireframes and functionality, and then iteratively flesh out the areas that need clarification and detail based on stakeholder feedback. The key is to share your prototype early and often (even though it may be far from perfect) to ensure you’re not designing based on incorrect assumptions. Often, stakeholders don’t even know what they want until they see it. Each round of feedback turns the dial and brings the project and stakeholders’ vision into clearer and clearer focus. By sharing early and often, you eliminate risk by failing cheaply as well as quickly identifying the winning concepts.
Don’t prototype everything.
Just as you should avoid wasting time by creating too high fidelity of a prototype (functional and graphical), you also should avoid prototyping every single aspect (every individual component, interaction, or page) within your project. You can focus on the areas or pieces of your project that are complex, need buy-in, or require end-user testing. Often, you build prototypes to get feedback on key scenarios. In this case, prototyping anything outside of these specific scenarios is a poor use of time. And remember, the prototype is not the final product; it’s a means to clearly convey understanding, collaborate, and gather quality feedback early in the process.