Book Patient Transport Service

Roles
Designer
Front-end Developer
Year
2018
Client
Falck UK Ambulance Service
Agency
Blue House Design
Website
Book Patient Transport

I was excited the most to work on the Book Patient Transport service. Not that it started out as that. You see language is a tricky thing and it's easy to fall back on jargon. Falck kept referring to it as a “web booking portal”. See how one describes a task and the other describes the medium?

I knew a project like this would benefit from applying design principles from service design. The challenge was doing this when the client had not paid for it, we as agency don't provide this service and there was little time to get buy-in or traction.

Why did I think service design would help? One reason is the relentless framing of the work around users. But this is a big cultural shift. It requires more than just thinking about user needs. To be truly effective it needs to be coupled with iterative approaches to a design system. Trying to determine all things up front is too big a challenge.

Figure 1
Book Patient Transport service start page that acted as a hub for information about the service as well a link to the third-party booking system

User research when neither you nor they do it

A problem I face as a designer is that my agency we does not provide user research services, and often the subject is never mentioned. Clients too don't hire us for this.

However when you start working with people pretty much any concern or idea they raise is about user needs.

To address what I could I did two things:

  1. I based the service on the work by GDS
  2. I set up analytics in advance to gather at least some technical information
  3. I talked to a couple of friends who happened to be users of the service

While the insights and data gained from these is flimsy it is nonetheless better than pure assumption. It also doesn't stop us from working on the project and delivering something. Of course would reduce risk and uncertainty but it was better than nothing at all.

While incomplete we did gain some insights:

  • Users considered training to be informal
  • The number of users using the website to start were significantly lower than the number of users logged by the system itself

Communication is often more important than the design

No more is this true when you work with a large company. Even the people you work closely with seldom grasp what it is you are really doing.

It's not their fault. Design is foreign to them. Most people have never worked on digital projects.

I spent more time explaining the same concepts than doing the actual work.

I find it often helps to provide a before and after document where you can highlight key details. Not only does this help communicate with the direct stakeholder, but also wider in the organisation. It allows them to explain to others with confidence what is happening.

Figure 3
Client guide on transition phases with explanations for design decisions such as putting the most visited page in the main navigation instead of everything.

It's interesting that the client was very concerned about providing training videos.