Design Sprints at the BBC – EuroIA 2016 – Answers
At EuroIA 2016 some of the BBC UXA team ran a workshop on Design Sprints. There were around 90 participants and lots of questions. We answered many during the workshop. But here are follow-up answers to all the questions that were asked.
[This post will be updated over the next few days]
EuroIA 2016 – Answers to questions
How do you change the mindset of participants who are hardly able to think without the usual limitations or and in functionalities? – Fiora van den Bosch
It’s a task for the facilitator: you can’t really change people’s mindset, but you can prevent them from converging during the diverging phase, or vice versa.
Cyrièle Piancastelli answered this during the session by stressing the importance of the facilitator. Make sure that everyone knows the rhythm and pattern that a sprint follows. You can then hold them to account and direct them back to the right kind of activity. But people are different and have different strengths. Some people may be more comfortable editing and evaluation rather than creating. Let people play to their strengths. But also commit to the stages, rules and constraints that you acknowledged at the start of the sprint.
What does a team look like? Product managers, development and marketing or UX only?
We always make sure that the sprint team is as diverse as possible. We think the ideal sprint team size is around 7 people. We try to make sure we have a good range of skills. Bring in specialists when needed – including subject matter or content experts. Choose a team who can make the prototype plus the ideas as accurate and realistic as possible. Aim for consistency in the team – have the same people available throughout.
The design sprint as described by the Google Ventures team is very structured; however, do you think it makes sense to squeeze in some activities from the innovation games methodology. And at which stage should this happen? – Mak Abdennabi
Sprints are one tool that we use to approach a specific type of design challenge. They’re good when you want to explore a problem or opportunity with a fairly well understood boundary. They usually involve a multidisciplinary team. But they’re just a specific form of divergent and convergent design process. And they’re made up of a range of tools and techniques. I think it’s fine to swap in different techniques to appeal to the demands of the situation or the skills of the team.
Once you get comfortable with the techniques to you can start to plan your own workshops and sprints. Choose the techniques or games you think will be most effective. In the book Gamestorming Dave Gray talks about different games for opening, exploring and closing. I’m also a fan of the tools and techniques described by Ideo.org in their Design Kit.
Sprints help you form a hypothesis and explore different solutions to test that hypothesis. So I think it’s fine to choose different tools to help you do that.
One thing to keep in mind though is the pace of a sprint. It means that adding in more techniques might not make you more productive. Be sympathetic to your participants. Try to design the process to deliver the most value and insights in the most efficient way.
To do Day 1 you need prior detailed research on the user journey, yes? – Joy Mwihia
To take part in a Sprint you should have a good understanding of the audience – their needs and motivation. Not every member of the team needs to have created a journey map or completely understand the current service – although that will help.
Sprints are fast. You don’t want to be stopping or diverting the planned activities to fill in gaps in understanding. But you do have a day dedicated to Understanding. The activities that you carry out before a Sprint can also help with this. Share any research you have. You can also arrange workshops, perhaps using a POINT activity to create a shared level of understanding within the team.
Day one can provide time to talk to subject matter experts to fill in any gaps in understanding.
Do you think a design sprint is an alternative to user research?
No. I think Sprints are a design process and a research method. They help you to test and idea, so they’re a way to gain insight and refine your understanding of your audience. Any time you’re talking to your users is a chance to gain extra insights. Refine your knowledge throughout a Sprint. Grab any opportunities to learn about your users opportunities.
Insights gained on the testing day of a sprint often provide inspiration for subsequent sprints or design.
[More answers will be added over the next few days]