Conducting a Design Sprint at Alzheimer’s Society.

Part 2: Facilitation and Structure.

John Dickens
13 min readMar 14, 2019
RITE (Rapid Iterative Testing and Evaluation) on testing day.

This article is part two of two. Read the first part here, where I write about the reasons for running a Design Sprint in my organisation.

This article covers some of the general things you might want to consider when leading or facilitating a Design Sprint. The second half details how we ran each day.

Facilitation

Sprints are an excellent tool that can allow your team to solve problems for your users. The key word here is team.

If you are going to run a successful Sprint, you need a facilitator who can help guide the group throughout the week. In my previous article, I already wrote about the importance of making sure everyone is on the same page before you start the Sprint, but the facilitator also needs to make sure that they’re on top of this, as well as some other things, throughout the week.

Facilitating structure

What is the role of a facilitator? The most basic thing you need to do is to ensure everyone knows what they’re doing. You need to know your Sprint structure inside out, but crucially you also need to have confidence in every step. Don’t know why the Sprint book you’re reading suggests doing an empathy map? Either A) find out why it suggests you should do it or B) if you know why, but honestly believe it’s not valuable to your team, then don’t do it.

That last option might strike fear in your heart because it goes against what might be perceived as the ‘perfect’ model of how Sprints should be run, but you need to do what fits your team/company/project. The perfect model for a Sprint is the one that you can mold and adapt based on the project’s needs.

Facilitating actions

Facilitators aren’t ‘leaders’, as such. Leaders direct, facilitators guide. You have a duty to keep your team on track throughout the week. What you should absolutely not do is direct the sprint away from the group consensus. Your status as a facilitator does not mean you control the project’s direction.

Instead, any interventions you make should be more about providing those “hmm” moments to your team and not the “arghhh!” ones.

There will likely be points where the group is at a fork in the road and it will seem difficult to make a decision. It’s important to explore your options, let the discussion flow both ways, and keep open minds. However, it’s also important that you don’t waste time in these discussions where it’s clear that you’re going round in circles. This is why you have a designated decider in the group. When decisions can’t be made, they have the final say and the group moves on. Like the facilitator role, you should get consensus from the whole group about who the decider is- but it’s usually someone who is a senior stakeholder in the project. Gaining this consensus normally makes these decisions go down better too.

The small details count

There are a few things you should probably consider throughout the whole week that likely seem quite trivial, but will make a real difference to the team’s work, morale and communication. They are, as follows:

  • I recommend that the facilitator uses a laptop to present with (more on this later), but generally, it’s not a great idea to have everyone around the table glued to their device. Keep the focus, and suggest to the group that laptops/tablets/mobiles aren’t allowed during the Sprint sessions.
  • Get some snacks for people, bring them out around 10/11am each day to fill that breakfast-lunch gap that so often cripples us (well… me).
  • Collectively decide when the group will break for lunch, and eat in a different space to where you’re working, if possible.
  • ‘Check-in’ with people individually and as a group. If you notice that discussion is fading and people seem a bit weary, recommend a 5–10 minute break. Don’t push people, or yourself.
  • Capture everything. Take photos of all work that is produced throughout each day, and upload them to a shared folder every evening for all to access.
  • Have fun. I think this sort of creative work is conducive to generating good morale within your team — embrace that.

Structure

As I mentioned earlier, it’s definitely useful to follow other team’s Sprint formulas, but you should consider if you need to make changes to it based your project’s or organisation’s needs.

The important thing is that you know your structure, and you know the value and meaning of each session. I like to lock this in place by doing a Keynote presentation for each day, outlining what we’ll be doing, why, and what we will get out of it. This is really useful for the team, but I found it especially useful for myself as it allowed me to be reminded of what was coming next, hour-by-hour, day-by-day.

This presentation was beamed up on a whiteboard with a projector. We kept this on all day, and we used it to our advantage by layering post-its on top of the slides, or taking pictures of the post-its and putting them in the slides to reference later on.

Day-by-Day

This is how we did it, so feel free to follow, adapt, or completely ignore:

Monday — Goal setting

Intro (15 minutes)

This is pretty self-explanatory. At this point, everyone should know why they are here and loosely what they are doing, but it’s best to recap anyway.

I also use this time to go over the Ground Rules of the sprint. These are rules that are collectively decided. Ask the group to spend 5/10 minutes to think of some rules they’d like to follow for the remainder of the week, such as “don’t talk over others” or “think with an open mind”. I’m usually a bit hesitant to do this sort of thing because normally people will follow these rules even if there’s no formal declaring of them. However: 1) it gives people a chance to warm up their brains and post-it writing skills, 2) it puts people on an equal footing to each other in a setting where a cross-functional team can contain different disciplines and seniority.

