The first of several areas we’re expecting to work on during the NHS.UK alpha is GP booking and registration. When the team started we worked entirely on paper. Sketching all of our solutions on paper is great for several reasons:

  1. It’s quick to get started. There’s no setup time involved to sketch ideas down on paper – just grab a pen and a piece of paper and go.
  2. There’s no barrier to entry. We make better things when everyone contributes and everyone in the team can use a pen and paper.
  3. We’re not constrained by technology. If we jumped straight into code to flesh out ideas then we might end up building what’s easy instead of what’s best. The framework we’re using for prototyping is pretty flexible, but it’s still a lot quicker to use it to make things that look like what we’ve already made.
  4. It’s easy to talk about. Standing around a bunch of sketches taped to the wall gives us a good focal point for explaining the flows and critiquing our work.

All of the above is why our second general order is to sketch ideas in every sprint.

As great as paper is, it has two major shortcomings for us. One, it’s harder to share. We have a lot of interested stakeholders who aren’t co-located with us and our paper sketches. We’ve also committed to sharing our work more widely, and as the fine folks at GDS would say: “show, don’t tell”.

To make this easier we use Marvel, a way to turn sketches into mobile and web prototypes. There are others like it, but the general gist is: take photos of your sketches, upload them to Marvel, and stitch them together into a prototype.

Two, it’s slower to iterate. Part of our process for refining our prototypes is to put them in front of real users and see how they use them. When we tested our first prototype of register with a GP with users one remarked “it tells me where it is, that’s good, but it doesn’t tell me how far away it is” – we’d included the address for the GP practice but nothing else. Fixing that in paper means at best a spot of Tippex and at worst having to redraw a whole page.

Moving to digital

After we learned enough about our registration prototype from working with paper we moved to HTML. We’d validated the overall flow with enough users to be confident we weren’t terribly wide of the mark. That doesn’t mean we’re nearly done, but it does mean it’s worth committing some more upfront effort to change to a digital medium.

Doing so addresses the two shortcomings of paper. Firstly, sharing our prototypes is easy: here’s the prototype for registering with a GP practice. Secondly, making small changes is very quick in HTML; we didn’t need to redraw whole pages to fix how we refer to GP practices, make form labels clearer or change how we present waiting times.

Moving away from paper still leaves us with one disadvantage: getting constructive criticism from the team is harder when the work is trapped in browsers. To make that easier we wrote a command line tool to take screenshots of our prototypes. It takes screenshots with a narrow viewport to help us build for small screens first and we can print out the results to help us visualise forks in the journeys and bring them to the team for feedback.

team-critique

Last week we started working on some new user needs around vaccinations, repeat prescriptions and blood tests; so far, we’ve done all of our work on paper. We’ve got a lot to learn about these new topics so it might be a little while until we make the move to digital again.

One response to “Starting with paper”

  1. […] and care system expertise. We saw the power of deeply understanding user needs and the cutting edge prototypes that flowed from that understanding.  And we got tonnes of value from working in the open, making […]

    Reply

Leave a comment