Firstly, I am not anti design sprints, in the right environment, solving a relevant problem and run well, they are a very powerful tool. What I have experienced is that many of our partners were not ready to run design sprints, thus in many cases they did not yield the desired results.

In terms of ‘what instead?’, we've been playing with an approach here at Reason that engages stakeholders and decision makers with customer research, builds empathy, and ensures projects focus on problems customers want solving.

In the design sprints critique, I outline three realisations, the first being:

You can’t transform an organisation by focussing on a method. Stakeholders, decision makers and/or board members need to understand the needs, behaviours and cultural practices of their audience more than they need to see the validity of a solution.

My suggestion is that by prioritising time spent on understanding customers and the context of the problem rather than the solution, I believe we can drive much more lasting change throughout an organisation.

Don’t design sprint, Empathy Amble

The working title of this approach is ‘Empathy Amble’ or ‘Context Stroll’. One of the many good things design sprints taught me was that branding and badging an approach is an effective method of driving awareness and buy-in.

Thus, one of the principles of an Empathy Amble is to slow down. Sprinting is great when you are in solution mode, but when it comes to building empathy and understanding there is nothing wrong with slowing down. ‘Start slow to move fast’ is something we’ve said for a long time here at Reason.

Preparation

The Empathy Amble is not a silver bullet to fast track research (as in a good design sprint) - customer, market and business context research must be done. Depending on the problem, there are many ways to do this - read about how we choose the right research approaches here and here. The key is how you get your stakeholders and influencers to engage with and synthesise the research in a meaningful way.

TIP: The best way is to get stakeholders to take part in the research. We find it works best when each stakeholder joins a single customer interview or observation session as a notetaker - that way they can add their real experience to the discussions on day 1 of the Empathy Amble.

Research -> Data

Senior people value data, it is what they base their decisions on the day in, day out; and as designers, we know there is no substitute for direct customer interaction. So how do we turn this research into data the decision makers can engage with?

We turn our observations into physical data points, individual cards with quotes, observations and results printed on them. This can be an arduous task but it's worth it in the long run.

Once we have done this we are ready to prep the room with our data and get going with Day 1.

TIP: Try organising the room to have a wall full of customer data points, a wall full of market data point and a wall full of business context data points.

Day 1

Clue Hunting

The team spends the morning silently observing the insight data points, choosing research they feel are crucial. By turning the research into physical data points, participants physically engage with the research. And by choosing items from the wall they are ceremonialising the process, making it clear to the group that they find what this customer said or did interesting.

Hunching

We use the principles of circling to drive empathy with the insight data points but also with the other people in the room. With hands full of cards, participants stand in a circle and talk about why they found the data point interesting. Each team member builds on that insight, adding their perspective and including cards they have taken from the wall that they feel are connected.

TIP: If participants were part of the interviews, they can add context to the quote from what they heard.

Running this process several times allows the team to really synthesise and theme the research. This naturally creates a large-scale affinity map on the floor that the team can physically move around, according to how they have interpreted the research.

Day 2

We start the day by recapping the synthesis work and introduce the task of today: turning those big themes of customer research into an engaging story. First, we need to create our point of view.

Point of view

A point of view statement is our first step at turning the insight into a customer problem. We use some basic Point of View templates (depending on the research), to help the team galvanise around a problem and ensure it is based on insight. Take a look at the photos for some template examples:

TIP: using the research cards to build the Point of View statement is a great way of demonstrating our points of view are grounded in customer research.

Story Prototyping

Ok, so now it starts getting a little funky. We use Story Prototyping, which we came across after a talk from Angus Lowe, as a tool to rapidly create context and emotion around your customer challenges. Like any other prototypes, Story Prototypes can be created, tested and iterated quickly in order to communicate an idea and enable new learning.

The only difference is we are writing stories, not drawing pictures.

Whereas tradition prototyping revolves around a potential solution, Story Prototyping revolves around a potential problem. Unlike InVision or paper prototypes, story prototypes allow for faster iterations and higher emotional engagement.

What’s in a Story?

