Hi-fidelity or Lo-fidelity?
When choosing the right fidelity for your prototype, there are two main questions that you should ask yourself:
Who is the prototype for?
What is the goal of the prototype?
If I’m creating a prototype for a User or a Stakeholder then it will most likely be hi-fidelity. If I’m working with Developers and Visual Designers then it’s usually lo-fidelity. As with everything though, it’s not quite as clear cut as that. And, there’s not just “lo” and “hi”, there’s everything in between too.
Most of the time a lo-fidelity paper prototype is perfect for iterating ideas with colleagues. Your aim is simply to communicate your concept to them. For like minded professionals a quick sketch is often sufficient. However, if you’re still spending a lot of time explaining the idea, then chances are the sketch isn’t cutting it. In this case a simple HTML/Axure prototype might be your next option.
If you are testing a prototype on a user or trying to sell an idea to a Stakeholder then you’ll need it to be as polished as the real deal. A hi-fidelity prototype is generally required in this instance. As ever, there are exceptions, one of which might be that your user doesn’t understand the prototype they are testing and needs to explain quickly how they think it should work – the two of you might then sit together and hash out lo-fi paper prototype.
The goal of your prototype also has an impact on the required fidelity. You should only prototype what you need. If you’re building a new widget for the homepage, a colleague will not need to see it in situ. You’d therefore only prototype the widget, not the rest of the page. A user might need to see the widget in context, in which case, you might simply use a screengrab of the rest of the page. It’s an unproductive use of time to build a functional navigation for your prototype when what you’re testing is just the widget.
If your goal is to sell a new concept to a stakeholder then you’ll want it to look slick. If your goal is to explain a small interaction change to your PM, then go lo! If your goal is to determine whether something is feasible to develop, then work on some quick and dirty code with a Developer.
As Todd Zaki Warfel says: “It’s a process, not an event”. Be flexible and read your audience, adapt your prototypes as and when required.
Ultimately prototypes act as a common visual language for communication. They pull everybody in the product cycle together; they help Developers articulate ideas to Stakeholders and vice versa. And, the more collaborative they are, the more they give everybody in the team a sense of ownership of the project. This, in turn increases how invested each member of the team feels. As the prototyper, don’t be too precious about your ideas, your job is to communicate and fuse together the ideas, technical expertise and direction of the team (yourself included, of course!). Prototypes are iterations, they are, in my mind, an inherently Lean process. A Minimal Viable Prototype is often the better option!