Prototyping Sprints

The aim of the prototyping phase is to find a direction to move forward in. We need to quickly find out which directions or aspects of the service work or don't work.

Retrospective

See: Sprint Retrospective

Planning

See: Sprint Planning

Sprint activities

  1. Building prototypes

  2. Testing prototypes

  3. Analysing test results

Building prototypes

What you build and how you build it depends on what you need to find out. Always aim to pick the quickest and cheapest option for building what you need.

For example:

  • If you want to test the information architecture of a site, you can build a tree test

  • If you want to test the usability of a form, use a form-building tool like Google Forms or Typeform

  • If you want to test the usability of an interface, try paper sketches, wireframes, or mock ups

  • If you want to try testing a service with live data, build an HTML prototype that pulls from a live feed

  • If you want to test an end-to-end transactional service, build an HTML prototype with a (potentially mock-up) backend service that can react to and persist the choices of users

Testing prototypes

Common activities when testing prototypes include:

  • Interviews with users to better understand their needs

  • Showing design concepts to users to understand if the concept fits their needs

  • Testing the usability of an interactive prototype in a moderated session

You must do research with a broad range of users, including:

  • those with limited digital access and confidence

  • people with a range of visual, hearing, motor and cognitive impairments

Also see: User research in alpha

Analysing test results

The aim of the analysis stage is to go from raw observations (this user said this, this user did that) to insights (this does not fulfil the user need, that is hard to use)

The raw outputs from the tests might include:

  • written and digital notes

  • sketches and photos

  • audio and video recordings

The best way of doing this is by getting all the useful observations up on the wall on post-it notes. It's best to do this together as a team going through the raw test output.

Once you've done that, you can begin grouping the observations into themes. For example:

  • common topics

  • stages in a user journey

  • individual pages or steps in a transaction

  • types of user

Decide on a for name each group together. Then generate problem statement that concisely covered everything you've learned.

Ta-da! Now you have insights!

Also see: Analyse a research session

Last updated