Each story prototype involves a character (your customer), a context (their journey) and a conflict (the problem we want to solve). Our Point Of View Statements should have done most of the work to define these, but we get everyone to write theirs down.

Step 1 - The Facts

Participants write their story by describing the characters’ actions. This allows us to get the basic facts of the story down on paper. But as we all know; facts are boring.

Step 2 - The Feeling

Now it's time to drive up the emotional engagement. Everyone revisits their stories, this time going a little crazy on the adjectives and adverbs. Every action should be paired it with a sense: what did it sound like, what did it taste like, how did it feel, what did it look like?

Step 3 - Make it Personal

Focus on the major problem that our character is looking to overcome and rather than looking at how we can solve it we want to know what effect (emotionally and physically) this problem is having on them, e.g. ‘The severe asthma had knocked her confidence for two years. She was completely fed up.’

Silent Critique

Once everyone has their first draft stories, put them up on the wall. Give everybody a bunch of dot stickers. Then, without speaking, everybody puts a sticker on every story, sentence or word they like. There are no limits to how many stickers you can use. By the end, you’ve got a ‘ heat map’, and some stories are already standing out.

We then run some 3-minute critiques on what the team liked about each of the stories, where we might want to merge stories or create new iterations.

Throughout this process, we are able to focus on the stories the team agrees with. By the end of day 2, we should have 3-5 story prototypes that the team have co-authored and are ready for testing.

Validating story prototypes

The fantastic thing about story prototypes is you can validate them in many ways. You can sit down with your customers, ask them to edit the story themselves, directly on what you have written. Have them explain out loud what they are changing and why.

TIP: print your stories out using double or triple line spacing to allow testers to pull them apart.

Use word processing software with track changes switched on to send out large numbers of stories to customers anywhere in the world. This is a great way for you to get qualitative style feedback at a reasonable scale - although it sometimes does take some nudging to convince respondents to update the stories.

Day 3

After the stories have been validated (this can be 1 day, 5 days or 2 weeks), it's time to get back in the room.

Story telling

Much like day 1, with all of the edited stories on the wall, encourage the team to view to take their time and read all of the stories, taking notes of the changes in language, context and narrative. Looking at the edits you should be able to identify key themes which will help you re-write your stories.

Re-Writing

This is an activity that the group does together — or if you are doing multiple stories you can break into teams. Start by listing the themes you notice as part of the story re-writes. Then write each line on a whiteboard. Each line will be a single step in the story, breaking it down line by line allows you to walk through each step and address the themes you saw it edits.

In each step, you will either reference a character, the context of conflict:

Lucy removed it from the fridge and set it down.

Then go through each sentence and stimulate the senses:

Lucy tentatively removed it from the fridge and set it down.

Then start to make it personal:

The anxiety was building. Lucy tentatively removed it from the fridge and set it down.

Thanks to Angus Lowe for this example.

Writing the story is hard work, and you’ll want to facilitate this carefully. Get one person to write, but don’t make them figure everything out on their own. The group should be engaged and discuss what happens next and give the one holding the whiteboard marker as much help as possible.

As you co-write your story, there will be plenty of things that perhaps didn’t come up when you first wrote the stories. That’s expected since we are now working with actual customer feedback in mind. There will also be plenty of differing opinions, this is where the facilitator has to work hard and not let people be ‘too nice’; you don’t want to write by committee. Don’t try and find a middle ground, let people talk it out and help the team make a firm bet in a single direction. Remember it is a prototype, so we can be wrong.

What was the point?

We have validated stories that clearly and emotionally articulate the problem we are solving for our customers. This is the perfect jumping off point for teams across the organisation to begin solving for these. Whether that be a design sprint, a customer journey mapping session or just a good old fashioned brainstorm, we have buy-in on the problem from all stakeholders, and we are actually solving a problem customers have, we can be secure to move faster and be more agile in the solution process.

We don’t need to have the senior team in a room for another five days to be part of the solution, because they are bought into the problem we are solving, which is infinitely more valuable than them taking part in defining the UI for the solution.

Hero image by ELENOR KOPKA elenorkopka.de/

‍