Laurel Gattenby: March 04, 2021
One of the items on the Roadmap we discussed in Monday’s blog is the ‘draft feature’. This gives users the option to part complete ReSPECT forms and come back to them later.
In this blog, Laurel Gattenby, User Interface and Interaction Designer, and Jonathan Waldheim, NDS Product Manager, talk about how the team explored this problem which seemed simple on the surface but was proving difficult to define and solve.
What we did by Laurel Gattenby
To try and overcome this rapidly and collaboratively, the ReSPECT team decided to use the Design Sprint approach. In this blog I’ll tell you a little bit about this process, how we tailored it to NDS and what we learned.
As most people who have planned and run a design sprint before will understand, we had the familiar problem of not being able to get a full week of time from everyone we needed to attend our sprint. As a compromise, we ran a condensed version. For comparison, this is what a normal design sprint looks like;
The first day is typically dedicated to choosing what the best use of the sprint time is. We already knew that drafts functionality was our top priority, so we cut that entirely.
We started on day 2 which we combined with day 3 (usually Tuesday and Wednesday). We did quite a few of the usual exercises, then decided on the best solution at the end of the day.
This ended up not being detailed enough, so on the prototyping day when I split off to create what we’d designed, there were still many unanswered questions for me to deal with.
We were able to arrange some testing sessions for the last day with the team in attendance. These went well and put us in a good place to hone the prototype for further testing. Here’s an edited illustration showing what our sprint looked like in the end:
What we learned – day by day
This wasn’t the first time I had run a design sprint, but it was the first time where I had done one remotely at NDS. There was a lot to learn.
Here are some reflections from Jonny, Product Manager for Digital ReSPECT:
We were lucky to have a clearly defined problem to overcome, without which we could have come unstuck very early in the process. Defining the problem ahead of the sprint did mean that we jumped away from some of the context setting that may have been useful.
The ‘User Story’ describing the problem:
In a traditional design sprint, subject matter experts give short talks on the subject at hand. We felt that might still have been useful, even if the majority of participants were aware of what the ReSPECT process is and what the digital product aims to do.
I think it’s fair to say this ended up being a massive design slog for Laurel. While everyone else got on with their days, she started early and worked very late. Not the ideal way to get the work done.
On reflection the sessions on the Tuesday could have had clearer outputs for the Design team to work from. Alternatively, there could have been an extra session for the whole group to define the wireframe together, so that Laurel would just need to hone the user experience rather than create it from scratch.
Finally, Thursday was split in to ‘review’ and ‘test’. As with all design sprints, recruiting users can be difficult. This was the same for us, it’s a very busy time in the NHS at the moment, so asking clinical people to find thirty minutes for a user testing session at fairly short notice is a big ask.
We did manage to get feedback from our NDS Clinical Lead, Paul Miller, and the ReSPECT Forth Valley Clinical Lead, Lynsey Fielden, but we know that it would have been ideal to have a variety of other users so that we could observe reactions from those who have been less involved in creating the digital ReSPECT.
What we learned about the effectiveness of a design sprint
However, that is not to say what we did was not a success. We are reflective practitioners after all and it is normal for us to look upon work we’ve done with a critical eye.
Our objective was to come up with a user interface to solve the problem of how to do drafts digitally and we think we’ve done that!
The challenges of running a design sprint remotely
Here are some reflections from Laurel on running a design sprint remotely:
There are numerous challenges to running a series of workshops like this remotely, but a few advantages as well!
Jonny and I have talked a lot about how design sprints (in person) almost feel like attending a conference. Lots of creative energy floating around. They certainly feel like a special event.
This is a difficult feeling to re-create when using online tools like Miro and interacting over calls. I’m not sure it’s possible to get all the way there, but we’re all living in a separated world for a while longer so we can certainly try to get close.
The results of our sprint were positive. We now have a prototype of the drafts functionality that has been looked over by one of our Clinical Safety Leads and had feedback from a key stakeholder in the project. Our next step is to polish the prototype further and run more user testing in a few weeks.
The team had been struggling with this particular bit of functionality for longer than I’d like to admit, and the design sprint was instrumental in getting us to this point.
Video demo of design
Here is a sample video of Jonny talking through the design (he knows he won’t become a professional voiceover artist anytime soon, but it illustrates quite nicely what can be designed rapidly when working collaboratively)!
We need sprint participants!
One of the biggest hurdles when planning a design sprint is finding a time when the right people can clear their schedules and fully participate. If you are a clinician or clinical staff and would like to join us and help design the technology that you’ll be using in the future, please get in touch and we’ll let you know when anything relevant to you is being planned.