Prototypes aren’t a deliverable; they’re a communication tool
Following up from the idea of a UX as a Facilitator, not just a Designer, one of the key UX tools that makes this possible is Prototyping.
To do this you need to break out of the mindset of UX generated designs being a ‘final deliverable’ and instead view them as a ‘communication tool’, which facilitate a step in the process rather than being an end point.
Prototypes in the world of UX
A prototype is ‘working’ interactive version of a concept that anyone can try, understand, and see how it would work. They provide a proof of concept that can communicate the solution in a concrete and tangible way. A prototype can be anything from a piece of paper folded a particular way, through to a clickable and polished simulation of a product. The most common UX prototypes are a usually series of static pages linked together.
Their key benefit is that they are low-cost to produce (compared to production code) and can be tested with real users to ensure that the concept and value proposition meets the target audiences’ needs. They can be iterated and improved quickly to get the concept right before more costly development begins.
Prototypes are a communication tool
It is important to consider prototypes (especially lo-fi ones) as a way of communicating a concept, not a final deliverable that is handed over. They never showcase the complete working functionality and usually require some form a narrative to be told when testing/presenting them.
Rather than trying to replicate the entire end-end functionality (that would make them the finished product), prototypes focus on demonstrating the key user journeys through the product, telling a narrative of what the user would experience and how the interactions would work.
With this narrative, they can be a very powerful tool, without it they can become confusing. They can’t just be thrown over the wall to a Dev to build. They need to be part of a conversation about what the experience should be. They work at their best in a collaborative environment.
I see them as a key step in moving from a Waterfall to an more Agile UX approach where there isn’t a hard handover point between design and development, but instead an ongoing conversation and collaboration.
Prototypes vs Functioning Code
There is always a healthy tension between how much effort should be put in to producing prototypes in non-production tools as apposed to just jumping in to coding up a real world working version.
I believe that the sooner that you get to code the better. It is after all the actual medium in which the product will live. And you can never truly test the actual real experience until you see how it will work for real. As much as I love playing around with paper and post-it notes, they are only a stepping-stone to get to the real coded version. And once you get to code iterating and refinement becomes far more efficient.
However, more often than not projects jump into code too soon, before they have tested, validated and tweaked the underlying value proposition. Once code has been written these concepts become far harder and more costly to change.
As soon as code has been written it becomes an asset, making it far harder to throw away. In the early stages of creating a new product concept or just playing around with a new piece of functionality, lo-fi prototyping tools provide a great to play with ideas and explore different approaches, before one gets locked and set in to IT concrete.
Prototypes vs Wireframes
There is a gray area between what is a prototype vs wireframe. Although they are both created using the same tools and can use the same page content, there is an important distinction between the two:
- Wireframes focus on comprehensively capturing the page content and structure.
- Prototypes aim to demonstrate the interactivity and journey through a product.
Wireframes function more as a requirements document, which can be used for getting stakeholder sign-off and then be passed on to Devs to build from. Despite being more comprehensive, they are far from the best way to showcase the experience. Prototypes are able to demonstrate interactively and visually what the experience will be like, whereas wireframes can only describe the experience. This is not to say that wireframes don’t have a place or aren’t required, but they have a different purpose.
|Focus||Interactions and journey through a product||Content, page structure and functionality|
|Purpose||Communicating the vision of what the experience will be like||Creating a blueprint of the product for stakeholders to sign-off and developers to build from.|
|Primary audience||Users, stakeholders and developers||Stakeholders and developers|
Choosing a tool
Prototypes can be made using many different tools, all of which have their various benefits. These are some of the common tools used for designing user experiences:
The general dilemma when choosing a prototyping tool is which level of fidelity to work in. The general pros/cons are:
|Time to produce||Cheap and quick||Time consuming|
|Look||Rough & sketchy||Polished & Final|
|Focus||Proposition, Concept & Structure||Interaction Design, Appearance & Usability|
|Usability testing||Requires a guided narrative||Users can complete tasks by themselves|
The choice of prototyping tool selected should be based on the level of user experience that is being addressed.
If the product solution is new and the underlying concept/proposition is still being developed, then a lo-fi option is always best to begin with. The deliberately sketchy nature of lo-fi tools removes any focus on detailed page design and instead puts focus on the value the solution provides to users. It instead focuses on what should we build, not what will it look like.
Once the solution has been confirmed as the right idea to progress with, higher-fidelity prototypes will allow for more detailed level testing which can iron out any interaction design and usability issues.
- Sketching User Experiences: Getting the Design Right and the Right Design, Bill Buxton
- Prototyping, Todd Zaki Warfel