Goal setting and sprint questions (3o minutes)

The first session involving post-its! The aim of this session is to simply answer the question: why are doing this? It’s an intentionally broad question, but it allows the team to think about the wider aim of the sprint.

A good way to start this task is to ask sprint members to individually write down what they want this project to look like in:

  • Six months
  • 1 year
  • 5 years

Example:

“In six months, the drop-off rate on our sign up will decrease by 20%…”

Once everyone has finished, stick the post-its up on a wall and go through them. Ask whoever wrote each post-it to spend a little time explaining what they wrote down.

Hopefully, people will have produced similar answers. At the end of this session, you’ll need an answer to ‘Why are we doing this?’. Collectively agree on this and you’ll have something that you can refer to throughout the whole week.

For reference, our goal was to ‘produce a meaningful sign up’. Essentially, a sign up that was quick, easy, but also gave the user the tools and knowledge to start taking action to become more Dementia aware immediately after they finished their sign up.

Map making (45/60 minutes)

Slightly adapted from here.

You and your team now need to work out how your user will get to the goal that you defined in the previous session.

  1. Start by asking people to individually map out how users attempt to get to your goal in the product’s current form. This should be 10 post-its max, with one ‘action’ per post-it, running horizontally. For this section, it’s important to include all the things that are going wrong, or could be improved in the current journey.
  2. When everyone has finished, stick all the maps up on the wall. Ask each map-maker to spend two minutes going through their map, step-by-step.
  3. Review each journey and ask the team to place dot stickers on the steps they find interesting or useful.
  4. Finally, create a ‘master journey’ which encompasses the most useful steps towards creating the ideal journey. Validate that the journey is feasible by running it by the product experts in/out of your Sprint team.

This last step might take some time and, although it is intended to guide the rest of the week’s work, I think it is important to note that it can be adapted later on.

Our ‘master journey’ — quite short, but does the job. We took a photo of the journey and then placed it in the slide to reference later on.

Lunch (60 minutes)

‘How Might We’ (30–45 minutes)

‘How Might We’ statements are a way to think about how we can solve specific problems for our users. Think of all the problems a user might encounter with the product or user journey you are focusing on, and frame this from a user perspective rather than your business’s goal. Reframe these problems as opportunities.

Example problem: Users don’t necessarily know what is expected of them when they sign up to become a Dementia Friend.

Example reframed HMW: How might we allow users to be more informed about what it means to become a Dementia Friend in order for them to have confidence in signing up?

  1. With post-its and sharpies, ask the team to write as many HMW statements as they can, individually.
  2. Get all the statements on a wall, and then organise thematically, with similar ideas being grouped together.
  3. Give each member two votes (two dot stickers) and ask them to vote on which statement they think is the best out of the bunch (including their own).

Select your Target / Review (15 minutes)

Going back to the map, ask the group to circle the most important ‘moment’ that you think is crucial to the project’s success. Keep this visible throughout the whole week!

That’s Monday done. Check in with the group and ask how things went. Go home, relax, and get ready for tomorrow.

Tuesday — Sketching

A bit less hectic than the previous day — day 2 focuses on exploring and generating ideas that will get your team towards the goal you defined on the previous day.

Lightning Demos (60–90 minutes)

This is a really useful exercise that allows you to look at how other organisations, or even your own, go about solving some of your user goals and How Might We statements. Split the group up and ask them to find solutions from other companies or organisations. Each group will need to present the best solutions they find for 3 minutes (per solution). It’s a good idea to get them to sketch out the process too, and pin these up for all to see.

Lunch break (60 minutes)

Four-step sketching (rest of the day)

I followed John Zeratsky’s guide for this, and it works a treat.

This is where things get especially interesting. Those that have used the design studio method will be familiar with this method.

It’s important to stress to your group that they don’t need to have any artistic talent for this task, just as long as they can draw a few lines and boxes!

  1. Notes. As a group, take some time to silently walk around the room and review everything that has been produced since Monday. If things aren’t visible and on the wall, get them up there. Encourage people to take notes.
  2. Ideas. Jot down and sketch out some ideas on possible solutions — these will be kept private.
  3. Crazy 8s. fold a piece of paper into 8 sections, sketch a variation of a possible solution in each frame, spending one minute per sketch. Limit this to 8 minutes in total.
  4. Solution sketch. Using the ideas explored in the Crazy 8s, each member of the group should create a three-panel storyboard using post-its to show how their chosen solution works. Make sure they have annotations and are as self-explanatory as possible. These are also to be kept anonymous.

