Design Sprints are a method of moving quickly but designing thoroughly. You innovate and you learn. You mix techniques, focus on different skills at different times and work quickly and collaboratively. At EuroIA we delivered a workshop that was all these things – Design Sprints at the BBC. This is one of two blog posts to supplement the workshop. This is a summary – plus extra techniques and resources that we didn’t have time to mention.
The workshop plan
Sprinting is a user-centred design process. It’s designed to help you to be quick but thorough. You create a small team. Then you dedicate a relatively short amount of time to develop ideas, test them and learn lots.
Sprinting can be seen as a ‘product development framework.’ That’s one of the reasons we created a workshop for IAs focused on Sprints. I’m interested in opportunities and dangers inherent in a process that limits scope. Sprints don’t and probably shouldn’t always take account of broader contexts. Hopefully by engaging more IAs in thinking about Sprints we can be more considered in how we engage with them. But I’m getting ahead of myself.
At EuroIA the plan was to deliver the first 3 days of a Sprint. Sprints are usually spread over 5 days. Each day focused on a different stage of forming, developing and testing a design. The workshop began with the Understand stage.
Before we begin
Before you begin you should establish the rules of your Sprint. Also agree and share constraints or design principles. Shared principles and rules will improve the success and the performance of the team. Establishing these things early (on Day one of the Sprint or before) sets expectations and makes it easier for the facilitator to intervene and pull people back on track. Constraints help with focus. Agreeing them early means that everyone is aware of immovable limitations that will affect the success of your sprint and ideas.
The rules of a Sprint
- Everyone participates
- Have one conversation at a time
- Withhold judgement
- Get up and draw
- Be comfortable
- Be easy on people, tough on ideas
- Be timely
- Be present
- No devices
- No jargon
- No hippos (which is jargon for ‘highest paid person in organisation’)
Identify the principles and constraints that are most important to your senior stakeholders. Sprints are democratic. But we’re realistic and know that some opinions do matter more than others. Capture and share the main concerns and constraints of your key stakeholder(s). Use this as a North star to keep you on track.
POINT
POINT is an exercise we’ve used in pre-sprint workshops to engage with a broader set of stakeholders. The ideal sprint team should usually be about 7 or 8 – taken from a mix of disciplines. We invite technical and subject matter experts, clients and product owners. We always choose a dedicated facilitator. But if there’s a larger team or set of stakeholders, a POINT workshop is one way to gather their input, involve them and give us inspiration for Day one.
Each participant in the workshop completes the POINT Sheets as homework. They present the homework in the workshop. We can then dot vote on any problem, opportunity, insight, need or theme and use this as the basis for the Sprint challenge.
Understand
The Understand stage allows you to define and describe the specific problem and get a better, shared understanding. We ask lots of questions. The most important is ‘what do we want to find out over the five days’? IA is about constructing shared meaning. Day one of a Sprint is the natural territory of an IA. The team tries to build a shared language and understanding, and then focus and commit to a challenge for the rest of the sprint.
I talk about UX architecture as following a parallel path to other double-diamond design processes. UXAs at the BBC begin each project with a process of understanding. We listen and talk to people about their assumptions, definitions and understanding. With this raw data we can begin the process of shaping and sharing information and meaning. We describe what we’ve heard and work with our colleagues to decide on the shared meaning. We build consensus and shared intent which will direct the project.
We do the same in the Understand stage of a Sprint. This is the day when we share our perspective of the problem or opportunity. We always go into a sprint with a fairly specific challenge or opportunity. Day one allows us to clarify and define that challenge.
Experiences and stories
We’ve used a range of techniques to do this. At EuroIA we talked about creating low-fidelity experience maps. This can shape a user-centred understanding of the opportunity you’ll focus on. Thinking in temporal terms about how experiences unfold forces a user-centred perspective. It always begins to reveal pain points and opportunities that can become the focus of your sprint. So we usually start by telling stories.
We’ve used a range of storytelling techniques on both the Understand and Diverge days of sprints. Stories engage the creative parts our brains. But they also have built in sense-making. Humans can smell when a story doesn’t stack up – when something unrealistic happens or when a character acts out of character. So stories have become a well-used tool in the way we do sprints.
There are lots of resources on story and experience mapping. On Day one of a sprint we don’t get too hung up on format. But this artefact is something that the UXA can use throughout the Sprint and beyond.
Sometimes we’ll have prepared a service or experience map for the Sprint. Or we’ll create and update our map throughout and after the Sprint to develop the detail and fidelity. Placing ideas within a service blueprint as well as an experience map or persona lifecycle can show when they might be disconnected from a broader strategic context. Within a sprint there isn’t always lots of time to create and develop these maps. But an IA is a natural person to own this type of artefact and find time to develop and use them.
How might we?
The Understand day should end with the team agreeing on a specific challenge. We use ‘How might we’ questions. How might we questions are an opportunity for me to talk about Goldilocks. I think there are plenty of things in life where you can talk about a Goldilocks zone – things being just right.
We try to make sure our question is just right – not too specific, but not too general. They should be just the right size to pose a problem that you can attack in a week. I like to think of Sprints as experiments. Your ‘How might we’ question is the hypothesis. It needs to be a hypothesis that you can test with a prototype that you only have a day to build.
Dot voting
Dot voting is simple. You give everyone on the team some dots and they use them to cast votes on the idea(s) they want to pursue. We use dot voting throughout Sprints – at various stages. It’s a simple and intuitive way to make decision-making more democratic. But there are a few tips we’ve learnt as we’ve used it.
You sometimes need to a adapt the number of dots/votes that you give everyone. This usually depends on the number of ideas. You’re using the technique to reach a decision. So we make sure we can adapt and flex to get to a decision quickly and efficiently. We use ‘super votes’ (given to key decision makers) and extra votes given to everyone to avoid situations of deadlock.
We’ve also experimented with other version of voting. Dot voting is great at giving everyone a say. But we’ve seen an effect where dots cluster around ideas that score early support. It’s sometimes hard to judge whether this is because the ideas are the best or that we’re drawn to building consensus. We’ve experimented with blind voting – votes going on the back of the paper. We’ve also stuck ideas to an envelope and used ‘virtual money’ placed in envelopes instead of dots. These techniques might help to avoid the bias we’ve seen elsewhere. But they’re not perfect and do slow things down – it’s harder to count the votes. So think about which democratic decision making process is right for you and your team.
Diverge
The Diverge day has a nice balance of working individually and getting inspiration from others. We like to make sure that there’s space for everyone to pursue and develop their own ideas.
Circle storm is an individual activity we sometimes use to warm up the brain. It gets new ‘sprinters’ comfortable with the idea of creating lots of ideas and not settling for the first thing that comes to mind. Often the biggest hurdle on day 2 is maintaining the stamina to keep creating ideas, even if you think an early one might be your best.
We’ve used a range of techniques to develop ideas and trick the brain into staying motivated and exploring alternatives. We often use ‘Crazy 8s’ as the basis for idea generation.
But we’ve also used basic prose storytelling to appeal to people less confident with visual thinking. We’ve used three types of stories which we’ve categorised as ‘Page’, ‘Chapter’ or ‘Book’. Each type of story describes a different ‘length’ of experience. The categories might vary per project. But telling stories which describe different durations, length or depth of experience helps us to make sure we have a range of solutions.
For each story we describe the situation, which includes the needs or motivation of the user. We then describe the experience. This is the area where we develop and describe the idea – writing our potential solution into a user experience. We then try to describe the impact of the experience – what are the next steps for the user? Are there a range of possible outcomes? We give each story a catchy title – which helps people engage and remember them.
This technique appeals to journalists and editors who are more comfortable writing than drawing. Reading the stories to the team is one way to share inspiration. And they can fuel and focus their own ‘Crazy 8’ session.
Telling this sort of story is quite dependent on having solid and well-understood personas. Without established personas there’s a tendency to invent stories and ideas disconnected from reality and true audience needs. So make sure your stories are truly connected to real user needs and scenarios.
The key thing in this day – and throughout the sprint – is to make the otherwise invisible visible and shareable. On Day one we made definitions and assumptions visible. In Day two you need to work hard to document and share ideas. Humans have great spatial memory. Capture ideas on paper and post-its. Stick them to walls. And move around them to help improve the effectiveness of any Sprint team.
Converge
Day three if focused on deciding and preparing. Again we use dot voting to help us make decisions. To keep things fair we make sure to document ideas in a consistent way. On day two we should have created ‘solution sketches’ for each idea. These pages detail the idea in enough detail for any member of the team to understand. As with all sprinting, your description should fit in the Goldilocks zone of having just enough detail.
We use a range of silent and speed critiques to dig into the ideas and make sure everyone understands. Critiques are how ideas are evaluated and discussed. We then vote. We try to be democratic. But we’re sensitive to the opinions of key stakeholders and use super votes and facilitated discussion to capture their opinions.
There’s also logistical planning that needs to begin at this stage. You need to be able to test your ideas with the audience during a Sprint. Think about which ideas might complement each other. Are any ideas mutually exclusive? How might you start to build a prototype to test the idea? During a sprint you need to test the ideas with something you only have a day to make. Keep this in mind as you vote and commit to the ideas you’ll take forward.
One technique we’ve used to interrogate and refine ideas is Beetle. It’s a simple way of asking a range of questions of the ideas you’ve created. You can have a bank of questions that you ask of all the ideas. You can also add extra ‘legs’ to document challenges or points of clarification on a per idea basis.
Prototyping and testing time is valuable – all time in a sprint is valuable. Your Converge day is your chance to make the best use of time. Don’t be afraid to spend time questioning an idea before starting to plan your prototype. It’s much better to find (and try to fix) all the weaknesses in an idea before the pressure of the prototyping day. If you find an idea with problems you can’t fix, don’t not carry that one forward in the sprint – maybe another method is more suited to evaluating that idea?
IAs and design sprints
I chose to talk about Design Sprints at EuroIA16 because I think they represent both a threat and an opportunity to well-architected systems. If IAs and user experience architects fail to understand the opportunities contained in these methods, we increase the chances of sprints resulting in unintentional architecture. Sprints aren’t always appropriate. But they are a powerful set of techniques to level the playing field, focus on a challenge and have a team work together to test out a possible solution. Hopefully the workshop and these posts will encourage more IAs to think about how they might engage with and improve the effectiveness of Sprints.
The featured image for this post is thanks for the ace Peter Vermaercke. You can find more of his photos from the event in this EuroIA 2016 Google photo album.
Leave a Reply