The 50M Dash Design Sprint

A two-day adaptation of the Google Ventures design sprint for internal tools

I recently facilitated a design sprint with an internal tools team at work. Our problem was perfect for a design sprint: we had a process to re-invent that’s never been closely examined and a team of people eager to make positive change. However, we were working with unusual circumstances and subsequently adapted the normal framework substantially to suit our needs. Though unconventional, the sprint was a success. Here’s what we did.

Photo credit Giorgio Montersino

First, we broke some ground rules

• We were working on internal tools and processes. Our experts and stakeholders were our users, which led to substantial changes around user testing.
• We only had two partial days instead of the usual five.
• We had fifteen people in our sprint because we prioritized including diverse perspectives over having a small group. We also had one person call in from Europe.

Planned changes

These were all known factors during the planning phase of the sprint, which allowed me to plan for changes.

Condensed schedule

I knew that we had limited time to start with, and was able to time-box all of our activities appropriately. The most substantial time cuts were to prototyping and user testing- two of us took the prototyping outside of the core sprint time, and we had a structured discussion with the users who were in the sprint instead of traditional user testing. Note that this requires follow up user testing outside of the sprint.

Long term goals

We were also able to save time around defining our long term goals- because this is for internal processes, this was something that the team had already established.

Map

Thanks to existing user research that was completed prior to the sprint’s start, we were able to draft a substantial map to begin with. It ended up being mostly accurate, and we didn’t have to spend much time revising.

Competitive analysis

As far as we could tell based on initial research, there aren’t currently any competitors in this space (at least not publicly available tools), so this was cut from the schedule.

Modified prototyping and user testing

Our favorite ideas were wide ranging, and two of them were entirely non-visual and related to data and automation. The other ideas were also extremely lightweight in terms of actual user interaction (versus system behavior).

Our user validation was far more conversational than user testing normally is in a design sprint. Since our users were also our sprint participants, we had structured, in-depth interviews about how these changes would work and how this would impact their current workflow, and ran through prototypes for the more visual ideas.

This wasn’t ideal because there are certainly things that we missed due to lack of testing. However, we were able to capture enough information to narrow it down to two ideas that would be most useful, and luckily, we have…

Planned follow-up

Now, we’re scoping out technical feasibility on our two favorite ideas. Assuming there aren’t any major, glaring technical shortcomings, we will conduct future UX research to validate more substantial prototypes of our changes, and likely meet for a follow-up session to incorporate this.

Unplanned changes

Shared ideas + group sketches

In most design sprints, the ideation and sketching exercises are conducted individually, and anonymously shared at the end. I initially planned to follow this, but as our sprint progressed, we realized that improvising would be a lot more effective.

As mentioned above, we had fifteen people in our sprint. This was great for a lot of reasons, but had to be carefully managed, particularly in light of our tight timeline. After we started the sketching exercise, everyone really wanted to talk to each other and ask questions across their domain since everyone was there.

About halfway through the idea phase, we paused, went around the table, and each shared a tl;dr on our ideas. It turned out that we had five overarching themes that the team was excited about.

In the interest of time and known similarities, we broke into groups of two or three for the final sketches.

Presentations

At this point, sketches are typically posted on the wall, and voted on. Some of our ideas were quite technical, and possibly not intuitive to everyone in the group. This came up pre-emptively, and we decided that presenting the ideas and discussing them would be more effective than posting them anonymously. This creates potential for bias, but in this case, additional context seemed like a worthwhile trade-off.

We made the right call: having everyone explain their ideas proved really valuable to make sure the team was on the same page.

Invisible ideas

We had a strong engineering and data engineering contingent in our sprint, and some of our best ideas were about how current processes could be automated. This was awesome, but presented unique challenges in user testing: how do you test not doing something?

Modified decision making

The invisible ideas were a contributing factor in the decision to take more an interview-style approach to user testing. We talked through pros and cons of these ideas, scoped out how much time they would save, and showed some mocks of how we could surface the information that users might need as results from automated processes.

After our interviews and conversation, we ultimately did vote. We narrowed our five ideas down to two, and then went even more in-depth around the two favored ideas with the intention to vote again at the end. The team decided that they would like to implement both ideas, but that it would be necessary to conduct more analysis outside the sprint to scope out which should come first.

The path forward

Our team learned a ton in the sprint, but aren’t quite done yet. We plan to scope out our ideas, review them again, and then conduct additional user testing and validation around exactly how we implement them.

Sample schedule

This is a lightly modified version of the schedule that we followed.

Pre-sprint

1. Draft map
2. Draft long term goals
3. Draft questions
4. Competitive analysis

Day 1

1. Review draft long term goal and questions (15 minutes)
2. Review draft map : shared brain (60 minutes)
3. Ask the experts : lightning talks (60 minutes)
4. How might we : organize and vote (20 minutes)
5. Break (10 minutes)
6. Sketch! (1 hour)
7. Presentations and Conversation (30 minutes)

Day 1.5 (in between sessions)

1. Aggregate findings
2. Prototype!

Day 2

1. Review day 1 (30 minutes)
2. Review ideas (30 minutes)
3. User interviews, in-depth conversation about ideas (2 hours)
4. Break (10 minutes)
5. Voting (30 minutes)
6. Path forward planning (1 hour?)

Future

1. Scope implementation
2. Review with team
3. Run more robust user testing

Thanks to my awesome teammates for being incredibly organized, participative, and willing to engage silly ideas!