Discovery Sprints: Level Up Enterprise Product Design with UX Part 2
Unlock the collaborative spirit of design sprints
Product designers utilize creative skill sets and a technical knowledge of interaction patterns to improve the way customers engage with a company’s products. However, the design process is actually quite collaborative. When empowered to do so, a design team will seek to involve stakeholders across the organization and actively engage customers at every stage to deliver truly innovative solutions.
Working aside the product team, design can provide value across the entire life-cycle illustrated below. In a previous article I discussed customer insights and ideation: working with product management to help validate the product roadmap and establishing a UX strategy supporting customer-centric user stories. You can read that article here.
This article will take a closer look at the role UX plays in validating ideas through the design process. The design process is a way to break down large stories into manageable chunks. It is a common process used by design thinkers across many fields: science, architecture, engineering…
The ideas coming out of the product roadmap are problems to be solved; and we want to make sure we’re shipping the right solution. To be clear, the user experience is paramount but there is another major advantage to this process: cost savings. When the alternative is potentially shipping an unproven feature that customers fail to embrace, design is comparatively cheap.
What a UX team can provide at this stage is a glimpse into multiple potential futures, giving product owners the data they need to move products into the very costly stages of development, sales, training and support.
This is done by designing working prototypes. Not coded proof of concepts, but clickable prototypes that for the most part look and feel like ready to release software. Getting to those prototypes is a multi-disciplinary team effort.
The Discovery Sprint
A great deal has been written on the design process — and design thinking in general, and there are equally many variations in executions. However they all generally follow the phases outlined above. Note that the model illustrated here follows the “Double Diamond” diagram presented by the British Design Council. The phases first diverge (widen out) to explore and then converge to narrow in on a solvable problem/solution.
Discovery sprints occur well ahead of delivery sprints and as with agile development sprints, a design sprint focuses on a single story. However, depending on the complexity of the problem they may require longer timelines to allow for exploration (4–6 weeks for example). At a minimum, a discovery team includes a product manager and a UX designer. The level of collaboration with stakeholders ranges from regular status updates to collaborative design sessions. Google Ventures has popularized a method of compressing this process into a 5-day sprint. It involves having key stakeholders (including the decision maker) in a room for five days. Unplugging key team members from their day-to-day schedules for a week (and in some cases flying them to a central location) is no simple task — so the 5 day sprint is best reserved for particularly troublesome issues or for kicking off those key strategic initiatives with high visibility.
The Sprint Stages
Understanding the Problem: Discover and Define
A design sprint begins with an understanding of the problem to be solved. In order to arrive at the right solution we need to fully understand all the issues. Discovery is a research phase wherein the team meets with key stakeholders, domain experts and customers to fully understand the entirety of the issues being addressed. With a renewed empathy for the end-user’s unmet needs and a clear understanding of the related technical constraints and business requirements the team can now define the desired outcome for the user — the problem to be solved.
Designing a Solution: Explore and Build
The design team will again widen their focus to explore a wide range of potential solutions to the defined problem. This is the creative paper and whiteboard stage: brainstorm, sketch, debate, sleep on it, try again. Ultimately the team will want to converge back into a testable solution and build a prototype. However, they may not reach a consensus on a single design so rather than continue debating they’ll move forward with multiple prototypes.
Prototype Testing: Permission to Fail
Designers build prototypes to validate ideas (potential solutions) with end-users. Research participants are asked to complete tasks using the prototype; which at this stage should look and feel like working software. A users response will tell us if we’re headed in the right direction: Is it useful, usable and desirable? Yes: move it on to development. No: back to the drawing board.
Remember, ‘no’ isn’t a bad outcome. In fact it may have just saved the company from directing massive budgets into a feature destined for failure. In some ways the design process and a designs teams job is to fail and recover while it’s still cheap to do so. The final stage of the product life-cycle is delivery and the design process weeds out the weak ideas, making sure the company is delivery the right solutions.
