Here at Βι¶ΉΤΌΕΔ Weather, we love experimenting with different ways of working. We're never shy of a new design challenge, so finding smart ways to collaborate with a multidisciplinary team and quickly test ideas with our audience is super important. One tool in our kit is the design sprint.

What are design sprints?

, a design sprint is_ "a five-day process for answering critical business questions through design, prototyping and testing ideas with customers"._ To us, it's a great way of bringing diverse teams together to solve a problem. The beauty is, it's a really collaborative process that allows you to make the most of everyone's perspective and knowledge, even those who might not traditionally be part of the design process. This helps your wider team buy into your design journey and keeps them invested along the way.

A typical five-day sprint looks like this:

• Day 1: Map out the problem and pick a place to focus
• Day 2: Sketch and refine solutions to the problem
• Day 3: Decide on a direction and create a testable hypothesis
• Day 4: Create a realistic prototype
• Day 5: Test with your users

How do we use design sprints in Βι¶ΉΤΌΕΔ Weather?

Like all good design methods, we believe design sprints are there to be tweaked and tailored to the project and team. Here we'll share three different ways we've used design sprints, and the things we've learned along the way. We'll cover:

1. The iterative design sprint: running multiple design sprints in sequence.
2. The non-dedicated design sprint: organising a sprint when you don't have a dedicated sprint team.
3. The super-elongated design sprint: stretching sprints across six weeks.

Let's look at three different ways we've used design sprints in Weather and what we've learned:

1. The iterative design sprint

The goal of this sprint was to redesign an existing piece of functionality. We had a dedicated design team, a fixed project workspace and a set of internal stakeholders that we needed to work closely with.

The experiment? What happens if, instead of trying to solve the problem in one five-day sprint, you work on your challenge over several, back-to-back sprints?

We followed Google's five-day framework almost exactly, with one big difference: we ran three connected design sprints over three consecutive weeks. Each sprint took place straight after the next, without a break. This meant we could take the things we learnt in one sprint and build on them in the next. Here's what our three weeks looked like:

Process to be repeated over three weeks.

• Day 1: Understand current picture (on weeks 2 and 3 use this time to analyse results and identify next actions)
• Day 2: Sketch ideas
• Day 3: Refine ideas and storyboard
• Day 4: Build prototype (or on weeks 2 and 3 add to the exiting prototype)
• Day 5: Test prototype (and on week 3 create wrap up)

What did we learn?

Stacking sprints is great if you have a large challenge and lots to test Google's five-day framework works really well when you have a dedicated team and a well-defined, constrained challenge. However, we wouldn't have been able to cover everything we wanted to learn and test using just one design sprint. Stacking is a great way to keep iterating on your ideas until you're happy with the outcome.

Take a break! By their nature, design sprints require intense bursts of energy and hard work. Running too many concurrently, without a break, can be incredibly wearing on the team. If you're planning to run multiple sprints, schedule a one-day break day between each sprint.

Build a project war room If you can, find a dedicated space to run your sprint. It'll mean you can take over walls and surfaces with your sprint documentation and fully immerse yourself in the process. It also means you can create a super useful, visual sprint calendar in the team space so everyone knows what's going on.

Stakeholder communication is key It may be that your stakeholders can't be with you every day of every sprint. If that's the case, why not send a weekly group update by email? Remember to include the sprint objective, what was achieved, what you learnt and the plans for the next sprint. We found this a really useful communication tool, and a way for absent stakeholders to send us their questions or comments to consider.

Book your test days early! It's really important to involve your stakeholders in the test days. To avoid calendar conflict down the line, decide on your test days as early as possible and get your stakeholders booked in before their calendars book up!

2. The non-dedicated design sprint

The goal of this sprint was for the team to conceptualise some future functionality for Weather. Our sprint team included our Weather UX&D team, an external design agency, our product manager and our tech lead. However, because our team had to juggle multiple projects, none of this sprint team could be dedicated solely to the sprint.

The experiment? How can we make sprints work when your team has other commitments?

We decided to stretch the sprint from the usual five-day recipe to fit over a two-week period, to see if more time would help our team with their competing work priorities.

Here's what our two-week sprint looked like:

