Our learning over the first 12 weeks of this project delivered a number of prototypes and these culminated in our planner. It brought together our understanding of user needs for content, services and patient information. It also identified some of the important things for users; test results, prescriptions, appointments.
However, there are reasons why we shouldn’t or can’t continue with these prototypes as our next step. Primarily because they are prototypes and they aren’t plumbed in – they can’t work yet. While they are great to test ideas, they don’t add value for the user because they aren’t connected. We want to help meet user needs from the outset.
This doesn’t mean that our work on booking or the planner has stopped. In fact, Dom has set out our next steps in his blog here. However, we believe that we can make our content more actionable before booking becomes a reality and start delivering value straight away.
A few weeks ago we published our first pieces of content on alpha.nhs.uk. (Hinrich wrote about it in more detail here.) We think this content is more actionable than what already exists but it is still not quite connecting services and content.
What we’ve done:
We’ve spent the last couple of sprints iterating content pages so they act as the first step to integrated content and booking. They will continue the principle from the booking prototype of being able to book a service and provide information and guidance around that, but then hand-off to existing booking services.
The example for physiotherapy below outlines this best. You can try it yourself here. On relevant content pages, in this example shoulder pain, there is an option to get physiotherapy.
After choosing ‘Get physiotherapy’ we need to identify which GP the patient is registered with. We want to do this so we can offer the right services. For example, in some areas it is possible to book direct with a physiotherapist whereas in others it is via a referral from a GP. In our physiotherapy example we have only prototyped one area with some made up options.
Once we know a patient’s GP practice we can then offer treatment options and hand off to existing booking systems. As with all our prototypes, this isn’t connected yet. There is more work to do to make a live service like this, but we think it is a way we could start connecting content and services.
On Wednesday 16th December we tested our prototype at a GP practice to see how the proposition held up. As usual we learnt lots and there were definitely some issues with our first prototype. For example, some users were not expecting to be able to book direct with a physiotherapist. They were expecting to have to see their GP first. This gave us an insight in to the current expectations of patients. It was also evidence that our prototype didn’t make it clear enough that this journey was to book physiotherapy direct, not an appointment with the GP.
Why do it this way:
Releasing early and releasing often is key to how we work. It means we can deliver value to users sooner and It means we can fail fast. As a team, we’d much rather discover early that the ideas we’ve been prototyping around action-focused content and booking services don’t scale in the way we imagine them to, than working away in secret and deliver a big bang release that doesn’t do what it ought to.
Having this in the open will also mean we can test with many more users than in the lab or guerilla sessions and really understand if we have met user needs. Please add a comment or email email@example.com if you want to let us know what you think.