What I’m up to: A Design Sprint Experiment
Doing what ministries do best — squeezing a full day’s worth of work into 2 hours
InterVarsity’s Strategy & Innovation department is still relatively new and working out its processes. As a department, they have been reading through various innovation frameworks and models and had a brand new product they wanted to try one out with and asked me to facilitate.
Enter Google Venture’s book Sprint — How to Solve Big Problems and Test New Ideas in Just Five Days. The practical nature of the book led us to try this framework out first.
Essentially the framework is:
- Monday — Set a problem, map out the rough steps to solve the problem, interview subject matter experts, run a “How Might We…” exercise to start ideating
- Tuesday — Sketch out ideas and storyboard the features you want to test
- Wednesday — Choose your strongest solutions
- Thursday — Build your solutions in a Prototype
- Friday — Test with real members of your audience
Our goals were: try out a framework, exercise our design chops, and get something out.
Before the Sprint
It’s a bold claim — big problems and answers in 5 days? But, this project was well bounded, it didn’t interact or interfere with other products/services, so it seemed like a good candidate to test out the framework and answer these questions:
- The problem question: Was it really possible to solve a big problem in 5 days?
- The time question: How can I get 5 continuous days? Is it really the only way?
- The virtual question: Strategy & Innovation is a remote team. The authors didn’t have any optimism for running it remotely. Was it truly a waste of time to try it virtually?
Looking at schedules, there wasn’t a way to get 5 days in person, much less have them be 5 continuous days. We thought about running semi-remote sprints, half the team in one location, half in another, and dozens of other option that just weren’t feasible unless we wanted to wait until Spring 2019.
I’ve been impressing upon this team that we don’t have to follow formulas — especially if they aren’t going to work for us.
All we could find was 4 days of 2–3 hour blocks. So…that’s what we did!
I’ll remind you what Monday looks like: Set a problem, map out the rough steps to solve the problem, interview subject matter experts, run a “How Might We…” exercise to start ideating.
We set a pretty grueling schedule — all of the Monday activities + we decided to try voting on our ideas sooner in the process. We had a previously scheduled conversation with a subject matter expert the following day, so we pushed it to our “Tuesday”.
If you’ve read the book, have run a Sprint yourself, or are one of the book authors, I’m sure you’re raising an eyebrow at this — because shoving a full 6 hours of Monday activities + a 1 hour Wednesday activity into 2 hours does sound overly ambitious.
Time Conclusion: It is ambitious, but I think it’s better than nothing. At the end of the two hours, I felt both exhilarated, and exhausted. We definitely did some really good work– we’ve had that confirmed in our subject matter expert conversations, but having a full day would have been nice.
Did I mention we did this remotely? We used RealtimeBoard to ideate in and sat together on a Zoom call.
Virtual conclusion: Yeah — you can do it! The book came out in 2016, and RealtimeBoard has been around since 2011, so I’m unsure of why the authors hadn’t tried to use one of the many virtual whiteboard apps. At this point, they really are good enough.
“Tuesday & Wednesday”
Since we had already voted on the ideas we felt were strongest to move forward with, we had a conversation with one of our lead developers to throw away any high effort and low value solutions before we sketched them out.
Following that conversation, we spent about 3 hours working through ideas — some sketched on paper, some in Adobe XD. We presented them to each other, did a little bit of critique, and all were sent to me to place into one prototype that we could actually test.
When I first read the book, I had a misgiving that the framework would be able to solve a big problem in five days. The examples throughout the book were solving problems, yes, but they were fairly narrow — they tended to center around one feature.
Our testers weren’t scheduled for a few more days, so with all the ideas sent in, I ended up prototyping about 6 new features that we felt were core to the product in around 3 days.
We had 4 user tests scheduled to work through the prototype. This was the first time my team had tested a prototype.
Overwhelmingly, reactions were very positive. We received a lot of guidance in ways that we needed to move forward and had many assumptions challenged.
“I would submit resources to receive feedback, but I wouldn’t want to be responsible for them after that– I just don’t have time for that. My main role is not ‘resource maker’. I just make them because I have to.
“If this went live today, even as it is now, I would use it daily.”
Big Problem Conclusion: When doing a Sprint for a brand new product — you don’t necessarily know what your stickiest problem is. If I could go back and do it again, I would proceed as instructed, prototype a veneer of the core of the product like we did, and discover what the stickiest problem is in ~2 user tests. Then, I would essentially repeat the Sprint for just that sticky problem.
I would totally do this again . With our changes to the methodology along the way, I feel validated that it’s a good thing to change course and make something up that fits what you need better.
I would love to try it out following the authors’ instructions to the T, but until we gain more project and design literacy, doing what we can until then is still reaping rewards.