When this is all done, gather up all the sketches and keep them safe to revisit tomorrow.

Preparing for testing — recruitment

You should now have some time to start the recruitment for the testing day on Friday. If you want to do your testing remotely, which I think is probably the best case in such a short time frame, I wouldn’t recommend anything else other than PingPong. Setting up your recruitment parameters and filling out the testing slots takes no longer than 20 minutes depending on your target audience, making it perfect for sprints. You can read more about how we used PingPong here.

Wednesday — Decisions

In the first part of this day, you’ll need to collectively make a decision on the best possible solution. This can be tough, and the Sprint book’s guide for day 3, again outlined here by John Zeratsky, outlines a good method to deal with this.

For our sprint, though, we approached this slightly differently. A lot of the sketches from the Tuesday were relatively similar and, as we were working with a fairly simple process (a sign up), it didn’t seem like we needed to follow all the steps outlined above.

Explaining solutions

However, we made sure to review each of the solution sketches as a group. We dedicated an hour to this in total:

  1. Silent critique (5-10 minutes). The group goes round the room and silently looks at each solution, taking notes if needed.
  2. Open critique. Participants get 3 minutes of uninterrupted floor time to explain their solution to the group. Asking each Sprint member to briefly explain their sketch, the process behind it, their inspiration and how they envision it to work in practice.
  3. After each speaker, the group is free to ask questions. When this is happening, ask everyone to keep the HMW statements and Goal in mind.

In normal circumstances, I’d introduce some form of voting here, but this wasn’t really needed due to the reasons mentioned above. There was, of course, some conflict, but we didn’t feel that we needed a formal voting system to decide what to go with. It will likely be different for your sprint. In which case, you can follow the GV format here.

Instead, we just came to a group consensus about what we’d start to build, and from there we started to create a user/wire flow that dictates the build of the prototype. Use a whiteboard for this, because you will want to erase a lot of stuff. You might also want to remember the role of the decider here, in case things end up in a stalemate.

You’re going to need a lot of room…

Keep working on this after lunch, and by the end of the day, you will hopefully get to a pretty solid solution.

Thursday

By Thursday, things slow down a little bit in some senses (you’re not really working to the structure of sessions anymore), but you still have only one day to create a clickable prototype. No need to be worried! Your team has already decided what’s on each screen in the previous day’s exercise. From here, you’re in a pretty good position to start building the prototype.

This should be done however you feel is best for your project. You can go straight to on paper, scan it in, and upload it to a service like InVision. That’s a pretty quick process to do. If you have a bit more time, as we did, you can go ahead and whip up some mid fidelity screens in Sketch instead of drawing on paper. Use what is easiest for you with the time you have. The important thing is that, by Friday, you’re in a position to test a concept.

You might want to allocate roles amongst your team here. For example, I spent the whole of Thursday making the prototype, whilst my colleague wrote up the script for the test. We also had another team member write up some basic copy. In the late afternoon, we all came together to review what we had so far and left an hour at the end of the day to tighten things up if needed.

Friday

And here we are… testing day.

If you’re familiar with usability testing then this is a pretty standard day for you. Here’s what we did, and the software we used:

  • Via PingPong, 2 UX Researchers/Designers took turns to conduct the interview with users remotely.
  • We sent an InVision link to participants to start the test once we had asked a few warm-up questions.
  • Using the observation feature of PingPong, we set up a room where the rest of the team could watch the tests and make notes in real-time, affinity mapping as the sessions progressed.
  • Because we knew that the prototype’s copy was critical to the success of the user Goal, after each session, we took inspiration from the RITE (Rapid Iterative Testing and Evaluation) method and made minor edits along the way. This was only informed by the results of the tests when patterns began to emerge.

That’s it. If you have any questions, comments, or suggestions: please send them my way.

Hey, I’m John, a London-based UX Researcher and Designer currently working at Alzheimer’s Society. If you’re interested in my work, feel free to talk to me at hello@johndickens.co.uk

Dementia is the UK’s biggest killer, and deaths from the disease rise year on year. Organisations like Dementia Friends and Alzheimer’s Society do vital work in supporting those living with dementia as well as their families and carers.

Ultimately, however, we need to find a cure, and we can only do this with the help of our donators and funders. If you’re interested in making a donation or finding out more, please take some time to take a look at both websites.

https://www.dementiafriends.org.uk/

--

--

John Dickens

UX Researcher at PlayStation. Previously at Pulselive + Alzheimer’s Society. johndickens.co.uk