Design Sprints. Wikipedia defines it as “… a time-constrained, five-phase process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market”. Typically Design Sprints incorporates all the phases of Design Thinking, namely Understanding the problem (empathizing with users and defining the problem), Exploring (prototyping and ideating) and finally Materializing (implementing and testing). This is also typically done during one week, all day activities, aiming to swiftly understand the requirements from a business perspective, who the users are (with a variety of techniques, from user journeys, empathy maps, affinity diagrams, information compiled from interviews), what the technical requirements and limitations are, what the competitive arena looks like (from a direct and indirect perspective), in order to generate ideation sessions which will, in turn, produce prototypes that can be tested to gather feedback and polish. These prototypes can be as complex or as simple as teams deem necessary (meaning paper prototypes or more complex digital ones) but should be produced fairly quickly in order to assess the feasibility, interest and response the feature or product may produce. What I just described fairly succinctly is standard, and has become the baseline by which many UX courses are shaped and then taught in many institutes. However, what this type of engagement fails to demonstrate, is the reality that these Design Sprints are typically more successful with organizations with a substantial amount of resources available. This type of initiative requires for the participants to be exclusively dedicated to it, which means that for the entirety of the engagement, all participants have to be solely focused on the activities at hand. Realistically speaking, most startups and even some organizations where Design is still incipient, have challenges in carving time from busy schedules, in order to make sure different participants and stakeholders, can attend a Design Sprint. And typically for Design Sprints to be successful, they require the attendance and participation of eclectic groups, containing professionals such as Business Analysts, Product Owners, Customer Support Group representatives, Development representatives, Senior Stakeholders, among others. The goal for this type of initiative is getting different points of view, understand the journeys the product or feature will have, and how that permeates across the solution being created. In my experience, in both Startups and also organizations with incipient Design Practices, I’ve opted to break the Design Sprint in a multitude of sessions, all of which aim to replicate the spirit of the original Design Sprint, but understanding the constraints in which each specific organization operates on. In many occasions, I’ve had the opportunity to witness, Senior Stakeholders, Product Owners, Senior Development professionals, have severe time constraints, due to demands of travel, sales-driven requests, among many others, all stemming from the fact that on Startups, for instance, professionals have a variety of responsibilities under their umbrella. Understanding these constraints have led me to rethink the Design Sprint, particularly when it addresses the timeline in which it operates. I’ve opted to move away from the typical week-long exercise, to a more dilated timeline, one that accounts for more participation, accounting for the availability of the attendees. The goal is always the same as what the Design Thinking process establishes, and which I have described above, however, sessions take place each day, for 2 hours each, as opposed to 8 hours. This allows for activities to be sensitively focused, namely from the Discovery phase, through exercises such as user mapping, product pitches, among many others, all the way to uncovering journeys, which are in turn converted into flows which demonstrate what the feature or product will actually do and the problems it will solve (and by extension, the benefits that it will produce). The onus is on the Designer(s) who has to be diligent and prepare the tasks beforehand (which includes, research, sketches, quick prototypes, among many other tasks), while also scrupulously adhere to a variety of tasks in order to capture and document all that pertains to this series of initiatives. This type of distributed Design Sprint requires a few chapters of summarization, where the team reconvenes to assess where the efforts are, but in essence, it maintains the cadence of the Design Thinking methodology. In all these types of Design Sprints, and in my experience more so than in the weekly based ones, there’s closer integration with the participants, since the breakaway time allows for the participants to ponder, research, gain further insight into a lot of the topics being discussed in the sessions.
Outcomes, Reality Check. Design Sprints have thankfully become a staple for many organizations, all of which want to subscribe to the fact that they’re Design-driven. It’s a process that produces demonstrable and measurable results, however as I mentioned earlier, how this process is applied and deployed to each organization depends on the resources and constraints that are specific to them. The Sprint cycle won’t function the same way for every organization — I’ve witnessed Design Sprints that were deployed with organizations where the attendees did not have the availability to be fully engaged, and therefore, the sessions themselves were semi-productive (the attendees were constantly paying attention to other tasks, taking phone calls, leaving the space to attend to other demands). It’s crucial that Designers understand the organization they’re operating with, and how this powerful process can be part of the mechanics of it, and not work against it.