It's Not a Marathon, It's a [Design] Sprint

Waiting for the right problem

Our product team has been looking for the right opportunity to run a design sprint since we learned about the process last year. The design sprint creators claim that a sprint can be used to solve a wide variety of problems, and Wyzant is trying to solve problems of many different sizes. We didn’t want to rush into our first sprint with a problem that wasn’t a good fit for the format. Furthermore, we needed to find a week when all of the necessary team members would be available, and when we had room in our pipeline to act quickly upon the outcomes we discovered in the sprint.

As we neared the end of our recent term, we realized the opportunity to sprint was upon us. We had big ideas for expanding our offering of 1-to-1 learning to adult learners nationwide, but we still had a lot of questions about the best way to do it. Design sprint to the rescue!

Sprinting by the book

We wanted our first sprint to be as boilerplate as possible so that we could make informed decisions about what worked for us and what didn’t. As a result, we followed the recommended schedule almost to a T.

Image credit: Sprint, by Jake Knapp et al.

Read the full schedule on the Google Ventures site.

Preparing with a practice run

The logistics were coming together for our first sprint. There was one bit of preparation that was giving us some heartburn: we had never done this before. Asking for a full-week commitment from seven people is a lot, especially at a company of our size. The last thing we wanted to do was waste their time.

To overcome our lack of experience, our facilitator and decider planned a dry run of the full sprint process. The Wednesday before our sprint week, we took an afternoon to walk through every step of the sprint from start to finish, making notes about where we had questions and where we wanted to adjust the process to fit our plans. The dry run familiarized us with the process in a way reading through a checklist couldn’t.

Our sprint goal

The long-term goal we wanted to attack in our sprint: Use our best-in-class online learning tool to facilitate lessons for adult learners.

Sprint questions:

How do we ensure that learners understand our approach to 1-to-1 online learning?
When is the right time to introduce the online learning tool?
How can we highlight the tutors’ robust qualifications to adult learners?

The team

Decider 1: Jesse, Product Director
Decider 2: Erika, VP of Product
Facilitator: John, Product Design Lead
Ben, Associate Product Manager
Liz, Product Marketing Manager
Mac, Senior Product Designer
Paige, Front-End Developer
Rhiannon, Research Lead

For our first-ever sprint, we had two deciders: one who joined us for the entire sprint (Jesse), and one who only dropped in for critical moments, such as the decisions on Wednesday morning (Erika). The in-sprint decider acted as a co-facilitator — another helpful move in overcoming our lack of sprint experience.

Our prototype

We built a click-through prototype of a desktop web browsing experience, starting with a Google search and ending with sending a message to a tutor.

Our test users would begin their experience from a Google search results page. Clicking a result would take them to a landing page explaining what Wyzant is, and then kick off their search for a tutor. The following screens presented each user with a series of questions about their learning needs in order to find tutors who were the best match. The users were then given a list of tutors to compare based on price, student reviews, strength of match and other factors. Finally, the test users would select one or more tutors to contact.

A redesigned search results screen from our prototype

Our prototype’s screens were generated using a variety of methods. Our designers grinded out brand-new designs using Sketch. Many of our prototype screens required simple copy changes to pages that already existed on our site — for these screens, our developer created a local build of the site and inserted the new copy where needed. To create our fake Google search results page, we conducted a search and used a web browser inspector to tweak the content of the results. All screens were stitched together using InVision, our in-house favorite tool for prototyping and sharing designs.

What we learned

We were happy to find answers to at least two of our three questions, which sounded like par for the course for other first-time sprints. Watching the online learning tool in use turned out to be hugely important in helping new customers understand not only how online lessons work, but what Wyzant is. Once customers saw the tool in action, they realized the advantages of using Wyzant to find personalized, 1-to-1 help through online lessons.

We also learned a lot about asking new students the right questions. Our prototype allowed us to collect feedback about an entirely new way of helping students explain their needs in order to find the tutor who’s the best fit. Watching the reactions from our test users gave us a bunch of ideas for continuing to refine this flow.

What worked? What didn’t?

After our sprint, the team submitted their feedback about the process via anonymous surveys sent to the facilitator.

One thing the team agreed on was that we were proud of the amount of work we accomplished in such a short period of time. The sprint was a great reminder of what a dedicated group can accomplish with focus, timeboxing and a ready supply of coffee. (In fact, more than one sprint participant wondered why we didn’t give ourselves this much uninterrupted time everyweek.) Wyzant has conducted many of these activities before, but never on such an aggressive timeline, and the quality of the outcomes didn’t suffer.

While we feel we learned a lot and our findings were sound, the group agreed that it was challenging at times to stay aligned with the sprint questions. Tuesday’s sketching session proved particularly difficult: people saw things in the lightning demos that they wanted to emulate, but after creating their solution sketches, they realized that they’d gone a bit off target. We think this difficulty could influence the way we craft our sprint questions in the future, perhaps by reducing the number of questions or by wording them in a way that makes them easier to remember.

A little fine-tuning

While we tried to stick to the standard sprint schedule, we ended up making a few small adjustments:

We discussed the format for “How Might We” notes at the end of the morning on Monday, so that we’d be ready to go when our “Ask the Expert” sessions started at 2pm.
We explained lightning demos at the end of the day on Monday, giving people a little extra time for good ideas to bubble up.
Our interviewer had to dedicate time on Thursday to set up hardware for our tests the next day. The first interview was at 9am Friday, so we needed to get our A/V troubleshooting out of the way early.
Prototyping went past 5pm on Thursday. The biggest reason for this was probably that we had to create separate prototypes for each one of our test participants, based on the subject they needed help with.
Wrap-up went late on Friday as well. Our final user interview ended at 4:30pm, and the final synthesis and review took no small amount of effort from our fatigued team.

What’s next?

The design sprint provided us with a scaffolding for our product road map, and even gave us some early stories to put into development. As I’m writing this blog post, our product director is kicking off the new term with one of our dev teams, sharing what we learned in our sprint. We also talked about the sprint process in a company-wide presentation the week following the sprint.

Will we sprint again?

We end our first sprint with so much enthusiasm that I’m sure we’ll jump into round two before too long. What’s uncertain is whether we’ll follow the same schedule or try a shorter, three-day format. Now that we’ve tested the full process, people are curious about how much we can learn on an even tighter timeline that’s easier to fit into a regular cadence.

Even if we don’t sprint again, many team members have expressed interest in incorporating individual activities into our routines. For example, our team loved the lightning demo session and we think it was valuable for generating good ideas about how to improve our own product, so it’s easy to see us bringing that activity back.

Got questions about anything in this post? Feel free to send me an email at [email protected] and I’ll try to shed some light on the process from our perspective.