--- title: Modifications we’ve made to the Design Sprint teaser: 'Design Sprints, by their very nature, are flexible. They follow an overall arc that drives towards testing ideas with potential users, but are not constrained to a single dogmatic way to go about that. ' tags: design sprints,design author: Eric Bailey published_on: 2021-05-25 --- thoughtbot is bullish on [Design Sprints][design-sprints]. They are incredibly effective at quickly and cheaply creating internal consensus, de-risking ideas, and determining product/market fit. Design Sprints, by their very nature, are flexible. They follow an overall arc that drives towards testing ideas with potential users, but are not constrained to a single dogmatic way to go about that. Each day of a Design Sprint has an overall end goal, and there are [a variety of exercises][exercise] a facilitator can use to go about meeting it. The exercise selection is flexible. A facilitator choses them based on the problem trying to be solved, the group size and dynamics, and the overall environment the Design Sprint is being conducted in. The same way the day’s exercises are flexible, we’ve found that the parameters of the Design Sprint itself are malleable. This is in keeping with the Design Sprint’s spirit of experimentation and iteration. Following are some tweaks and modifications we’ve made to conducting successful Design Sprints: ## Have a break between prototyping and testing While exhilarating, Design Sprints can also be exhausting for all involved. They require a ton of active listening, critical thinking, and a decent amount of context shifting. By the end of the week, people are tired. This goes doubly for facilitators. This goes triply so for [remote Design Sprints][zoom-chats]. To address this, we’ve found that inserting a weekend in between prototyping and testing days has great value. A weekend allows everyone involved to get some rest, refresh themselves, and approach usability testing with revitalized energy. Energy level is one of those subtle things participants subconsciously pick up on, so it’s important to come correct. The weekend also provides little extra buffer time to check your prototype to ensure all the interactions work as intended and there’s no accidental hard stops that would confuse the test participant. There’s a little bit of a push/pull here, as well. If we’re making modifications to the prototype during the weekend, it’s voluntary, and not expected. We also make up for this incursion into our personal time by adjusting our hours the following week. This is in keeping with [our values][values]. It is also worth acknowledging that a Design Sprint is effectively a 40 hour-long meeting. It is easy to talk at a high level about how they’re important and *of course* everyone should make the time to participate. In practice, it can be difficult for clients to dedicate five consecutive days, plus stay on top of existing work obligations. ## Reserve time to talk to the experts Some Design Sprints are more blue sky, in that they’re trying to identify if an idea has big-picture merit. Other Design Sprints can be dialing in on refining or replacing existing ideas. These sorts of engagements usually require more time to understand the problem space. Design Team Lead [Vendela Larsson][vendela] mentions the importance of identifying Design Sprints where there are existing, complicated technical considerations. An example of this could be unique environmental constraints, something that is commonplace in a lot of Internet of Things projects. If these circumstances are known going into the sprint, you can add additional time to have breakout conversations for things like: - Discussing technical nuance and domain jargon, - Getting access to the proper resources, and - Do dry runs of working with existing technical implementations. These sorts of concerns may not always be uncovered in [the Understand phase][understand], but can have a dramatic and potentially detrimental impact down the line. ## Meet up beforehand Remote Design Sprints are different beasts. Since we can’t all gather in one physical room and physically move sticky notes around, we need to swap in digital replacements. With this digitization of the process comes the reminder that there are varying levels of technological literacy. There is also some nuance here: Tools such as [Miro][miro] can be confusing even to people who spend a lot of time using a computer, but not necessarily using apps that are more open and freeform. Sometimes it is beneficial to for you to meet with sprint participants beforehand to learn how to use the remote tools you’ll be using for the sprint itself. It can be as a group, or one-on-one. Whatever helps participants feel more comfortable and therefore less self-conscious about participating. For one Design Sprint, we led participants through a small series of exercises designed to help acclimate them to the basics of interacting with Miro. This helped to build trust and rapport, as well as ensure the actual Design Sprint went smoother. ![A board in Miro containing a collection of sticky notes. The prompt is asking to list your favorite musical genre. Answers include, 'Techno', 'Jam Bands and Yacht Rock', 'Classic Rock', '70-80s Rock', 'Indie Pop', and 'Anything but country.'](https://images.thoughtbot.com/blog-vellum-image-uploads/XZEu3vTEQz680KW5KPP1_sticky-notes.png) ## Start the day with some music Waiting for people to trickle into the Zoom meeting at the start of the day? Play some music! [Our COO Chad Pytel][chad] tried this during a recent Design Sprint to great effect. Music kicks the day off with a fun, casual vibe, and gets rid of that dreaded awkward silence everyone endures while waiting for instruction. [Here’s a playlist][playlist] designer [Elaina Natario][elaina] uses to help set the mood. Some light background music can also be nice for later exercises such as [Speedy Eights][speedy-eights] and [Storyboarding][storyboarding]. Keeping the same playlist helps with a feeling of continuation and helps people relax. ## Blend onboarding exercises In addition to conducting pre-work, Designer [Alex Chen][alex] has had good luck blending ice breaker activities into the virtual white-boarding tool you’re using. This saves time by co-mingling education with introductions. Examples of this could be creating a sticky note listing your favorite musical genre, or pasting an image of your favorite animal. These little exercises do double-duty for starting to get everyone on the same page. Just remember to ensure the ice breaker questions you use are inclusive! ## Democratize UI creation In the abstract, the Design Sprint guide advises using whatever tools you have on-hand to create a prototype. If it’s a just sketch on paper? That’s fine so long as it gets the ideas you want to test across. In reality? We oftentimes found that we’d also want to concurrently test things like branding, necessitating a higher-fidelity prototype. We also need to factor in quarantine, where the entire process is virtual, including the tools we use. There’s no longer sketches on paper, unless you can convince people to photograph and upload their work. To address this, we’ve had good success taking a UI toolkit and creating a set of UI “building blocks” for participants to use. If you’re using Miro, I quite enjoy cherry picking from their Wireframe library to create a suite of common UI controls:
A board in Miro with the prompt, 'Let’s build some UI!' Below the prompt is a collection of UI widgets including text inputs, a calendar, headings, and radio and checkboxes. Below that is a simple prototyped implementation that features email adderess and message inputs, time and date scheduling controls, and a send button.
Design Sprint participants collaborated in Miro to build a scheduled email sending tool.
Having people participating in creating UI at a higher level of fidelity does two wonderful things. It: 1. Decreases the amount of work a facilitator needs to do to create the prototype, and more importantly, 2. Increases the Design Sprint participant’s sense of ownership over the prototype and process. The Storyboard helps a whole lot with this activity, in that it outlines overall goals the prototype should accomplish, which provides direction for what UI should go where. One of my favorite moments with this process is when participants hit their first UI roadblock and go from a paint-by-numbers mindset to one that can actively question if it’s a good user experience. ## Stay loose, stay flexible Acknowledging the realities of real life and meeting people where they are helps everyone participating in the Design Sprint process. Being able to adjust its parameters to accomplish this leads to more comfortable, satisfied clients, less ambiguity, and overall better results. [design-sprints]: https://thoughtbot.com/services/product-design-sprint [exercise]: https://thoughtbot.com/playbook/validation/design-thinking-exercises [zoom-chats]: https://www.bbc.com/worklife/article/20200421-why-zoom-video-chats-are-so-exhausting [values]: https://thoughtbot.com/playbook/our-company/purpose-mission-values [vendela]: https://www.linkedin.com/in/vendelalarsson/ [understand]: https://thoughtbot.com/playbook/validation/product-design-sprint/understand [miro]: https://miro.com/ [playlist]: https://open.spotify.com/playlist/0dyFviEAtYNtVGfnw5Kt0M?si=a146e5258f2849d3 [chad]: https://www.linkedin.com/in/cpytel/ [elaina]: https://www.linkedin.com/in/elainanatario/ [speedy-eights]: https://thoughtbot.com/playbook/validation/design-thinking-exercises/speedy-eights [storyboarding]: https://thoughtbot.com/playbook/validation/design-thinking-exercises/storyboards [alex]: https://www.linkedin.com/in/achen178/