Recently, our research showed that our Environments feature, which is part of the Deploy stage of the software development lifecycle, was experiencing lower adoption rates and facing some usability challenges. Leaning on the evidence, Viktor Nagy, product manager for Environments, and I soon realized that we needed to look beyond a few small fixes and rethink our direction. We needed a design sprint. Below we share the process for creating your own remote design sprint.
What is a design sprint?
Design sprint is a term most people working in tech have heard in passing, but the meaning and purpose behind running one is often lost. A design sprint is a process for solving big problems through design, prototyping, and assessing ideas with customers. It's a method for developing a hypothesis, prototyping an idea, and testing it rapidly with as little investment as possible. Essentially, it's a great tool to align a team under a common goal, and answer the question: Are we on the right track to making a product that users will want to use?
Obvious benefits apart, why would a team want to spend the time going through this process? There are multiple selling points, but the main one is they help reduce time and money spent during the product lifecycle. A design sprint is a time-boxed way to get clear answers before investing in any development resources. It also brings the team together and gets everyone on the same page from the very beginning. This helps move the project forward even after the sprint concludes.
How we run remote design sprints
Jake Knapp created the design sprint process at Google in 2010, and during his time there he refined the process to be what it is today. Design sprints were originally designed to take place in person over five days, but over the past few years they have gone through continuous adjustments and refinements to adapt to remote practices. A more recent example being the four-day sprint we ran with the team.
Design sprint diagram showing the four-day breakdown
The big question here is how do we go about developing a process for GitLab that works across time zones, runs partially asynchronously, and works remotely?
Design sprints were originally run in a conference room, with everyone together. If you needed an answer, the facilitator was right there at the front, able to answer questions or help with activities. Things get significantly more complicated when everyone is located on different continents. But with all this, we managed to figure out a successful process through a bit of trial and error, and some of the following tips will help anyone run a successful sprint in a remote setting.
1. Thorough planning is the secret ingredient
Even an in-person, fully synchronous design sprint requires preparation. In a well-planned design sprint, the process does most of the heavy lifting and gets you the right results in the end. So, when it comes to running a sprint that plays across time zones, remotely and asynchronously, the importance of planning increases tenfold.
The first thing a team needs to do before starting a design sprint is to answer some important questions:
- What is the problem for the customer/user?
- Why is it important for the business/technology?
- What evidence do we have that this is a problem worth solving?
- What research insights do we already have about the design problem?
With answers to all these questions, the team now has established goals and objectives to sprint towards. The clarity around this ensures everyone starts on the same page, and is working toward a common purpose.
2. Set the time expectations
Design sprints can be demanding in terms of the mental capacity and attention participants are required to dedicate to them. Advance capacity planning helps participants to be more present and engaged, and to bring their best ideas to the table. This is only possible if they account for the time required to spend on the sprint in advance. It also gives the facilitator a chance to answer any questions related to the sprint and set the expectations ahead of time.
Part of this includes understanding how the team's time zones can impact asynchronous activities. It is good to look into the following:
- Review time zones and ensure sprint participants don't have to wake up too early or stay up too late. Sometimes this can be challenging and that's when leaning on the asynchronous aspect of communication is important. Tools like this time zone converter can help make this process easier.
- Depending on how far time zones are spread, some people may finish their day hours before others even start. Therefore, a one-day window likely isn't enough of a time box for a task/activity. A practical window can span 48 hours in some cases, meaning each day of the design sprint could potentially take two days.
- Ensure activities or announcements are assigned and communicated at the start of day in the earliest timezone. These are best shared both in Slack, and in the issue for the respective day.
- Account for unforeseen reasons for participants' unavailability as there will always be aspects we cannot control.
Partnership is key
Running a design sprint is not a one-person job. To ensure smooth operation and get the best results, the product designer and product manager need to team up. A strong partnership between the two can make the process of planning and running a sprint less overwhelming. The split in responsibilities can look something like this:
- Product can help define business and product goals, and reach out to users and team members to participate.
- Design can help facilitate and plan the sprint, and guide ideation and prototyping. Design also can diligently plan for testing the concepts that come out of the sprint.
Tools and tips
With all the planning complete, the biggest task is to facilitate and guide the team through a sprint process. Running a sprint involves using various sets of tools for different activities to ensure everything runs smoothly. During the sprint with the Environments team we took advantage of the following:
- GitLab issues to outline the activities and expectations for each day and serve as a single source of truth
- Mural boards to collaborate on activities such as 'How Might We's', ideation, and prototyping
- Zoom to meet synchronously, along with a Slack Channel for asynchronous updates
- Google Drive to share files, such as the lightning talk recordings
As a facilitator, I also took advantage of GitLab's asynchronous culture to pre-record videos such as our Sprint Kickoff and Activity Walkthroughs so participants could go through these in their own time during each day.
Celebrate the wins
Once the sprint week has concluded and the team has landed on an experience or feature they want to move forward with, it's time to celebrate the wins!
Design sprints can be a lot of work, and it's great to look back on what all has been accomplished. Find ways to share those wins through team channels such as Slack and weekly meetings, or go even broader with blogs or social media posts. Who knows, this might also encourage other teams to test out the design sprint process as well!
Support at GitLab for design sprints
A remote design sprint helped the Environments team to come together and make a contribution to solving a large problem. We were able to come out of the sprint with a clear concept to move forward with and a shared understanding around what the future of environments at GitLab could be. I was motivated to further document the resources that came out of this activity and make it accessible to the team. We landed on a design sprint process that can be shared, re-used, and built upon by other designers. Not only were we able to solve something that fit what we had been looking for this whole time, but the team came together during the process and built it up together.
