Recently, I’ve noticed a bit of an alarming trend within the product design community around the use of static prototypes. These types of prototypes are a great tool, but solely relying on them for making crucial product decisions can be a slippery path. Let’s dig into why that could present problems.
Distinguishing between static & interactive prototypes
A static prototype typically is done with low or high fidelity designs. A classic example of a static prototype would be a clickable set of mockups put together using a tool like InVision. A user can click on pre-determined hotspots to move from one screen to another. The content in these mockups doesn’t change per session and looks the same to every user.
Interactive prototypes are more dynamic and feature-rich. This may be a prototype built in a more interaction-based tool, like Framer, or built natively within the final intended platform, like an HTML/CSS prototype. These types of prototypes usually aren’t hooked up to a finalized back-end system but have the capabilities of changing more significantly based on the user’s input.
Validating ideas with prototypes
When building a product, there are many points in the process where you need to validate if you’re headed down the right path. This can happen with early MVP products but also with fully established products that are focused more on refinement. Validating can help you make decisions before going too far down one particular path, saving valuable engineering cycles.
Herein lies the crux of the problem with relying solely on static prototypes.
Static prototypes can help validate a direction by testing two different solutions in a quick and less labour-intensive way. But that’s where we need to start creating that defining line: they should be a gut check tool, not a final decision-maker.
Let’s take validating a search experience as an example. Search is a very personal experience; as a user, I’m looking for something very particular to my needs. Showing the user a search experience with static mockups means very little of the experience has been tailored to the mindset of the person viewing it. Because the search results shown to them weren’t inputted by them, they have little emotional connection to the results. This can lead the user to become distracted and start looking at parts of the UI that they don’t feel are necessary. Even worse, they may begin to suggest changes to make it more personal to them. For example, you could hear something like, “I’m not sure where to look, there should be more options for X here.” This could just mean that because they don’t personally care about the results shown to them, they’re looking to add information to become personally invested in. This can take you down the path of adding new items or overcomplicating your UI just to satisfy an unrealistic use case.
Static prototypes take the emotion out of the experience and emotion is what makes the difference between a good and great experience.
Using static prototypes effectively
The key is to use prototypes for their intended purposes. Static prototypes are great to quickly gut check an idea or compare against two different directions. A more practical example could be in a new-user onboarding flow to better validate the content the user might be shown. This type of prototype doesn’t rely on the user inputting information. They’re digesting the information presented to them the same way every time.
These types of scenarios are where static prototypes truly shine.
Remember to take the results with a grain of salt. If your experience relies on their emotional response to it, then you might not get a lot of useful information from the prototype stage. That’s okay — just don’t rely on it to make the final decision. Ship one direction and see how it gets used and how that emotional response to the experience is formed — then iterate with this new, more valuable information.
Use all the tools in your toolbelt, not just the easiest one. You wouldn’t use a hammer to put a screw into the wall, now would you? 😉