Design Sprints are Absurd
It’s Time to Get Serious
The ‘Design Sprint’, made extremely popular by Google Ventures is a highly problematic approach to innovation. At best, it’s a glorified ‘team-building’ exercise that has made its way into thousands of massive corporations, startups, and company workshops. Due to its adoption and promotion by Google, it has spread like absolute wildfire, but even on its’ best days shouldn’t be really be taken seriously in any organization, big or small. The reasons are simple.
First, it lacks any scientific rigor. Second, it creates social tension, leading to hurt egos and learned helplessness. Lastly, it is just too hasty and rudimentary for massive, multi-million dollar decisions to be made. Moreover, design sprints are an exercise better suited for social conferences— not high stakes development decisions. Could you imagine Nasa using design sprints to develop solutions for a man-mission to Mars? It’s absurd.
The ‘Design Sprint’ has been made extremely popular by the book ‘Sprint’ by Jake Knapp, which outlines how an electoral conceptualization and omission process can help companies ‘solve anything ever’. The only problem is that sprinting never really solved any worthy problems. What it does do, is inflate ego’s while creating group friction which is inherently bad for innovation and the organization at large.
What is a Design Sprint?
The design sprint espoused by Google is a 5–10-day process of validating ideas and solving problems through research, conceptualization, and testing solutions with hypothetical end-users. Usually, sprints are exercised by teams which may include a designer, researcher, strategist, visual designer, and anyone else deemed fit to participate (managers and/or executives).
How it Works (The Google Way)
Teams of ~5 people are organized to work together in one–two week sessions where they’re tasked to solve a problem or work on a particular facet of a product (it could be the ‘account’ section of a website). On day one, members are asked to take part in a lightning round where they ask experts (often within the company) key questions that will help them understand the problem they’re tackling. One day two you then jump into ‘solution mode’. This is where each member of the team sketches solutions (~8 per person) based on their contextual understanding taken from the single day of research that was done the day prior. On day three, individuals choose their ‘best’ ideas, which are then presented to the rest of the group (sometimes anonymously). The group then ‘votes’ for which one they think is the best. When performing design sprints, this happens in person using physical dot stickers, or sometimes people use tools like Jira, or Basecamp to do the voting when teams are remote. Another caveat to this method is that you can’t vote for your own idea.
Day four is when you make your chosen idea ‘come to life’. This is where you (or one person in the group) prototypes the voted solution to higher fidelity, so it looks ‘real’. This is usually done by a single member (you can’t really have 5 members working on a single prototype) using software like Sketch, Invision, Adobe XD, or Figma. Now on day five, you have a clickable prototype that you ‘test’ with a hypothetical user. Often, this is an individual within the company, and they are asked to ‘use’ this prototype and imagine/pretend it’s real. The team then learns how their hypothetical user reacts to the prototype to identify pain points so they can make it better. What happens next week is totally up to the organization. They could be working on another feature or they could be fixing problems with their current prototype. Nobody really knows where to go next.
Design Sprints Are a Bandwagon Trend
Due to its adoption and promotion by Google (an engineering company), the design sprint has been sold to and embraced by seemingly thousands of massive corporations across the globe to invent new products and fix existing ones. The script reads like this: Multi-billion-dollar corporation realizes they need to do some form of ‘digital innovation’, so they hire a bunch of designers to work with engineers to invent new products and solve new problems. They place these new designers and engineers in some segregated part of the building, throw a pool/ping-pong table into the mix and think, ‘get cracking!’.
What ends up happening is that months if not years go by and nothing of market value has come to fruition. The products they do design are a mess and everyone on the team is miserable (high turnover). Top executives may then fire the head of innovation and attempt to start over again. The failure here is not a people problem, it’s a process problem. Sprinting is just a god awful approach to innovation. Processes like these cannot be trusted in the real capitalist economy.
Problem 1 · Zero Rigour
Design sprints lack any form of scientific rigor or sound research methodology. It’s an ego touting exercise where often the loudest voice in the room wins, and qualitative feedback as taken as absolute truth. According to the design sprint methodology, research takes place in a whopping one to two days. We know that through the multitude of biases that humans hold that this is absolutely absurd. One cannot simply ask an internal ‘expert’ some qualitative questions in a single day and use that information as the basis for a monolithic project that will affect thousands if not millions of people. In life and in business, it is the early decisions that matter the most because these decisions lay the groundwork for things to come (see path dependence). Also, we know through biases such as the sunk-cost fallacy, it is very difficult for humans to change the course direction once they have already invested time and money into a particular problem. The research phase of a project should never be so hasty. It is serious work.
Even the testing phases of the design sprint lack rigor. Experimenting with recruited users is an extremely unnatural way to gain insight. If you’ve ever participated in user testing you may understand the problem. Often times, someone ( a design member) will be sitting directly next to the testee, leading to an uncomfortable dynamic where the user feels anxious and possibly pressured to conform or agree with the design solution. It may lead to people-pleasing, which is contrary to the mission of testing — to get objective critical feedback. Another huge problem is that design sprints encourage ‘think out loud’ tests. This is where the user is to verbalize what he or she is thinking, feeling, or observing. No human in their right mind scans information and consciously vocalizes it unless they’re reading a book to their child before bedtime—it’s actually quite difficult to do especially when you’re ‘learning’ a new product. When someone is speaking, they’re using a different part of the brain so the unconscious learning process is compromised—their chances of ‘success’ are diminished. The ‘think out loud’ test rarely extracts good insight. Often times, it is best to just test the product further with the team or with other designers. Your users are not designers, so stop asking them to be.
Problem 2 · Social Friction
Design sprints tend to remove software developers (and other stakeholders) from the research and ideation phases of the project, which is a sure-fire way to build resentment with the very people building the product. When I was working with IBM, we were designing a front-end product that visualized how mainframe applications were performing. None of the design team even knew what a mainframe was prior to working on the project, yet we were the ones making all the decisions and essentially telling the developers what to build. In this case, the development team knew way more than we did about mainframe application performance (what matters and how it works)—but the methodology didn’t allow for cross-pollination of ideas. Roles were segregated. This lead to extreme emotional tension between the group and most of the stakeholders essentially became miserable and hopeless. The development team had to frequently remind us of why we were wrong, thus we dreaded discussing solutions with them because our ideas were flawed due to our lack of contextual understanding. Development dreaded the work because they had no power or autonomy over what they were building, and they knew they were implementing sub-valuable features. They were simply told to execute what we told them without involving them in the design process. This led to a very uncomfortable work environment and weakened group morale.
Another problem with design sprints is the process of sticker voting or pitting members of the group against each other. This article, Why Google’s Sticker Voting Method Kill’s Innovation, unpacks why this method is creative sacrilege. To summarize, ideas are sacred to the individuals who hold them and when their ideas don’t get chosen, resentment builds and learned helplessness sets in. Subsequently, members of the team are less likely to ‘try’ in following sprints because oftentimes the voting boils down to politics and groupthink. People desperately don’t want to oppose people of authority within the group, thus they become complacent and stop trying to argue ideas. Moreover, team members should be creating solutions together and validating the pros and cons of different concepts—not just choosing one. There could be a plethora of valuable features in unchosen concepts. The competitive element of sticker voting just isn’t good for innovation.
Problem 3 · Hastiness
Sprinting has gained such immense widespread attention and implementation because of the marketing behind it. It sounds ‘fast’, and in technology, speed equals ‘good’. How many job ads have you seen looking for a manager, design, or developer who thrives in a ‘fast-paced’ environment? It’s in almost every single job description. The word ‘sprint’ alludes that things are getting done—it fits well with the corporate facade that things are moving swiftly, even when they probably aren’t. Moving swiftly in the wrong direction only further sets you back in the long run.
If you’ve ever worked in both the corporate and startup environment you probably understand that things tend to move a lot slower in the former. There are often days when there is nothing to do but people keep things hush because they don’t want to lose their job — they don’t want to rustle feathers. The ‘design sprint’ is an effective sales strategy because it makes it seem more productive and valuable than it actually is. When implementing design sprints you can be sure your designers aren’t sitting around, simply pishing pixels (oftentimes this is the case). We know this is true because digital products with good traction (Google, Facebook) don’t actually change much over time. These highly profitable successful companies/products are turning good revenue, and have the ability to hire new designers—but they are too rigid and scared to modify the product that led to its success. This leaves an organization with a huge team of highly paid, unsatisfied designers and developers. This absolutely kills morale and isn’t good for the company. I will discuss solutions to this problem in a later article.
The research involved in design sprints lasts one to two days. Do you see a problem with this? While there is definitely such thing as too much research, it is absolutely ludicrous that months of work are being mandated based on insight derived from a single day of qualitative feedback—usually by a person recruited within the organization (obvious bias issues). In life and in business, early decisions are extremely important because they lay the foundation for what can be done in the future. It’s extremely costly to rebuild a foundation once it’s set. A great example of this can be seen in city planning. Urban areas take decades to build, and before any houses are constructed there needs to be infrastructure (sewage, drainage, roads, electrical) set in place before people can actually live there. Once the infrastructure is built, it becomes extremely difficult to change for both logistical and psychological reasons (sunk-cost fallacy). In economics, this concept is known as path dependence. Here is an excerpt from Wikipedia on the phenomenon.
Path dependency is an idea that tries to explain the continued use of a product or practice based on historical preference or use. This holds true even if newer, more efficient products or practices are available due to the previous commitment made. Path dependency occurs because it is often easier or more cost effective to simply continue along an already set path than to create an entirely new one.
Path dependency implies quite accurately that early-stage decisions are critical because subsequent changes with time will be exponentially more challenging, if not impossible to make. For this reason, when designing a business/product/service (all interchangeable terms), it’s better, ‘to begin with the end in mind’. Try to understand the core value of what you can provide, along with the multitude of factors and trends affecting your industry, prior to ‘marrying’ anything. Start functional, and be wise. Do not rush development in the early stages. Stop sprinting, and start planning. It’s better to know more than less.
Conclusion
I’ve seen the sprint methodology adopted everywhere, largely in part because it has the ‘Google’ name attached to it. Every time I see the sprint methodology adopted I see the same problems come to fruition. One, it forces businesses to make critical decisions very quickly without proper contextual understanding. Another problem is that it pits teammates against each other, causing hostility—a morale killer. Design sprints also encourage social loafing, because it suggests having a very management/design-heavy team. This isn’t optimal for many reasons.
Sprinting also forces us to behave like feature factories — where we keep piling on items for the sake of moving forward. Often times what happens is you have a complex product that isn’t intuitive or functions poorly because you’ve made the goals about adding value instead of defining and sculpting value. As seen in the graph below, more eventually means less— once you keep adding to its complexity there is a critical point in which value starts declining. This theory parallels the law of diminishing returns.
Design ‘Sprints’ — like artificial intelligence, virtual reality, and cryptocurrency are bandwagon trends that have gained popularity because of the ‘sexiness’ of their marketing. Almost every corporation that has undergone a ‘digital transformation’ is performing design ‘sprints’ to some degree. The reason for this is the marketing of the methodology itself (a gimmick). Sprinting sounds ‘cool’ and exudes an element of ‘speed’. ‘We’re working hard and fast to get things done, here at Innatech’. ‘We’re working in a fast-paced environment and that means good things are happening’. Sprinting is what George Costanza would do to show executives that he’s working hard and getting things done. The problem is there is no point in working hard and fast if you’re working in the wrong direction. That will only bury you and the organization into a deeper pit of despair. Stop sprinting and start solving.
I’m Jeff Davidson
I help companies design awesome products. Contact jeff@jeffdavidsondesign.com for project inquiries. You can also get free design lessons on my site.
