Lessons from testing 4-day Design Sprints in Brazil

Is it possible to shorten Design Sprints without compromising quality?

After hearing that AJ&Smart and Jake Knapp were experimenting with a 20% faster Design Sprint, we wondered how we could test it in the reality of Brazilian corporations. In the book, deciders seem to be really straightforward, but this is not often the case here. We've seen many deciders that are actually mid-level managers, who don't have such a comprehensive view of the company for being capable to make assertive decisions.

According to AJ&Smart, Design Sprints 2.0 are very quiet: they even put some music on, so people don't get annoyed by the silence! It seems pretty different from Brazilian companies' culture. Many are not yet used to this type of meeting and constantly deviate from the subject. This is what I've learned by adapting it to our context:

Day 1: Understanding & Sketch

— Ask the experts

Deciders and stakeholders always want to speak early in the first day, because they often can’t participate in the entire Design Sprint. So it made a lot of sense to put this step first and let them talk about their problems and expectations about what the goal should be. This also makes easier for the team to decide the challenge more clearly later. When we did Ask the Experts only in the afternoon, we've experienced teams completely change the challenge afterwards, spending more time for another long discussion.

— Long-Term Goal

Instead of trying to write the perfect goal together, people write on post-its the different challenge phrases that come to their mind. Then, they are voted without everlasting philosophical discussions. As we’ve heard the experts before, the challenge shapes more naturally.

— Sprint Questions

Instead of asking the team their questions and starting a heated discussion, everyone quietly writes down their questions in post-its. After voting, we get only 3 fundamental questions.

— Map

This doesn't change much from the book. What we've learned so far is that when people are not familiar with the Design Sprint process, they question the importance of this step, or why we don't map the whole company's process. But at the end of the day, they understand that the Map is just for us to place our focus at a point in the journey.

— Lightning Demos

No matter how much we ask, a few people bring inspiration on the next day. So, on the first day after lunch, we set aside half an hour for people to search for inspirations and write on post-its keywords explaning why they are presenting this. Then, each person presents what they've searched in just 5 minutes. As we have done more than 50 Design Sprints, we have already saved many benchmarks and we cherry-pick them according to the Sprint subject. We get some spare time to search new ones to complement.

— Sketch

Writing notes while drawing saves time. For people who aren't comfortable with pencils, we bring a lot of visual examples of what the drawing is like, so it looks less like a daunting task. In the Crazy 8s part, we explain about SCAMPER (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse) so people will not have creative blocks. It's important to reinforce that the more they care about copywriting, the less we will suffer the next day doing the Storyboard.

Day 2: Decision

— Art Museum & Vote

In the Straw Poll, we tell people to write down on post-its their final vote and the reason they've chosen it, before sticking the dots on the idea. Thus, we avoid the herd effect of people changing their vote when they see other votes.

— Storyboard

To make it less exhausting, we start by asking people to write an ideal test flow in 6 post-it. Then, the decider votes on the best flow and can add a post-it or two from other flows to complement it. That gives us a macro view of the prototype and eliminates a lot of discussion and misunderstandings.
When we start drawing the Storyboard, what has worked well is to split the team: each team has a couple of screens to draw or has different tasks to accomplish. The more detailed the Storyboard, the less people will suffer the next day doing the prototype.

Day 3: Prototype

Before we begin, we make a clear list of all the screens that needs to be done. This helps them not to forget any secondary screen that was forgotten in the Storyboard. Using the Design Systems that we have at Taqtile, we already have in the Sketch many components ready and symbolized, we just add the client’s identity colors in order to customize them. This speeds up our process. In addition, with the new Invision DSM, more than one person works on the Sketch with the same components. We don't use Figma because for our long-term projects, Sketch is still more mature.

A good practice here is to have one person putting together all the screens and fixing any possible mismatches. It's important to test the prototype early on using the real device that will be used the next day. It avoids drawing with the wrong screen size.

We also have small meetings during the day to get to know how much each task is progressing.

Day 4: Usability Test

The test also has no secrets. What we have learned is that looking for back-up people is essential, because it's common for people in São Paulo to cancel the tests some minutes before scheduled. Recruitment remains one of the most painful parts of Sprint Design for a lot of companies.

Final Presentation

The companies' tradition is to always have a final results presentation, even this going a bit against Lean methodologies … It’s still difficult to give up on it. So we leverage this opportunity to discuss the next steps of the project with them.

Conclusion

The order and timing of the dynamics really makes sense and the quality is not lost. If the team is already used to the dynamics, it is easy to conduct a Design Sprint in 4 days. When they've never done it, the challenge is to change people’s mindsets about meetings and moderate discussions. However, by placing Ask the Expert first, it makes easier for the team to decide the challenge. As Design Sprint 2.0 are more efficient, it becomes easier to do several of them one after another, to iterate on the previous solution. This has given us much more concrete results for developing the MVP more easily.

Feedbacks are welcome! Leave a comment if you've tested Design Sprint 2.0 in your company.