The first accuRx design sprint

Hi, I’m Matt, I’ve recently joined accuRx as a senior product manager. One of my first jobs was to run a design sprint for the team I joined. I’ve led teams through discovery and short sprints before, but never run a design sprint as set out in the book Sprint by Jake Knapp. This blog post covers my reflections on the process and what we got out of it as a team. I’m not going to go into detail on the process as that is well covered in the book and elsewhere (I found the AJ&Smart YouTube channel really helpful). Some useful context however is that we ran a 5 day sprint, as per the book, not the 4 day Sprint 2.0 which AJ&Smart cover on their YouTube channel.

Hopes and Fears

We ran a design sprint to help give us focus on how we could help practices better communicate with other care providers, with a clear outcome on where we should focus our development. Our added advantage was that the team had already been conducting user research so everyone knew a lot about our users and the issues.

My hope for the week was that we would be able to validate our ideas, get an idea of the things that users found most useful and create a good shared understanding in the team of the why as well as the what.

My fear, being new to the team, was that some of the exercises in the design sprint had been done before and I was worried about wasting time repeating these or losing people’s interest by doing them again. I was also worried, given the time already put in to research, we wouldn’t come up with anything new.

The Sprint

The running and organising of the sprint was the easiest task of the week. The book and checklists really help you focus on the structure and if you are unsure of anything then the numerous videos on YouTube provide a great insight. A couple of obvious things I wish I had thought about beforehand:

• The existing knowledge of users in our team made day 1 easier / quicker than expected. This threw me off a little as I tried to stick to my timeline
• Regular breaks will keep everyone motivated and don’t worry about bringing a conversation to a close — take a note to kick it back off again if it is important or use the break to move on.
• Share what you are doing with other teams, especially if this is your first sprint. People find it interesting.

Outcomes

Overall the sprint went really well. We ultimately came up with a high fidelity prototype using Figma that we tested with 6 people before the sprint was finished. It received great feedback and we are just about to launch our MVP. We’ll now iterate and work on the feedback as we build out the features we originally designed.

As part of the process I asked for feedback on every session (straight after each session rather than expecting people to remember) and the comments were largely positive.

People liked:

• The structure of the days, it helped push for clear decisions and rapid progress
• Dotmocracy was a really popular tool to stop circular discussions (Wednesday)
• Design process was particularly popular, we had run similar sessions before, but not in the same order etc. (Tuesday afternoon)

People didn’t like:

• There was some concern that given our existing knowledge we were too biased by our own ideas, which limited our thinking
• Advance prep of some of the sessions (such as the lightning demos) would have been useful for people to bring more ideas

Reflections

It’s been three weeks since our design sprint and my key reflections on the process are:

• On Friday night, after the sprint I was chatting with a friend, a Director of Design, who told me that he had banned his teams from running design sprints because they were “design theatre”. They solved UX issues but not the underlying problems that users face. My immediate reaction was, ergh have I just wasted a week, but I don’t think we did. The team had conducted a good amount of research upfront and we had a key problem we wanted to solve. The Sprint process helped refine our thinking and give it direction. This upfront research was super valuable and I would like to be in the same position in future Sprints, i.e. to have a well understood problem to solve, not just a UX issue.
• That said, I’d be happy to try a Design Sprint with a completely new problem. However, I’d make sure the facilitator kept the group focused on the problem solving rather than the design. This would also make the expert sessions more important as the knowledge would not be in-house, so I would think about recruiting target users for these.
• Running the Sprint as a product manager who would soon be working on the product I found it hard not to get involved. I blurred the lines a little more after the first couple of days, getting involved in sketching etc but stayed out of the voting and decision making. It worked well because I was so new. In future I think it would be best for the product manager to not facilitate, so they can influence the decisions as part of the sprint team more.
• Commitment to the process shouldn’t be underestimated. I/we were super fortunate that everyone cleared their diaries and made the whole sprint. This meant we didn’t need to use time on bringing people up to speed etc. It also meant we finished the sprint with a shared level of accomplishment. If you can get everyone to commit for the whole week (or 4 days) then do.

In a couple of weeks I’ll write a post about our progress turning our Sprint prototype into a real product.

Get in touch to let me know what you think. Thanks!

Matt