Introduction
After running a handful of Design Sprints, I started noticing interesting patterns in terms of how it modifies for good the collaboration between a team building a Digital Product.
I hope that this article helps you to decide and try this process, or any similar approach to Digital Product Design, if you haven’t done so.
If you are not familiar with what a Design Sprint is, I provide an introduction in part one of this series of articles. Get to know that the post you are reading right now is part two from a series of three posts:
- First part covers general lessons learned from the Design Sprint, and why is this relevant for Developers, Designers and other disciplines involved in Digital Product and Software Development
- Part two is about stuff going ‘under the hood’ not covered in the Design Sprint book (this post)
- Part three provides a look at how to implement the Design Sprint in a more complete and integrated workflow of design and development
That said, let’s take a look at each day of the Sprint, and discover what’s happening under the hood.
Monday: knowledge transfer in record time
During Monday, the team gets to know each other, and establish challenges for the rest of the week. This initial dialogue creates an alignment of goals across the whole team, provided by the act of discussing business goals within the context of the company’s vision for the next years. Needless to say, for this to work everyone on the team –with the facilitator at the lead– must become machines of asking the right questions, and going through several layers of ‘WHY?s’.
With all this information, the facilitator and designers are able to build a map showing how the goals are going to be achieved through several interactions. This map lays out a ‘bigger picture’ of the product or service in front of the client, and usually it is the first time that the clients are able to see their product or service as a whole.
The map not only provides this sense of looking at the big picture, but also helps transmitting a ‘lean’ and ‘agile’ mindset when ‘choosing a target’ (basically, selecting a specific region of the map to work for the rest of the week).
All of these conditions allow the team to be sure that they are tackling the right aspects of the problem, before jumping into solutions.
Tuesday: everyone becomes an interaction designer
During Tuesday morning everyone shares ‘lightning demos’: basically products that excel at what the team is trying to build. This is a very casual, but very powerful tool of trend watching –in terms of good user experience design, and user interface design.
While designers have a chance to share great UXD practices with the rest of the team (from real examples on the wild), clients have a chance of showcasing industry specific success cases (most of the time vert technical and with poor UXD, but great approaches to user needs).
The most exciting thing about Tuesdays is sketching: everyone takes pen and paper and gets to work, sketching ideas for the solutions. This is part of the co-design process that I really love about dynamics like the Design Sprint.
When looking at prototypes created during Design Sprints, people might think that designers are crazy for doing so much work in a single day. Truth is, the prototype is created collaboratively by everyone, starting on Tuesday with all those sketches. That’s why I think that on Tuesday, everyone in the team becomes an interaction designer.
Not to mention that ideas and sketches from non-designers usually impacts equally –or even more!– the final solution.
Wednesday: meaningful discussions about the product
During Wednesday, the team discusses the sketches in a very organized way; using individual analysis, voting, commenting, and gradually eliminating noise from the picture (putting away less relevant sketches).
This sort of team discussion becomes really intense, but it feels relevant and enjoyable. That’s because everyone is focused on how the product delivers value, in the context of interaction, flow, messaging, and the general feeling of using the product. The later implies a very different dynamic from the oldschool approach:
- Gather design and development requirements
- Withdraw to the office, prepare a proposal in isolation
- Go back to client, show proposal
- Get involved in low-value, time consuming discussions about placement of objects in the design; choose of color; imagery, and so on (still important elements, but those are just the surface of the product)
During this process of organized discussion, bad ideas are clearly labeled as bad ideas (or maybe just as ‘not-so-good’, or ‘maybe-laters’, but still). This helps to better manage expectations from everyone involved, and allows those whose ideas are discarded have a clear understanding of the context in which those ideas were discarded.
Finally, and probably most obvious of all, creating a detailed storyboard (most part of the afternoon is dedicated to that endeavor) provides a crystal clear scope of work for the designer on Thursday.
Not only the storyboard makes the designer’s life easier, but it also represents a fully approved vision of the product, by the decision maker and the whole team.
Thursday: show off time for the designer
With all the eyes now on the designer –responsible of generating a high-fidelity mockup in just one day– it is a great chance for the clients to witness the ‘magic’ happening in front of their eyes.
The Designer has a special spot here to develop a strong sense of empathy from the rest of the team, and this helps get design-related discussions move more easily and fluidly.
Plus, the prototyping process implies a unique moment of Nirvana for the designer; after three days of generating mental maps, sketches and storyboards, moving to generate mockups becomes a super productive experience. As I mention in my previous post, a well defined problem and a ticking clock are the best friends of productive creativity –and the Design Sprint provides the designer with both.
Friday: validation through interaction
After all the hard work the last 4 days, a high-fidelity prototype is finally ready. Now it’s time to test it with potential end users.
No strategy survives the first contact with the enemy; and no design survives the first contact with the user…
Getting feedback from real users is one of the most rewarding and challenging moments for a Product Designer (or a Product Design Team).
For the client, this is a unique opportunity to observe (often, for the first time) how real, potential users react to her/his business idea. This sets the client into a mindset of listening the customer, and becomes really helpful for the rest of the development process (particularly on large projects where ongoing iterations are needed).
The client and her team also obtains a chance to learn how to better interview users, and make sense of their feedback and reactions. In most cases, the interviews run on Friday reveal unexplored forms of customer research for the client’s team, as well as clues on how to integrate experiments and validation into their current Design Process.
In general, you can see how –by the end of the week– the discussion among the team has moved away from potentially less relevant topics (‘colors, images and text placement on the interface’, to quote a very obvious one) and gravitated towards a really interesting conversation about how the product delivers value and impacts the life of the users and the business.
Practical cases, and some caveats
The Design Sprint is a useful recipe to use right away as a Design Process, but it is unlikely to do wonders by itself. As any other Design Process, a Design Sprint must have support from other processes and actors inside the organization; before and after its implementation.
Putting too much faith on the Design Sprint process alone can be catastrophic without the right team and the right pre-sprint and post-sprint strategies to support it.
I’ll publish a third part to this series of posts, pointing out how do we use the Design Sprint at Icalia Labs, along with real examples and practical advice for other firms that might want to try it.
In the meantime, do you use the Design Sprint in your company or startup? Does the content in this article was relatable to you? Let me know your comments below!
Stay tuned for part three, and read part one here if you haven’t done so ✌️
Also, huge thanks to Eduardo Lopez De Leon and Carlos I. Garcia for their help, proofreading and improving this post 🙏
