I’m typing this article whilst one of our designers, David Evans, co-facilitates our introduction to user-centred service design course with Rochelle Gold, our Head of User Research. It’s both a proud and a nerve-wracking moment; seeing your own work being delivered by someone else. David’s doing a good job, though, I’ve got nothing to worry about.
Why are we doing this?
The vision for tech in health & care, published in 2018, states that:
“All the services we build, buy or commission should start with user needs.”
Starting with the needs of users, and keeping them at the centre of the design process, is the best way of delivering products and services that are valuable to both users, and the NHS.
But being user centred, isn’t just what designers or user researchers do. It is the responsibility of everyone within an organisation. We all say we want to do it and understand its value, but not all of us knows how to do it in practice.
To meet this need, Rochelle and I designed a one-day training course as an introduction to user-centred service design for staff within the Product Development directorate and the wider NHS Digital. We ran a few trial sessions with internal teams, which allowed us to iterate and evolve the training to a format we were happy with.
We made a proposal to our executive director; we would train the staff, but we need her to recommend everyone to apply.
We got her blessing, so now we must deliver on our promise.
The double diamond design process
The double diamond design process, first introduced by the UK Design Council 15 years ago is a brilliantly simple, yet comprehensive way to describe how we design at NHS Digital. Due to its effectiveness, we wanted to use it as a framework for our trainees.
One of the most important roles for the double diamond is to point out to the teams where they should and shouldn’t start. How do teams know they are solving the right problem? Do they need to spend time finding that out?
During the session, when we’ve completed a specific part of the training, we point out to the participants where we are at that point. This is helpful as it’s often difficult to know how to use given frameworks or models in practice.
User research is paramount in user-centred design and we wanted to make sure this is reflected in our training course. From the start, we wanted to avoid using ready-made personas or spoon feed user needs to the participants. The value of user research can really be understood if you’ve experienced it first-hand. We knew we wouldn’t be able to teach the participants to be user researchers, but we could demonstrate its value by asking them to interview colleagues for real
We carefully crafted our initial problem statement about their experiences in GP waiting rooms to allow the participants to be interviewed as real users who may have experienced the problem. We of course explain about the ethics in user research and how the participants don’t have to answer questions they may not want to — just like in real user research, but this has not been a problem at all.
We split the group into two, interviewers and interviewees. The participants then conduct one-to-one interviews about their experiences in GP waiting rooms. These interviews will highlight loads of smaller problem areas the teams will analyse, map out and choose the one they want to start solving during the rest of the session.
What is the right problem to be solved?
One of the most crucial parts of any design process is to ensure we are in fact solving the right problem. There’s no point in ending up with a brilliant solution to the wrong problem and we make a big deal about this during the training.
We start with an initial, high-level problem statement, which is based on real-life health & care related issue about GP waiting rooms and the anxiety they may cause to patients waiting for their appointment. Following the user research, the teams will have identified multiple smaller, but more detailed problem areas which they will write problem statements for.
Writing out the problems into problem statements ensures some thinking will have gone into defining the problem, describing why the problem exists (based on research), and what is the effect of the problem. The last part is particularly important as it provides us a high-level view of how we may measure the success of potential solutions to solve the problem.
Design is not just planning what we are going to do, journey mapping or sketching. Design must also be about creating. Jared M. Spool describes design as:
“…the rendering of intent. The designer imagines an outcome and puts forth activities to make that outcome real.”
This is what we advocate in NHS Digital and this is what’s taught on the training course. Only by creating something, can we find out whether our design will actually work as intended, and how we should develop it further.
Prototyping must be accessible and not dependent on the designer’s abilities as a coder, and this is especially true in our training course. For this, we bring along various accessible materials to prototype with — paper, cardboard boxes, lego bricks, scissors, pens, etc. Even play dough has found its way to our prototyping kit. We don’t use computers in our prototyping at all during the training; by introducing more accessible prototyping methods, we also hope to see ideas explored in this way across the organisation. Lo-fidelity paper prototyping is a quick and inexpensive way to validate early assumptions.
Service design thinking and doing
It’s important we move towards service design thinking and one of the simplest ways towards that is to think about the wider context, the physical spaces and people involved, and not just the digital solution we have in mind. We encourage our participants to explore the non-digital world by understanding their user’s journey end-to-end, from their appointment booking to attending the appointment. We also encourage the teams to prototype the whole service, e.g. the waiting room with other patients. Many teams engage in role play to bring the prototype to life.
We have a target of training 700 people within a year — that’s 23 sessions with 30 participants in each. Clearly, we need some help and are now training our designers and user researchers to run this course in Leeds, London and Exeter.
This also means the course is not just benefiting the participants, but also the designers and user researchers who are delivering the training. I have personally learnt so much about things I take for granted in the design process when teaching and guiding the teams. The questions they ask, the problems they encounter are all relatable to the real world.
We have agreed with our organisational development team that we can use this training course as professional development for our trainers as well. They will get practical experience in presentation skills, and how to lead a workshop. How to adjust the material and agenda to suit the group when things don’t always go to plan.
Results and outcomes
Measuring the true success of a training course is not easy. We are adding up the number of attendees on the course, but the real impact must be whether anything has changed in the way people and teams are working; Are we delivering better services, because of this training course?
It would probably be hypocritical to say we are and it’s because of this course, but every now and then I hear when people have used some of the techniques, we’ve taught them. Whether it’s as small as using the rapid idea generation in a team meeting, or referencing the double diamond, it’s all good; We’ve nudged something.
Our first goal is to deliver the training internally to our directorate and the wider NHS Digital. However, we have already received requests to deliver the training to our partners in the NHS and we’re happy to support all those if we can. It’s beneficial to us all; the more of us understand what user-centred service design actually mean in practice the better services we can design and deliver to our users.
If you would like to find out more about this training course, you can contact us at: firstname.lastname@example.org.