Prototyping is a multi-disciplinary activity, spanning across digital design, industrial design and everything in between. Whilst being precursors to the end product, prototypes may vary in fidelity. This article will look at digital prototyping, providing guidelines you can use to determine when you should and shouldn’t build one.
Within the digital space a prototype is used to quickly test ideas and see whether users can complete core tasks. They are intended to save development time as not a single line of code is needed to validate any ideas. Furthermore, a prototype is not always needed. Often, a storyboard will do! Choosing between the two depends on what you’re trying to achieve. Each of these deliverables is an important skill for UX designers to develop, but arguably what’s more important is the ability to select the appropriate output and level of fidelity required.
Low Fidelity Prototypes
A low fidelity prototype is often created using paper and pen.
When to Use
In my experience, lo-fi prototypes are intended to capture the “low hanging fruit” feedback, such as confusion about platform conventions (e.g. Material design plus button, Windows 8 charm bar etc). Also, this method is especially useful when working in a collaborative design project. You can set the timer for fifteen minutes, hand out a number of templates and get each person to sketch out their ideas (one page per two people works well).
Companies such as uistencils.com offer a number of paper and ruler stencils of common UI elements to quickly put together rough concepts. You could also use a paper and notepad. These lower fidelity prototypes can be uploaded in tools such as Invision, where you can link up the pages using “hotspots”, and simulate, at a pretty loose level, what the end product could possibly look like.
Mid Fidelity Prototypes
A medium fidelity prototype is normally put together using software. Unlike the paper prototype, which may be more suitable for collaborative design, this method is usually put together by a UX designer on the team.
When to Use
Use mid-fi prototypes after you’ve gone through your inspiration phase, including qualitative research, customer journey maps and initial flows. The goal here is to test some task flows and see how users respond to your ideas overall.
There are a number of tools out there such as UXpin, which are always evolving and updating their set of features. Axure is also a common tool and one which I prefer due to the rich interactivity with form fields and its ability to create complex rules and conditions. However, in my experience, less is more–making complex interactions at this stage defeats the purpose. The intention of this prototype is to create something quick and easy for testing.
High Fidelity Prototypes
High fidelity prototypes can be differentiated from mid fidelity prototypes in a couple of ways. The main thing that separates them is that they are often created using code. However, this might well be very hacky code, certainly not production quality, and being in need of some serious refactoring.
When to Use
High fidelity prototypes are good when you’ve finished initial user testing sessions and want to explore richer interactions and animations. Also, you may want to share a vision with stakeholders regarding what the final product may look like.
I find the best time to use a storyboard is when you have an idea to communicate. A storyboard (in the context of UX design) is a linear sequence, showing how a user may be struggling with an existing process or product. However, often it reflects an imagined state and interaction with a new product.
When to Use
Innovation Projects: I used to work in a consultancy. In between contracts I was often tasked with building an innovation project in order to drum up business and sell our capability to companies who may not be actively looking. For example, on the back of whatever we came up with to show (our skills with big data, data visualisation, user experience etc.) the account manager would be tasked with demoing our creations to each representative.
A prototype was often created, simply because we had the resources to build one. However, in this scenario a storyboard is more effective as a sales tool. The prospective client may or may not be savvy with technology; by using a storyboard you can bypass the industry jargon or tech babble and clearly show a story–including a problem and resolution.
Human Centered Design Challenges: Storytelling is also powerful in human-centered design challenges, where you need to get inspiration from research, ideate and consider the scope of the problem and innovative ways to address these issues. A prototype often seems a bit premature here. The natural progression of one of these challenges may be a crowdfunding campaign, rather than building out an actual product. Therefore, a storyboard may be the best way to succinctly convey this to an audience and reach them on an emotional level, where they are more likely to contribute (as opposed to looking at a user interface).
Hackathons: Hackathons are probably the best place to use a storyboard and ironically they are very rarely ever seen there. This is because typically you get technical types participating and they are overly focused on technologies and programming languages. These can really alienate the panel of judges. By having a compelling storyboard, showing how the solution addresses the problem it is more likely to be compelling to an audience and be a strong supplementary piece to anything that has quickly been generated in a few days.
All you need to create a storyboard is some sharpies and butcher’s paper! You don’t even need to be good at drawing.
If you are a designer and have Adobe Illustrator, Sketch, or Affinity Designer you can also take your storyboards to the next level by finding a free set of storyboard art illustrations and editing them to suit your story. If you have a look online there are generally many available.
In my personal experience, low to medium fidelity storyboards are sufficient in UX design. Perhaps if you were working in the industrial space you may need something more higher fidelity. However, in digital it’s unlikely that the benefits will outweigh the costs.
The intention of this article is to give you more awareness around which deliverable to use and when. You will often be tasked with things by managers who don’t really understand the need for each. It is hoped that by reading this you will be able to critically think about the deliverables needed and put forward a case for whatever choice you come up with.