While a number of prototype philosophies and approaches are likely going to be used through the development and design cycle of a given project, from flow charts to sketches, from paper prototypes to rapid and wireframe, at some point, it’s going to come down to a high fidelity prototype.
The high fidelity prototype is unlike the prototypes that preceded it, not being a mockup or a conceptual construct, but a version of the actual product. In the case of software, it actually runs. It’s essentially a release candidate alpha or beta of the product, so close to completion that it’s viable for external user usability testing with resulting metrics that are actually applicable to forecasting how the final product, as it is envisioned, will handle in the hands of the public.
So, this prototype is very important, and there’s a lot of pressure here, right? Well, let’s talk a little bit about how to make sure this prototype is set up the proper way for the users to test it, so that the metric will in fact reflect on the theoretical final version pretty directly.
#1 – Unconfirmed Unstable Features: NO!
We’re going to assume this is all about some form of software here, in which case, well, watch the feature set first of all. It’s not uncommon for some additional “oh hey maybe we could add this little thing if there’s time or it works” sorts of features to start to adhere to a running prototype. For a high fidelity prototype, if these features aren’t 100% functional, and/or aren’t part of the original plan nor mandatory, disable them, hide them completely, heck, remove them if possible, from that particular prototype.
See if the UX test group asks for these features, not knowing they are sort of there but unavailable. If so, then you know to work to get them ready, and at the same time, you don’t have them messing with the tests in the mean time.
#2 – Use the Final GUI Library
Use the library you plan to publish with, with the fonts, label wording, color schemes and everything that you want the retail version to use. It can’t be the ugly developer GUI that just reflects the layout but not the aesthetic. A prototype of this level of fidelity is to reflect how they will react to the perceived final version, and this is part of it. Too many times, people think otherwise, and it kind of defeats the point.
#3 – Give Realistic Tasks for Testing
Since you’re testing the use of something that’s practically the final product, you must test them on using it as they would normally use the final product, as you see it taking shape. So, be realistic in what tasks they perform in usability tests, rather than the unrealistic drilling tests done on previous prototypes and builds which were intended for combing and stress testing.
Ultimately, bear in mind that a high fidelity prototype is a safe way to test the “final” version of the design, and in that scenario, it needs to reflect in how it is tested and how it is presented, a simulation of said final product in a realistic scenario. Keep that close to your forethought, and you’ll be just fine.