As part of the NHS.UK Alpha project we developed a prototype for a type 2 diabetes planner. It was based on real interviews with real people and we took it through several iterations.
We discovered from users that it was compelling to bring together appointments, prescriptions and personalised content in one place.
We focused on what users wanted and did this without worrying too much about the underlying technology – we didn’t constrain ourselves with what was currently technically possible.
Yes, that means we’ve built a prototype that doesn’t work – and that’s OK.
We know these questions need answering
We’ve had a lot of decent questions from people working in the health system about how the prototypes would work, for example:
- How are you going to do login?
- How are you going to integrate with GP practice systems?
- How does this work with e-referrals?
- Where are you getting prescription data from?
If we were to build this for real, we absolutely would need to answer these questions, but at the moment that’s premature. At this stage, what matters is working out what things will really help the user.
If we had tried to answer the technical questions before we started prototyping, we’d still be scratching our heads and thinking about it.
Vision first, then technology
It’s easy to dismiss sound ideas, thinking, “we can’t build that because system X doesn’t support it”.
But that’s the wrong way round! We should build the underlying systems to serve user needs – not constrain them.
In my experience, the most difficult problem is working out what things to build that can actually help users.
Building it is the easy bit! We know how to build big, scalable services, so we can solve that later. The tough bit is working out what to build.
Prototypes help communicate vision
When we show people the prototype – especially diabetes users – they get it. The prototype communicates a vision that’s far more tangible and powerful than a document or powerpoint.
If we can all get behind a vision, that leads us to the technical capabilities we need in the health system.
Having a tangible user-needs based prototype also gives a new frame with which to answer the questions on how it should be done.
This is a long winded way of saying, “start with the user, work back from there.”
Are you working in this area? We’d love to hear from you: email@example.com