3.1. What is a prototype?

The term ‘prototype’ can be interpreted in many ways. When we refer to a prototype in the context of building digital services, we mean a high-fidelity mockup of a potential user journey.

A good prototype:

• looks and feels like a real digital service
• provides a seamless user experience along the ‘happy path’
• uses familiar design patterns
• includes content and data that looks real
• responds with alerts and feedback in the right places

Of course, a prototype shouldn’t be functionally complete: build only the journeys and use cases that you need to test.

3.1.1. Show the thing

So far, the team will have created hypotheses and opportunity statements, generating concepts based on their research. This is essential, however it’s common for most teams at this point to fall back into assumption and beliefs about users and their needs.

The best way to quickly challenge assumptions and begin to tailor your prototype to the real needs of users is to ‘stop talking and start doing’ - make your concepts and theories tangible, and test them.

This is also really important because it:

• creates a common understanding of what you’re aiming for
• helps eliminate confusion or misunderstanding within the team
• enables you to get back in front of the user to find out whats relevant to them
• will boost you out of theory and into practice

3.1.2. Start sketching in code as quickly as possible

It’s fine to start sketching out ideas for a user journey on paper - it can be an easy way of thinking through solutions to a design problem.

However, it’s important that these sketches on paper move to sketches in code as soon as possible, so that you can quickly test out the idea to see if it works on screen.

We’ve written more about the tools and technology for building prototypes.

3.1.3. Build for mobile devices first

A greater proportion of users are accessing government services from mobile devices than ever before. Taking a mobile-first approach to building prototypes means that more user research can be performed in a realistic context.

The constraints of the smaller screen size means that services designed to be mobile-first are simpler, with only one or two things on each page. When scaled-up to larger screen sizes, the simpler service design is easier for everyone to use too.