In August 2018, my team and I were tasked to build a new Saas solution for the Customer Service team at Zappos.

While narrowing down the scope, interviewing stakeholders and figuring out tech requirements, I started a round of focus groups to understand what problems the agents had with the current solution.

Because of the nature of the exercise, the output was a big set of post-it notes on a whiteboard. I tasked some of our ops team to collect the output, digitize it and upload it on our drive to share with the team.

Next, I planned to gather a few more data points from our Customer Service Analytics team, and actually go about solving some of the problems the agents brought up.

Design Sprint planning session

Some may think that a meeting about a meeting is not necessary, but we are talking about a Design Sprint. We need a clear goal, and clear problems to solve.

To start our Sprint strong, I thought it would be ideal to have a quick 30-minute session with our Product Manager and Engineer Lead (EDP format) to smooth out the process, and set expectations.

We began by looking at the main takeaways of the focus groups we ran a few weeks prior to this session. The problems and pain-points were clear:

I created the chart above to illustrate how solving for the first six issues, would cover 70%-75% of user problem occurrences.

After grouping and adding meaning (we were able to consolidate them from six to two, as some were different aspects of the same workflows), we came up with two clear categories:

  • frustration on starting and processing XOs (a common user flow)
  • lack of data tracking (common vernacular used by users is “concessions”)

With that in mind, we set out to figure out how to frame the problems and structure the Sprint:

Sprint Agenda and Deck

The Design Sprint was built to span three hours, 9:30am – 12:30pm.

We used this method for a couple of different reasons:

  • the devs on the team have very limited experience with UX processes. We want to use the least amount of time to prove value so that they’ll be open to longer, more involved Sprints in the future
  • speaking of the devs again, they were under release during this Sprint. We could not postpone it, so keeping the devs for just half a day wasn’t too demanding
  • I wanted to reward ourselves and start building trust by having a nice delivered meal at the end. This would help bonding and could further the conversation in a more relaxed environment

Agenda

9:30 am – Arrive and settle in

9:40 am – Agenda and activity explanation, quick Q&A

9:50 am – Lightning talks by Dev Ops: expand on the problem statements

10:05 am – How May We

10:20 am – HMW Affinity exercise and dot voting

10:40 am – Crazy 8s

11:10 am – Explanation and dot voting

11:40 am – Lunch and next steps

12:25 pm – Last five-minute clean up and leave the room

Design Sprint Deck

I download and edited the Google official Design Sprint deck and sent it to all participants three days in advance.

How May We Photos

Right between the “How May We” and “Crazy 8s”, I snapped a couple of photos to add to the Sprint documentation.

Conclusion

The Sprint was successful. We were able to generate about 60 ideas overall.

Of these 60, I created a Matrix to factor in Dev and Design time and complexity, User Delight and Long Term Use, Innovation and Business Value.

After the matrix we had a clear picture of what to do next:

  • 8 solutions scored high enough in the matrix to allow for researching and scoping
  • of the 8, 1 was completed in the next Dev Sprint and brought very promising beta testing results
  • developers started appreciating the value UX brought to the table and Sprints are now an established part of our team’s process

Takeaways

  • three hours is really the minimum for a Sprint to come together. Ideally, we should spend a day on it
  • picking a slower time for the devs could produce more engagement
  • planning sessions are essential for a successful Sprint
  • during lunch, we generated some good conversations around the solutions we found