Skip to main content

https://userresearch.blog.gov.uk/2014/08/27/using-prototypes-in-user-research/

Using prototypes in user research

Posted by: , Posted on: - Categories: Agile, Tips and techniques
GOV.UK paper prototype
Photo by @edwardhorsford GOV.UK paper prototype 

In this post, I’ll share how we’ve been using and building prototypes in user research to inform the development of digital services.

How we use prototypes

User needs and usability

In regular user research sessions, we use prototypes with research participants to further our understanding of user needs and test the service for usability. We often need to be able to iterate rapidly and try new (and sometimes very different) designs, meaning that the prototype is changing from week to week.

Quick and inexpensive changes

If you’re working with production ready code, a big change to the user interface often requires a significant development effort. This can make experimentation slow and difficult. Using a prototype, we can make quick and inexpensive changes to simulate the system participants would use.

Understanding user interface requirements

Sometimes the development team will use a version of the prototype as a reference for understanding user interface requirements. Using a version control tool and cloud hosting service, we can publish different versions of the prototype to different URLs whilst keeping all the code in a single repository.

Handy for service managers

A service manager often needs to demonstrate a service in the early stages of development to key stakeholders. In this case, the service manager needs a version of the prototype that stays the same and is always ready to be shared.

From sketch to code

In the alpha and beta phases, early design concepts normally take the form of sketches on paper and are often iterated quickly.

After proving these concepts with different types of user research, we often prototype in code fairly quickly. These prototypes are mainly built using HTML and CSS, normally without any back end integration.

Building prototypes in code allows us to rapidly achieve a live-like experience, making it easier for research participants to believe that the design they’re seeing is real.

This is how we build prototypes

Frameworks

Starting with the GOV.UK front-end toolkit and GOV.UK template frameworks, it’s fairly easy for a designer or front end developer to get started with prototypes that look like the real GOV.UK website.

As there’s a consistent style on all GOV.UK sites, most of the visual styles and design patterns we're likely to need are in the framework. We can combine the toolkit with simple static HTML or with development frameworks such as Ruby on Rails, if we want to make something more dynamic.

The GOV.UK front-end toolkit has been built to be responsive, so we know that our prototype will work on most devices - desktop, mobile, tablet or other.

Version control

On GDS projects, as well as many other projects throughout government, development teams use tools such as Github or Subversion for version control of source code.

We have found this is to be a good way to manage our prototype source code as well. These tools make it easy for several people to work on the same codebase, and they keep version histories, so it’s easy to jump back to any previous version of the prototype, especially if you tag the commits.

Website hosting

We publish the prototypes to free cloud based hosting environments such as Heroku or Amazon Web Services, and make sure they’re appropriately secured.

Having a place on the web we can point to is really useful. We're able to use the prototype from any computer and wherever we have an internet connection - in the research lab, at pop up research sessions, or to demonstrate the service to stakeholders.

Beyond prototypes

As development of the service progresses through beta to live, in addition to the prototype, we can also use the real service for research with participants. Using the real service can expose issues that are not obvious in the prototype. For example, service response times might be very slow or the way the service deals with errors might not be user-friendly.

We don’t stop using prototypes once we have a live service. We use our prototype ‘sand boxes’ to rapidly build and test new design directions and ideas. This helps us achieve our goal of continuously improving the experience for people using our service, even beyond the launch date.

Keep in touch. Sign up to email updates from this blogFollow Katherine on Twitter.

Sharing and comments

Share this page