• Day 1 & 2: Understand current picture, sketch and refine
• Day 3 & 4: Storyboard (and get feedback)
• Day 5 & 6: Build prototype (and get feedback)
• Day 6 & 7: Create testing script and do a pilot run through
• Day 8 & 9: Test prototype and analyse findings
• Day 10: Review and decide next steps

What did we learn?

Make sprint timings work for your project and team
Allocating typical sprint activities to fit a two-week period was a success thanks to a clear timeline and focus for each day. Having a time-boxed period was still useful, but it may not necessarily need to be an arbitrary five days. Experiment with what works best for each project you do.

Invite stakeholders for specific timeslots rather than 'all day' invites
For our busier teammates and stakeholders, all-day sprint invites are just not feasible. Try booking in specific timeslots throughout the sprint instead that still allow them to be part of it and to give feedback. Choose timeslots where their input will be most-needed so they feel their time is well spent and you get to make the most of their attendance.

A day after testing to review your next steps is really useful
The traditional sprint stops after testing, but you may find, like us, that you'll want some time to analyse the testing insights, write up some main points and then use those as a springboard to figure out your next actions. Making time for this allows you as a team to be super clear about your direction. This is definitely one of those points to make sure your key stakeholders are there so you can get everyone's buy-in.

3. The super-elongated design sprint

The objective of this sprint was to get everybody agreed on a set of requirements for a new piece of functionality within the Weather responsive website. This was so we could begin to prototype and test it. It was vitally important for us to create a shared understanding and single source of truth for this new functionality, as it didn't just involve internal teams, but external teams that were located around the world. Our team was sprawling, including the Weather UXD team, our developers for responsive web, the product team for Weather, and an external development partner who would be building some of the new functionality, based remotely.

The experiment? Can we run a sprint that joins up remote teams over a six-week period to successfully gather and define requirements?

For this experiment to work, we had to discard the idea of using specific days for assigned activities. Instead, we broke down the elements of a design sprint with the intent of following those steps over a six-week period.

Here's what our sprint looked like:

• Activity 1: UX and product - Understand current picture
• Activity 2: Everyone - In person workshop
• Activity 3: UX and developers - Build prototype
• Activity 4: UX and product - Test prototype
• Activity 5: Everyone - Build consensus

What did we learn?

Naming is important!
This project showed us that calling something a 'sprint' really helps the participants feel like they're part of something together, providing a structure and sense of shared purpose.

Collaboration tools can be your saviour, but know when only 'in real life' will do
For remotely located teams, software like Trello and Slack can make working as simple as possible. It takes a bit more effort, but with consistent planning you can make sure everyone is able to see information and take part in remote workshops and activities. But, a note of caution - ask yourself when it really matters to have everyone together. For us, we had an in-person workshop at the start that was vital to build team camaraderie and a shared trust. Identify the most useful points to have everyone together and try to make that happen.

Make the outcomes of your sprint useful
What is your sprint delivering? Whether it's a set of ideas or a prototype that captures a single-source-of-truth for stakeholder requirements, remember that your output reflects a lot of time and effort from your sprint team and it needs to have some utility. Our final prototype ensured that we gathered consensus on what needed to be built, as well as reassuring stakeholders who were less technical or close to the project that they were understanding what we were going to make. Demonstrating this value allowed us to show that design sprints are useful, and got our team more motivated to run them.

Keep up that momentum
Are you working on a project that takes time? It can be challenging to keep momentum during longer projects, particularly when there may be lulls in frenzied activity. Make sure you're having regular check-ins as a sprint team and, if appropriate, sending out progress emails to a wider group of people. This helps keep your project in people's minds and allows everyone to maintain some connection with your work.

Keeping the design sprint spirit alive

Our experiments show you can get loads out of design sprints, even without having the 'perfect' conditions. But where the sprint shape can flex, there are certain fundamentals that help keep the spirit of the design sprint alive:

• Be generous with the time spent upfront to understand the challenge and what you're trying to do
• Time-box your activities to focus your energy and maximise your efforts
• Keep it collaborative and involve people from all relevant parts of the business
• Validate your ideas with useful feedback from your users and your stakeholders

Working within these principles, we've found the design sprint framework can be pretty flexible to your needs. No doubt we'll continue to experiment with the boundaries as we work on new types of projects and challenges. Watch this space!