Choosing the minimal testable prototype
A prototype is something that is created to test an idea and understand whether it’s a viable solution to a problem. The reason we use prototypes of any kind, not just in software development, is to try out ideas quickly and cheaply rather than spend time and effort building a solution only to find out that it doesn’t solve the problem. Something I’ve heard to describe this in architectural terms is that ‘it’s easier to erase a line from a sketch than to knock down a wall’.
When creating a prototype, we also don’t want to spend more time and effort on it than necessary. There is no point creating a fully clickable, in-browser prototype to test a task flow. In creating a prototype, we need to make sure that it is in that sweet-spot where it is of high enough fidelity that it is testable, but also low enough fidelity that we’re not wasting resources creating it. This is where we need to choose and create the minimal testable prototype.
Examples of prototypes
Flow diagrams
These may not look much like a prototype, but they are. Flow diagrams can be used to understand how a task can be performed. At this stage, we’re not concerned with the screens, but with trying to identify the steps the user will go through in order to complete their task. These can be used to test with users, and feedback can be gained to make sure the steps in the process are correct before going any further.
Wireflows
I’ve been using this technique more and more recently. It works particularly well with a well-defined design system such as the one from Gov UK that we use for government projects. The idea here is to start identifying screens in the process and how they connect together in the overall flow. These can be expanded to include example text and other screen elements, such as the status I’ve included below. One benefit of these prototypes is that the user is presented with a lot of information that may be on the screen, but they instinctively know that it’s a work in progress so are quick to give feedback and make changes.
In-browser, or click through prototypes
These can take a number of different forms and can range from visual representations of screens with clickable areas, right up to HTML built prototypes with programmed logical routes such as the GOV UK design toolkit. These tend to be created when we need to test how the actual system will work. They will be the highest fidelity, and therefore the costliest to create; both in terms of time/effort and money. They will also provide the best feedback in terms of how users will experience the end product so can be very useful to use.
Choosing the right prototype
Choosing the appropriate prototype can be difficult and comes with experience and also depends on the testing requirements. Often, when I was starting in the industry, I created all-singing, all-dancing prototypes that could have been done much quicker and far simpler. It’s only through doing things multiple times that we find the right and wrong way of doing them. Nowadays I try and spend a little more time before I create each prototype to consider what is appropriate for the context of what I need to test.
