What I want to show is how a resource-constrained startup was able to use a Design Sprint as an invaluable tool to get a lot of shit done in a short amount of time, in a vertical we lacked expertise: design.
At Tutum, we recently ran a week long design sprint to completely re-design our entire web application’s interface. We’re still a fairly small startup, which means many of us are wearing multiple hats. So as a caveat, as you read this post, I am not a designer.
However, I grew up with a graphic designer as a mother and I’ve read a handful of design books (for whatever this is worth): Design for Hackers, A Project Guide to UX Design, Smashing UX Design, and UX for Lean Startups. I’ve also taken over many of the functions a UX Designer would be doing as part of my role in Growth until we can make that hire. So while I’m definitely not a designer, I’d proudly take the title of wanna-be designer.
The primary goal for this design sprint was to crunch down months of disconnected and half-baked discussions around the re-design into a single intensive week. There’s also something magical about creating momentum around a process. Kind of like what you might see at a 24-hour Hackathon, we wanted to use this week to bulldoze through months of work. There’s no way we could’ve done this in 5 days spread out over a few weeks.
I suspect that there are many tech-focused startups that don’t have a dedicated designer, or may have someone who wears the designer hat every once in a while; this is for you. At the time we ran this design sprint, we had our first design hire only a few weeks before.
We started to notice that our application interface was getting more and more complex and the general structure of the interface wasn’t conducive to adding all of the new features we were firing off weekly. After a while, we just kind of ran out of “logical” areas to place features, and we started to get the sense that a complete overhaul was needed.
How is this different than a Google Ventures Design Sprint?
It just so happened that I recently came across Google Ventures posts on how to run a Design Sprint, which are excellent and served as my bible. To be clear, the process and everything I talk about will be based on their Design Sprint. I’ve read and re-read all of the design sprint and research sprint, and just about every presentation and video on design sprints they’ve ever put out. I highly recommend checking out that material.
The only issue I saw with Google Ventures is that even though it was built with small teams and startups in mind, it was created to tackle very singular problems. They would focus the design sprint on a single “User Story” and if it were “complex,” meaning more than three steps, it might be broken down into two parts.
This might be reasonable, but we wanted to design for 15 user stories, each of them containing 10+ steps.
To say this was ambitious is quite an understatement. However, we knew if we didn’t get this done during this week, in reality it would probably be slowly pushed back and completed over the next few months.
You Must Get Organization-Wide Buy In
It’s very important to make sure that everyone understands why the design sprint is happening and people should be eager to participate. At this time, it would also be wise to think about what will happen after the design sprint is over. It’s easy to become short-sighted and see the design sprint as the goal in and of itself, but this is just a stepping stone to the greater objectives.
For us, this meant knowing we would come out of this sprint with rough wireframes of all of the different screens of our interface, which is roughly 30. We also knew we wanted to design for future features and have our design be more “modular” to accommodate anything we’d reasonably throw at it.
Another crucial step is getting all the right people to attend the design sprint. This means the people that would best influence the problem at hand, the design challenges, the people who would be implementing it, anyone who might be customer-facing, and ultimately the primary decision makers. Luckily for us, since we all perform so many functions, we were able to have all of these people present at our sprint. In particular we had the CEO and CTO attend, myself (growth), our front-end designer, and our graphic designer.
Another big reason for having a dedicated sprint was to capitalize on all of us being in the same room. Since we’re an international company with an office in Brooklyn, NY and an office in Madrid, Spain it’s not always easy to closely collaborate. Now that I knew the right people would be showing up, I had to gather the right supplies.
Must be a Problem Worth Solving
This sounds fairly obvious, but if the problem isn’t big enough then it’s going to be hard to get the organization-wide buy-in and people to take it seriously. If you’re calling the team together for week-long sprints every time you want to change a sentence in an email or choosing a new color for your sign-up button, these will obviously piss people off.
Be mindful of other people’s schedules and priorities. Your problem has to be big enough for everyone to make it their number one priority for an entire week.
Google Ventures recommends the moderator doesn’t participate in the sprint, but we felt we just had way too much work and too few people already.
I had two weeks to prepare the sprint’s setup, supplies, and itinerary; I was also preparing to be the moderator to make sure things would run smoothly and that we weren’t going to be wasting our time.
To ensure things went smoothly I planned out as much of the sprint as I possibly could beforehand. Just so I wouldn’t feel too stressed out jumping back and forth as a moderator and participant, I scripted out all of the activities for each day, had examples ready for any exercise we were going to do, and even wrote down what I would say verbatim for any part of the process I wasn’t 100% comfortable with.
I saw a ton of value in running a design sprint and didn’t want to be the “that guy” who ran a horrible sprint and ruined it for everyone. A bad turnout would ensure we never run one again.
Plan for Interruptions
It was clear for us that our CEO and CTO would ultimately have the final say in decisions. We also knew that they would be in and out with meetings we couldn’t afford to miss.
My best advice is to have activities planned where no decisions will be made while the key decision makers aren’t present. We accomplished this with mini-sprints, which I’ll talk about in the next section.
As much as we would like to lock ourselves away to work in solitude, we still had a company to run. Having 5 of the 10 people involved in a sprint makes it impossible to truly dedicate 100% of an entire week to the sprint.
We had set breaks where we would all work on “normal” work activities. Making sure people know that there are set durations of time they will have to catch up on work will help keep their focus in the design sprint and not worrying about the impending mountain of work they’ll have to do.
Running Multiple Mini-Sprints
The standard Google Ventures design sprint is separated into five days with a theme dedicated to each day: understand, diverge, decide, prototype, validate.
We had to run multiple quick cycles of the first three steps: understand, diverge, and decide. Since we had so many user stories to design for, we had to split up our efforts and tackle multiple stories at the same time. We usually assigned people who had the most knowledge of a user story to design for it.
In this way we were able to knock out several user stories at a time, and then cycle back through tackling new user stories. This saved us from getting fatigued and bored doing the exact same exercise for 15 different user stories, as well as let us small chunk our progress. Taking constant small bites out of the problem lets you easily see progress.
This also had the added benefit of making us better at running through the design sprint cycle. If you find yourself having to tackle a ton of problems at the same time, I might suggest starting off with easier user stories to gain some momentum and some easy wins. Then you can tackle your most challenging problems. Once everyone is fairly tired, lining up an easier problem makes sure everyone has enough mental juice to get through it.
We went with a lot of the supplies as suggested by Google Ventures, but here’s a list of everything we bought (keep in mind we bought way more than we needed to accommodate future sprints and design-related problem solving.
- Basic Dry-Erase Board 70 x 47 inches, melamine surface
- 15 Piece Original Dry Erase Marker Kit
- 4 Black Dry Erase Markers
- Color Coding Round Labels, 7,128 count
- 3 x 5 Inch Yellow Sticky Notes, 100 count, 12-pack
- Set of 10 Colored Pens
- Tac Removable Adhesive Putty Tabs
- 8.5 x 11 Inch Paper 1,500 Sheets
- Healthy office snacks
Total Cost: $250.69
Keep in mind that the greatest cost of a sprint is the personnel resources being tied up. Taking half of the employees of a startup, let alone the two co-founders is a big deal. This relates back to making sure you have a big enough problem worth solving.
Start with a Sprint, end up with a War Room
As far as expenses are concerned, it’s paid for itself many times over. We now use these supplies to have an instant war room at our disposal. We just shift a few desks, move a few chairs, and we have our own private space to tackle difficult problems. We also use the whiteboard on its own whenever we’re faced with a problem that requires putting multiple heads together; it’s definitely been a great investment.
Now that you’ve properly planned and prepared for your Design Sprint, things should run nice and smooth. In future posts, I’ll be covering the rest of the phases: understand, diverge, decide, prototype, and validate.