Design finally sprints into the lead

 

Design sprints drive software success. Here’s how to instill great UX in your apps without sacrificing delivery speed.

By Fatos Berisha Ph.D.
October 6, 2015

Good design is always good business. Sounds like something you’d read in a modern design magazine, but in fact it was IBM President Thomas Watson Jr. who said it, almost half a century ago.

What’s even more surprising is that our industry is only now realizing the obvious corollary: that great design is the real true differentiator of digital/tech products. The biggest splashes are invariably made by organizations that integrate design into every product right from the beginning. Their products delight the users, they outsell run-of-the-mill ones, they are easier to support and maintain, and most significantly, they are excellent for the bottom line. Just ask our friends at Apple Inc.

But designing the right product to win in the marketplace remains as hard as it ever was and competition is now fiercer than ever—your great design basically needs to be ready by yesterday morning because by yesterday noon you’re just another “fast-follower”…

So is there a quick, versatile, and robust methodology or framework able to eliminate failures and delays caused by badly or even un-designed products? One that will succeed most of the time to elevate your solutions above the mundane and the mediocre? And that will regularly reward your teams and your customers with truly excellent digital products?

Well, there might be. Enter the design sprint.

 

Five Steps to Better UX

The “design sprint” is not entirely novel—its key strength comes from combining some of the best concepts and practices of Design Thinking, Agile, and Lean amongst others—but it represents an important innovation in digital product design. It was developed at Google Ventures (GV) and its most common high-level definition is: “a flexible product design framework that serves to maximize the chances of making something people want.” This is what they say at GV:

(With design sprints) we shortcut the usual endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, teams get great data from a prototype. The sprint gives these companies a superpower: the ability to build and test nearly any idea in just 40 hours.

The other critical strength of the design sprint framework comes from its intrinsic flexibility. While no design process is one-size-fits-all, the design sprint process can be easily modified to meet the needs of different projects, in different stages of completion, for various types of organization. It can be shortened to a couple of days or extended to a couple of weeks; you can run with it in a small office with just three or four other people or in a large conference room with 10 to 15 participants and stakeholders.

“OK, I’m interested, how do we actually do this?” I hear you say. By executing a five-phase intensive process where the results will set the direction for a product or service and answer critical business questions through design, prototyping and testing ideas with customers. The five phases are most commonly known as:

  1. Understand: Bring the working team to a mutual understanding of the problem to be solved.
  2. Diverge: Look at potential solutions and generate as many ideas as possible.
  3. Converge: Pick a direction to prototype and test with users.
  4. Prototype: Simulate the selected solution with just enough detail to allow adequate testing of the assumptions the team has made.
  5. Test & validate: Test the prototype with real users and learn which ideas worked, which didn’t, and what to do next.
These phases must be preceded by a preparation phase—in which we set the stage and complete the scoping and planning—and succeeded by a wrapping-up phase where the sprint master creates a followup plan, shares the results and surveys the participants to learn how to improve future design sprints (this often represents the prep phase for the next design sprint iteration).   Sprinting at iRise Here at iRise, these steps have been for years the mainstay of our core process—either in our consulting work with customers or in proof-of-concept workshops with our prospects. We have used our iRise collaborative prototyping technology and expertise in conjunction with the key tenets of this framework in many a digital product or feature design engagement to rapidly identify the requirements, flesh out the solutions and validate or invalidate them in hours. What’s funny is that until recently we’ve pretty much done this implicitly, without calling them out expressly and probably without employing the full arsenal of methods provided by the design sprint framework. We now do, with design sprints being a fully fledged offering delivered by our iRise Professional Services teams. I truly hope this has whetted your appetite, because in my next three posts, I’ll cover the above steps in more detail and describe practical, repeatable methods and activities that are used in each of phase to unleash your team’s creativity and come up with new answers to difficult problems. I’ll also explore scenarios in which it is (and isn’t) advisable to conduct a design sprint. I’ll include practical advice on how to spot situations where a design sprint isn’t the right course of action in a project—though it often might be so at a later stage after some further work and clarification. And finally, I’ll describe and analyze the possible outcomes of a design sprint and their optimal respective follow-up strategies. Stay tuned!

These phases must be preceded by a preparation phase—in which we set the stage and complete the scoping and planning—and succeeded by a wrapping-up phase where the sprint master creates a followup plan, shares the results and surveys the participants to learn how to improve future design sprints (this often represents the prep phase for the next design sprint iteration).

 

Sprinting at iRise

Here at iRise, these steps have been for years the mainstay of our core process—either in our consulting work with customers or in proof-of-concept workshops with our prospects. We have used our iRise collaborative prototyping technology and expertise in conjunction with the key tenets of this framework in many a digital product or feature design engagement to rapidly identify the requirements, flesh out the solutions and validate or invalidate them in hours.

What’s funny is that until recently we’ve pretty much done this implicitly, without calling them out expressly and probably without employing the full arsenal of methods provided by the design sprint framework. We now do, with design sprints being a fully fledged offering delivered by our iRise Professional Services teams.

I truly hope this has whetted your appetite, because in my next three posts, I’ll cover the above steps in more detail and describe practical, repeatable methods and activities that are used in each of phase to unleash your team’s creativity and come up with new answers to difficult problems.

I’ll also explore scenarios in which it is (and isn’t) advisable to conduct a design sprint. I’ll include practical advice on how to spot situations where a design sprint isn’t the right course of action in a project—though it often might be so at a later stage after some further work and clarification. And finally, I’ll describe and analyze the possible outcomes of a design sprint and their optimal respective follow-up strategies.

Stay tuned!