A Sprint Story Chapter Two: Solution Sketching & The Case Of The Missing Context

by Brad Soroka. First appeared on Digital Telepathy Blog.

Now that we’ve laid the groundwork, it’s time to dive in and start brainstorming ways to solve the problems identified during Day One. Today’s activities involve sketching out lots of ideas to identify the best course of action. Before the fun begins, each team member shares examples of inspiration to help get the everyone in right mindset. When everyone is ready, each team member will sketch out low-fidelity solutions that solve the core problem. After sketching, we regroup with the team to begin the process of recruiting people for Friday’s prototype testing.

The Plot

9:30am

We began the day by breaking some more rules! People weren’t prepared to share inspiration and neither was I. So before jumping right into Lightning Demos, we gave the team some time to think. The first half hour of the morning was designated to silently and individually collecting examples. We created a Google Doc and had each team member paste in screens and/or URLs of the work they wanted to share.

10:00am

Lightning Demos! A huge variety of digital products were on display. We looked at products focused on habit building, fitness, wellness, nutrition, meditation, community building, productivity, project management, and more. While my partner John drove through the screens, Roche designer Anurag and I captured the essence of each example through sketching.

10:34am

It was around this time that things started to go off track. Perhaps the exercise wasn’t communicated well enough. Or perhaps people were biased on tools they liked. But we noticed that some of the inspiration being shown wasn’t connected to solving the problem we decided upon. It was then that Marco, the main stakeholder from Roche, introduced a method he called Keystorming.

Keystorming is a system of discussing analogous inspiration and its relevance to the problem being solved. This technique helped the team reframe the work being shown by answering the following questions:

• What are the top three keys in this example that unlock the desired human behavior we are looking to unlock in our scenario?
• How can we apply these keys to our solution?

The result of the exercise was fascinating. All of the work now had relevance, as it helped everyone see the potential use of each example. Through this approach, the possibilities were abundant and we were ready to ideate.

1:30pm

Sketching in Four Steps. The typical four step process outlined in the GV Sprint Book is as follows:

1. Notes. Twenty minutes. Synthesize. Silently walk around the room and gather notes.
2. Ideas. Twenty minutes. Brain dump. Privately jot down some rough ideas. Circle the most promising ones.
3. Crazy 8s. Eight minutes. Fold a sheet of paper to create eight frames. Sketch a variation of one of your best ideas in each frame. Spend one minute per sketch.
4. Solution sketch. Thirty to ninety minutes. Create a three panel storyboard by sketching in three sticky notes on a sheet of paper. Make it self-explanatory. Keep it anonymous. Ugly is okay. Words matter. Give it a catchy title.

The new team members came across some issues with this process. I don’t think it was the process itself, but maybe the way we explained it. Or perhaps it was difficult for some because this type of rapid ideation is not what they are used to. You see, a Design Sprint is nothing more than a bunch of UX best practices wrapped into one week, but if you aren’t versed in UX or design this stuff can be tricky. So we showed them examples of how we would tackle it. They asked for more. We showed them more. Moving forward, we learned that the best way to communicate these exercises up front is with examples. So if you are leading a Design Sprint with n00bs, bring a lot of visual references!

With a little coaching and some electronic music to get us in the zone, at day’s end our solution sketches were complete. A nice and tidy assortment of ideas to review and vote on the following day.

4:30pm

This is typically when we would start the recruiting process for testing. But a big sloppy happy curveball came our way. The Roche team asked that we consider doing unmoderated remote testing. This was something they were not very familiar with and wanted to get better at. We were all set for in-person interviews, but we were open to pivoting. After all, one of the goals of the week was to train them. So we discussed the pros and cons of going remote and determined that while we might loose some conversational qualitative feedback, we could still write a test plan that pulled thoughts out of the users’ minds. This plan seemed sound, but it became suuuuuuper tricky during prototyping day.

How could we write a test plan for a prototype that wasn’t yet built? Would we have enough time to get quality tests to synthesize on Friday? But wait, what about Wednesday? Do we have enough ideas to build something? Find out next on A Sprint Story.

Originally published at www.dtelepathy.com on May 17, 2017.