For most of my career, I’ve believed that design sprints were a bullshit way of looking like you’re being productive. 🤷♂️ I think I thought of them like this because everything I read about them online, or saw on YouTube, was masturbatory Silicon Valley jargon. 🌉 That said, I was still fascinated by the idea of them, mostly because I knew respectable people at Google who popularized the method, so I was curious what, if anything, they could offer to my team.
Finally I was in a situation at work where we were stalling on conceptualizing and designing a new feature. As often happens, there was a lot of talking around the new feature, but there wasn’t a lot of common understanding of what it was, or how it would work with the rest of our product. To me, this felt like a good opportunity to try out my very first design sprint. After a lot of research and soul-crushing YouTube videos 😩 I came up with a slimmed down version of the common design sprint format.
Just so we’re clear, what I came up with is totally based on the common knowledge of design sprint methods. It lasts a week, the days are pretty much used in the same way. I just focused on making it more accessible and less confusing to explain to my product team. I found most How To Do A Design Sprint Medium Posts too complicated and hard to really put into practice.
Anyway, I hope this feels more understandable and like something you could imagine using for your team one day.
MONDAYArguing Day
The main point of today is to slow down, get together in a room, gather everyone’s knowledge, create a map of what you know, argue about what you should do 👹, plan out your goals for the week, and agree on what you want to have done by Friday. Some professional design sprinters 🤮 might hate me for this one, but in my experience the first day is a lot of impassioned discussions (arguments) that lead to a lot of ideas and that is fine.
Throughout the day, the output should only be short words on sticky notes. Use a fat marker to prevent yourself from writing paragraphs on sticky notes.
You should collect open questions, things you already know, potential solutions, and requirements. Put them on the wall in those groups. You might start hating yourself at this point as the room fills with sticky notes. Maybe you question who you are as a person, who you’ve become… but once your boss walks in and gives you that look that says, “great job, work is being done here,” you’ll be grateful for the sticky notes. 😂
During this initial discovery day, come up with questions to ask stakeholders (the CEO, your boss, the related departments). Later in the day, invite those stakeholders into the room to answer these questions. Involving stakeholders at this early stage helps avoid both personal issues (they will feel like part of the process) and practical issues (you will learn from them and design something better).
I never figured out how the hell “How Might We” statements work. It has never felt natural to me and always failed as an exercise in my experience. 👮♂️ Do not @ me!
Before the end of the day, remember to pick and agree on a target for the rest of the sprint.
TUESDAYHand Waving Day
Evaluate everything you learned yesterday and really start to focus in on potential solutions. These solutions should not be high fidelity. They should be whiteboard wireframes or quick sketches.
A common design sprint method is called “Lightning ⚡️ Demos” but instead of giving it a name, I’ll just say: collect a bunch of solutions from other companies that could influence this sprint’s challenge, sketch the main idea from each of the influences, and tape them on the wall. You can use this as inspiration when you get into designing. I often find myself referencing these throughout the week in discussions. It’s always helpful to know how other people solved similar problems.
As you continue sketching, keep all the sketches together 🗳 ready to organize and evaluate for tomorrow.
Remember to start recruiting people today for Friday's prototype test. If you have the luxury of having multiple meeting rooms, book two rooms for the whole day on Friday—one where the testing will take place, the other where your team will observe the testing in real time. When looking for testers, try to find people who are removed from the immediate team. If you can get real users in the office, that’s perfect.
WEDNESDAYNail Biting Day
Organize all the ideas from yesterday, pick the best one, and draw out the whole flow on a whiteboard, paper, an iPad, anything that allows low-fidelity sketching. Maybe yesterday you already honed in on one idea, that’s fine. The goal of today is to make a finalized and detailed (but sketched) plan for the prototype you will build tomorrow. I sometimes even start writing basic copy on these sketches if the mood strikes me. 👨🎨 They should be detailed, but still sketches.
People might start getting nervous 😬 that you haven’t opened design software yet, and I get it. Trust me, just keep working in sketches. Finalize the prototype on paper before jumping on a computer.
Remember to have a final sketched plan for the prototype before you go home for the day so you can jump right into prototyping tomorrow.
THURSDAY“Real Work” Day
Focus today 100% on making an actual working prototype. You'll also need to do a trial run and write the interview script today, so someone should start thinking about the questions you want to ask users and what 🏅 success or ☠️ failure looks like in a user test.
Remember, this is just a prototype. Don't sweat the insane details unless that’s a big part of your concept. Just make something that makes sense and works. It should be as real as possible, but doesn’t need to be perfect.
It helps to do a quick test with someone on the team—anyone is fine—to make sure you have your questions ready and the prototype is working fine.
Remind the testers that the test is tomorrow. If they don’t show up, you’re screwed! ⚰️
FRIDAYTest Day
This is where you get real insights and feedback on what you've worked on. The team will be observing the 🎥 live user testing of what you've worked on this week via a Google Hangout from one meeting room to the other (make sure to tell the users they’re being watched by a room full of people 🤷♂️). And absolutely do not forget to note and organize feedback as it comes in throughout the user tests.
This is probably the most important day to get stakeholders and other members of the team to come by and see how actual users perceive your product. Real user feedback is so important to pay attention to, and often something that people unintentionally ignore or have no insight into. It's really easy to just build a product that makes sense to your team and never talk to actual people about it, but that's a recipe for failure. So make sure to get engineers, stakeholders, managers, interns—anyone really—to drop by throughout the day. It does a lot for your standing as a design team within the company, and makes it clear that you’re actually working and not 👀 looking at Reddit all day.
Remember to pay very close attention and take notes throughout the whole testing session so that people who can't make it can still look over the results. It's important that someone in the observing room take these notes instead of the person doing the testing, so they can focus on keeping the conversation flowing and natural.
After a day of user testing you’re left with a lot of feedback on your prototype. It’s up to you to figure out what you do with that feedback. If you have a lot of time on your hands and really want to do things right, you should schedule another user test after revisions to the prototype have been made. What I typically do is sit with the team on Monday and go through the prototype leaving comments in the design file on things we learned and things we want to try to do better in the next round. In total transparency, I don’t often do another user test. 😈 I’m just crazy like that. But if you wanna be a teacher’s pet, then schedule a follow up test.
Anyway if you just scrolled to the bottom hoping for a summary, just go back to the top and read it. I swear I wrote this to make design sprints feel more accessible and less dumb. When my team tried this method, we didn’t feel like we were spewing nonsense the whole week, we got stuff done, we came out with real results, we impressed stakeholders with our ~*~ methodologies ~*~ and since we’ve implemented this process we’ve had many successful design sprints.
But don’t take my word for it, try it out yourself! 🌈📚🏃♂️ And reach out on Twitter if you found this in any way helpful. I’m @brandonhaslegs there.