The 4-hour design sprint
How we did it, what we learned, and would we do it again?
A hairy, ambiguous problem space, fast-approaching deadlines, and constraints in securing team members’ time. Likely a familiar scenario to most folks working in the fast-paced product world — and this too was another day in the life of my team at Shopify.
Lightning-quick background
I’m a senior program manager on a team that supports the internal products and tools that Shopify employees use to capture, share, and organize what’s happening in the organization. Some big changes were happening around the process of how we build product (endearingly referred to as Get Sh*t Done), and we were asked to redesign some of the tooling to better reflect this.
Beyond simply updating the tool to support the new process, our key goal was to reduce friction for users and drive more consistent adoption, contributing to increased data accuracy. Of course, we also had a fairly short timeframe to make all these wonderful changes to the product and our team was stretched working on other in-flight initiatives.
Our designer extraordinaire/my partner-in-crime, Janice Chow, and I discussed the approach we wanted to take to start honing in on the problem space.
While we would have loved to follow the tried, tested, and true 5-day design sprint, we didn’t have the luxury of a dedicated week.
Jokingly (and loosely inspired by Tim Ferriss’ 4-hour workweek, perhaps) we decided to see what we could condense in to four hours and how far we could get. As Orson Welles famously quipped (and I took the liberty to further interpret),
The enemy of art [or, design?] is the absence of limitations.
In our case, we optimistically agreed that these constraining four hours would help our design thrive, and we’d be putting that to the test.
Before the Sprint
We sat down to frame the key outcomes we were hoping to get out of the sprint, which were to:
- better understand our users’ pain points, goals, needs;
- go wide on design explorations;
- then, finally narrow down and get deeper on the explorations.
We were realistic about how much we thought we could condense into our session — about halfway through what you’d get at the end of a typical 5-day sprint.
We identified the criteria for the participants we wanted to recruit. We’d include our own development team, stakeholders, and a mix of people who use our product (mostly Product Managers and Product Leads at the company). This ended up requiring 10–12 people in total, which meant our designer and I would both be facilitating. Lucky for us, we were recruiting internal participants, so it was fairly easy to get people to join the sprint on short notice.
We also built a high-level agenda and the key activities we wanted to cover, which I’ll break down into a bit more detail next, as well as observations from when we ran the sprint.
During the Sprint
The Intro — 15 min
Since most of our participants didn’t know each other, and about half of our session involved collaborating and aligning as a team, a quick icebreaker was essential. We ask team members to share the last picture they took on their phone with the group — this usually surfaces an interesting story, or cute animal/kid picture, and works well to let people’s guard down a little bit.
Power-context session — 1 hr
Day one of the 5-day sprint is typically focused on ‘understanding’ — unpacking the problem, leveraging data and diverse expertise from the group.
Our challenge was to distill the context for our participants into a 1-hour slot, without just dumping a confetti of information on them.
Our tool-set for context included the following:
- Recap on the business needs that led to the work we were doing — it was important to tie it back to the bigger picture and the “why” our team was focusing on this work.
- Sharing our product’s two key personas — their goals, situations using the product, and their intent. While there is much debate about the usefulness of personas in the product and design world, in our case we’ve found them helpful to frame different needs and mindsets for our product. (And beyond the personas, of course, we consistently test everything we build with people).
- User experience maps created in advance of the sprint, which visualized the entire end-to-end experience that both our personas go through in order to accomplish their different goals, and their pain points across the journey. A user experience map is very similar to a user journey map, but focuses on pain points specifically, which we felt was important for us as we knew the experience needed some love.
- Reframing the business needs and persona pain points into How Might We (HMW) questions. These were meant to promote brainstorming when we got to our sketching activities, and be broad enough that there were a wide range of solutions but with some helpful boundaries to provide guardrails. We also shared some actual verbatim quotes from our users related to the How Might We questions to add more real context.
That ended up being a dense hour, but we seemed to keep our audience captive enough until the next set of sketching exercises.
Time to get sketch-y
1. Solo sketching activity — 30 min
Our first activity was a slimmer variation of Crazy Eights — which we called Crazy Sixes (original, right?). Similar in concept, we had participants fold a piece of paper into six squares, and they had 10 minutes to get their six ideas on paper. Then, they picked one idea to draw in more detail within 20 minutes.
We intended for participants to really “diverge” in their ideation by thinking wide during this part.
The sketching was very productive — everyone was scribbling vigorously and no one got stuck. One or two participants asked if they could just write the ideas out vs. draw, which we okay’ed as we didn’t want to block anyone from being generative.
2. Group sketching — 1 hr
We then split the room into three groups — with four participants in each. Every person had to share their one detailed idea sketch, and then the group decided which idea they liked best, or if they could combine their respective ideas into one “super idea”. They had an hour to finalize their team sketch, on a large flip board sheet.
There was a lot of discussion between groups, however, converging wasn’t easy.
While some teams more easily collaborated and gravitated towards the ideas they liked naturally, others were getting stuck.
One gap seemed to be the comfort level with drawing. One group decided to just list their ideas on the flip board. Some slight personality conflicts also emerged where different perspectives on ideas were not easily bridgeable. More time was also needed and we ate into our 10-minute break. However, in the end, all the teams were ready with something to present.
The big reveals: final presentations — 1hr
It was then time for each team to present their ideas to the rest of the group. Two of our groups had managed to present a sketch in the end while one group just had a list of their top ideas.
Themes consistently emerged across the presentations and each team was able to explain the rationale and alternatives they considered in their approach.
We were able to get through the presentations and end the sprint about 10 minutes over time.
It’s a wrap: overall thoughts on the 4-hour sprint
What worked really well
1. Synthesizing context into experience maps
This allowed us to succinctly cover personas, their needs, and their pain points in a visually absorbable way for participants. Distilling what could be a day’s worth of information into an hour, without overwhelming participants, is not easy, but this approach seemed to work well. We also printed out the experience maps for each persona so the participants could have these as reference points during sketching.
After the session, we also received feedback from participants that the context was relevant in helping them with the next set of activities.
2. Super generative solo sketching exercise
A clearly facilitated Crazy 6s exercise, followed by additional time to expand one idea into a more detailed sketch, worked well for all our participants.
3. Well-planned agenda and time-boxing
While it may be obvious, it’s still critical enough to note! Fine-tuning the agenda around our desired outcomes, and tightly keeping things on track, allowed us to maximize the time in the session.
What we could have done better
1. Ensuring we had the right participants
One gap that surfaced was when one participant felt that the scope we were looking at didn’t reflect how her team used the product, which ended up being an edge case. However, this made us think to add more criteria during recruitment to ensure we don’t have a participant who feels like an outsider to the rest based on how they’re using the product. While we need to consider edge cases in our design, we felt this type of sprint would work best with a group of participants representing general usage of the tool, so it wasn’t the optimal setting for a participant representing a minority of our users and they may have felt disengaged.
2. Better boundaries around scope
While the context session was helpful for participants to better understand the problem space, the How Might We (HMW) statements still felt too broad and made the scope a bit ambiguous. Creating that perfect balance of wide-enough-yet-narrow-enough HMW statements isn’t a science, but we think more defined scope parameters would have provided better guard-rails to our participants.
3. Helping teams converge on their ideas
While the solo sketching exercise went well, the group alignment and sketching exercise had some gaps. Teams were getting stuck for a few reasons:
- Comfort level with sketching was low in some groups. We’d consider recruiting actual designers or participants with stronger design skills so that each group would have one such member to facilitate getting their ideas into visuals. While these types of sprints encourage everyone despite their skillset to draw, with the compressed amount of time we had it surfaced as a blocker, so we’d expand our recruitment criteria to include a few folks with design chops to accelerate this part of the session.
- Stronger opinions from select team members prevented quicker alignment. Maybe we should have jumped in more to guide these conflicts of opinions as facilitators. A potential solution could also have been having teams dot vote on their favorite ideas to help move the converging process along.
In summary
This format worked really well to generate a TON of ideas, from different perspectives, and to surface clear themes in a short amount of time. It also kept our participants fully engaged. After the sprint, we catalogued the themes and ideas and used them as an input to create our product backlog, which we then prioritized and were able to start refining the design based on this. The sprint accelerated us moving into our design phase in a more informed way. The bottom line: we would do it again, 100%, with some tweaks to make it even more productive.
— — — — — — — — — — — — — — — —
Shoutout to Janice Chow for being a great partner running this sprint (and coming up with awesome things like our personas & the experience map) and all our participants/guinea pigs: Nataly, Zabrina Hossain Ahmed, Erin Marchak, Steven Wu, Betty, Ami, Cristian & Vincent!
If working on problems like this sounds like fun, check out our careers page.
