Prototypes

What are prototypes?

Interaction Designers create prototypes of their services to explore, share and test different designs before committing to building anything.

You can quickly make and test multiple prototypes and discard the ones that do not test well.

Making prototypes is important because it:

  • improves the usability of your service
  • helps you to make sure you’re building the right service for your users
  • helps your whole team to get a shared understanding about the future of your service
  • allows your team to explore design ideas much faster and at lower risk than using your production code

When to use prototypes

You must use prototypes in the ‘Alpha’ phase of your service to explore and test different approaches to the design of the service.

Prototypes can also be used in the ‘Beta’ and ‘Live’ stages of your service to explore potential new features or improvements.

Types of prototype

Prototypes can vary in style from a quick pen and paper sketch to a code prototype that works like a fully interactive website.

You should use the prototype that best meets your needs at the time. Sketches are useful for exploring and discussing basic ideas with colleagues whereas code prototypes are better for user research because they’re more realistic.

Using code prototypes

Prototypes built in code can look and behave like GOV / NHS sites and are the best approach if you want to test realistic interactions that a user has with your service.

The advantages of prototypes built in code are that:

  • they look and behave almost exactly like the real thing, on mobile as well as desktop - this means users you test with are less distracted
  • you’re always aware of the constraints of designing for the web e.g. meeting accessibility standards
  • it’s easier for the whole team to have a shared understanding of any design ideas

The code in a prototype does not need to meet the same standards as production code. For example, it does not need to be secure or to perform well with large volumes of traffic. When you do move into production, other disciplines e.g. Developers, will make sure any code used is of good enough quality and is checked against the Web Content Accessibility Guidelines (WCAG) guidelines.

Developers should not just copy prototype code into production - if you spot this happening, raise it with your Delivery Manager immediately.

The point is to test ideas as quickly as possible. If an idea tests well, you may want to work with a developer to make your code a bit clearer so that it’s easier for others to work with.

If you’re new to prototyping in code, we have developed an ‘Introduction to Prototyping’ session that can help you get started.

This session is intended to give a base level of knowledge to all new designers or anyone interested in learning how to begin prototyping.

Using the GOV.UK / NHS Prototype Kits

The GOV.UK / NHS Prototype Kits allow you to build realistic prototypes of your service that look and behave like GOV and NHS services.

Both prototype kits come with detailed installation instructions and some example pages to get you started.

To use it you’ll need some basic knowledge of HTML, for example what tags and attributes are and how to copy and paste code.

Alternatively, you can work with developers on your team to create prototypes together.

Sharing code prototypes

Point 12 of the GOV / NHS Service Standard advises that we should ‘make new source code open’.

To do this, we store our source code on Github and we ensure our prototypes can be viewed in a browser by publishing our prototypes to a service called Heroku.

When you’ve published your prototype, you can easily share it with others. You must protect access to your prototype with a password so that members of the public do not find it and mistake it for a real service.

You must not use the GOV.UK / NHS Prototype Kits to make live services. It’s designed for prototyping and does not have the security or performance features needed for a live service.

To get access to the organisational GitHub and Heroku accounts, please speak to one of the Senior Interaction Designers.


Improve the playbook

If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.

Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.