By Dan Goodwin & Ben Coleman25 May 2017Tutorials
In an exclusive excerpt from Designing UX: Prototyping Ben Coleman and Dan Goodwin explore the main reasons for using prototypes for your designs
There are some compelling reasons to utilise prototyping, such as:
Let's explore these in a little more detail.
The best way to test our user interface designs is with real users, and the best way to communicate our user interface designs is to implement them. This is where prototypes are significantly more powerful than sketches, wireframes, or flat designs (for example, visual design mockups produced in Photoshop).
As a design progresses through increasing levels of fidelity (such as full production-ready implementation, full content and/or data), the effort (and hence, cost) of implementing that design increases, too. Without getting bogged down in statistics, it's generally accepted that this increase is more exponential than linear, as represented in the figure below.
The cost of implementing design work and changes over time:
As a result, placing designs in front of users and stakeholders as early as possible means that we can share, test, discuss, identify issues with, and iterate our designs in an efficient and cost-effective way. Involving the whole project team in the creation of a prototype early in the design life cycle is the recommended way to go about it.
In situations where we are uncertain about design decisions or are experimenting with ideas - and particularly where we want our designs to work best for our users - we should find ways to explore our ideas and test them with users early in the process. Sketches and wireframes provide a great starting point (and, to a degree, sketches and wireframes can be treated as prototypes). We can sketch and wireframe ideas for sections, features, and interactive elements. And if we work collaboratively, we can quickly generate lots of ideas.
Yet putting sketches and wireframes in front of users can only go so far. We can ask users to tell us what they'd do and how they'd approach a specific task, but as interactivity is limited, there isn't much users can actually do. This can be tricky for users in an observed testing scenario (even if it's informal) as people will feel pressured to say something, to seem useful. We tend to receive feedback that's subjective, such as “I'd do it this way” or “I'd put a button there”). This is generally unhelpful to us. What we need is to observe users using our product, trying out our idea.
This is where prototypes can come in—bridging the gap between ideas, sketches, and wireframes and the later stages where we're producing full fidelity visual designs and production level markup and implementation. They provide enough depth, fidelity, and interaction to make user tests much more relevant. Users can be set tasks that they want to complete (because our user research has told us what are our users' key goals). They are given free rein to explore, interact, review content, see results, and react; to explain where they're going, what they're doing, and why.
Regardless of how a project is structured (for example, in-house, client/agency), it will involve multiple stakeholders. Prototypes can help stakeholders understand your designs and involve them in a much more powerful way than abstract deliverables such as user research outputs, sitemaps, sketches, or wireframes.
Stakeholders can interact with a prototype themselves; they can experiment with it, explore, review content and data, and add or change content or data. It's real enough that they can quickly and easily visualise and understand.
Stakeholders are often senior-level people with very little time to spare. A lot of their time is spent being shown boring slide decks full of bullet points and pouring over spreadsheets full of numbers. Getting to play with a prototype is really exciting and different for them, so it's a great way to engage and gain approval quickly.
Additionally, a stakeholder can share a prototype with other people, such as others in the organization who are less involved but interested, third parties whose opinion they value, or users to whom they have easy access.
You might even find stakeholders becoming so involved that they start creating their own sketches and prototypes to communicate their ideas.
We're now in a world where our designs will be used across multiple devices with different viewport sizes and multiple methods of interaction: touch, keyboard, mouse, remote control. All the indicators are that this device and interaction space will only continue to grow.
Most prototyping tools and techniques support us in designing across different devices, sizes, and forms of interaction to a degree. They achieve this better and more efficiently than sketches, wireframes or flat designs. Some prototyping tools and techniques, in particular HTML prototyping, are particularly helpful here.
Presenting across different devices is a massive leap forward in terms of testing. We can run user tests across several devices, as well as enable users to test prototypes in a familiar context on their own devices. Similarly with stakeholders, we can encourage them to review our prototypes on smartphones, tablets, and other devices.
As we look across the range of prototyping techniques in later chapters, we'll look at comparing their ability, or inability, to help us design and test our prototypes across devices.
If one of our overall aims is to better involve users in the design of our product or service, as well as to better communicate our designs to stakeholders, the ability to present realistic and convincing real content or data makes a significant difference to our ability to meet that aim.
Most prototyping tools and techniques make it easy to incorporate real content into our designs quickly. If we have stored a set of real content with some structure to it, we can generally get an interactive prototype to pull in that content. It could be a database or a set of files that we can query with some code or set as a data source in an interactive prototype. It might even just be content copied and pasted in, but with the benefit of tools to help with layout. Many tools make it easy to build and include a library of images, cropping and resizing as necessary.
Some tools provide separation between content and the presentation of that content. This means that we can start with a prototype with no content or placeholder information, then give our project team and stakeholders (even those with minimal technical knowledge) the ability to add and edit as it becomes available.
We can also allow users to input content to a prototype and for the prototype to work with and respond to that real content. Imagine working on a web app where a user provides some information about themselves and the web app presents a set of results for them to work with. If the user is able to use their own information when testing a prototype and the prototype provides results that reflect the information, the test will be much more realistic and useful. This level of interactivity can only be achieved with a prototype that implements some degree of real data input to present results, offering something a wireframe or sketch never could.
This is an excerpt from Designing UX: Prototyping by Ben Coleman and Dan Goodwin. Ben will be attending Pixel Pioneers Bristol, so come and say hi or even have your copy signed. The series editor of the Aspects of UX titles, Joe Leech, will also be speaking at the conference.
Ben is co-founder and managing director at fffunction. He trained as a product designer in the late 1990's and moved into the field of digital design shortly after. In doing so he brought user-centred design principles to this relatively new field and has been applying them to digital projects ever since. At fffunction he wears many hats, but can be mostly be found solving design problems, running workshops, organising content into information architectures, sketching interfaces, building prototypes and testing them with users.
Dan is the user experience director at fffunction. With 20 years experience in agency and in-house software and web development, he is an all-rounder with strong technical and people skills in addition to user experience. He loves user research and bringing users and empathy for them into every step of a project.
Dan loves the sea and gets in it or near it whenever he gets the chance. He likes good coffee, good beer, and good and bad flapjacks.