Gary Coker

UX and Product Design Leader

Creative Leader with 20+ years of Director- and VP-level experience

Design Thinking

How I use Design Sprints to engage stakeholders, produce better products, and cultivate a Design Thinking culture

Why Design Thinking?

Many factors contribute to a user's overall journey with a product and company, not just UI design. Things like technical performance, how to get help or support, even how to buy the product in the first place, and so on. So design can and should influence the entire product lifecycle, from inception and strategy to development, marketing, and customer care. Peter Merholz & Kristin Skinner, in their book "Org Design for Orgs", described this idea well:

If a single team is labeled as the primary keeper of the user experience, that absolves other departments from concerning themselves with it. User experience must be everyone’s responsibility.

And that really does mean everyone, including the business, engineering, marketing, sales, operations, customer care, etc. When everyone is thinking about the customer's and user's experience while doing their work, the total journey can take huge leaps forward to produce delighted and loyal customers.

Champion Design Thinking with Design Sprints

One of the keys to cultivating a Design Thinking culture is simple: Get stakeholders to participate in design. There are many ways you can facilitate this idea, such as providing open, accessible design activities where stakeholders can observe UX team members at work. But one of the best ways I've found is the use of Design Sprints, as defined by Jake Knapp at Google Ventures.

I've facilitated and participated in many Design Sprints with a diverse range of stakeholders participating, from Product Managers to Subject Matter Experts (SMEs) to developers to executives, and more. Everyone who participates experiences the value of Design Thinking, takes it back with them to their own work, and invariably becomes another advocate of the shift.

So while Design Sprints are a superb way to improve the product itself and get to market faster, they also provide the added benefit of planting the seed of Design Thinking into everyone who participates, creating a culture that improves everyone's work.

I created a 2-part course on Design Sprints for UX-BHM (a group for UX professionals in Birmingham). Click the button below to view the first slide deck in the course, "Getting Started with Design Sprints". You can also find this deck on my LinkedIn profile. Interested in the second half of the course, "Design Sprints: Facilitation, Operation, Efficiency"? Send me an email.

"Getting Started with Design Sprints" (PDF, 1.2MB)

Design Sprint timeline

Most Design Sprints follow a 5-day timeline, as shown here. The first 3 days are spent defining the problem, sketching solutions, and then deciding on which solution to prototype and test. On Day 4, we build an interactive prototype of the solution and on the last day we test the prototype with real users. We can then analyze the results to decide how to move forward.

Shared online whiteboard in a Design Sprint

For remote Design Sprints, we use a shared whiteboard app (in this case, Miro) to work through the activities in the sprint. The board also captures documentation of all sprint activities.

Activities may include problem framing, creating a sprint goal, brainstorming important sprint questions, expert interviews, developing user personas, ideation via Lightning Demos and Crazy 8s, UI sketching, dot voting, storyboarding, and more.

Interactive prototype created in InVision

After our design activities are complete and captured on the whiteboard (days 1-3), on Day 4 UXers build an interactive prototype that we can usability test with real users. This one was built in InVision.

Usability Testing Script developed for the interactive prototype

Also on Day 4: While our interactive prototype is being created, the facilitator (or a UX team member) writes a usability testing script for the prototype, with real-world tasks for the user to perform by actually using the prototype. No questions about if the user "likes" the design -- we're interested only in the user's behavior and if the design produces the desired outcome of solving the user's problem. The tasks in the script allow us to objectively measure whether users can efficiently complete tasks using the prototype, or whether additional work is required.

Recording a usability test in Google Meet

When the interactive prototype and usability test script are ready (should take only one day of a 5-day sprint), we conduct interactive usability testing of the prototype with real users, asking them to perform real-world tasks using our usability testing script created earlier. We record all the sessions in Google Meet for later review and analysis. Design Sprint participants are encouraged to observe as the tests are conducted. Plus, any stakeholder in the company can observe the tests if they like.

Findings help us decide if we met the Design Sprint's goal

After completing the usability tests and analyzing the findings, we can decide how successful we were in meeting our Design Sprint goal. Plus, we can identify areas that need additional work to enhance the user experience.

Findings for the Order Details screen

After analysis, we present detailed findings from the usability test to all stakeholders, categorizing the findings into Worked Well, Needs Work, and New Ideas buckets, similar to the format of a Sprint Retrospective. Here we see findings from the Order Details screen of the prototype created for this Design Sprint.

Findings for the Bundle Details flexpane

Here, we present detailed findings for a Bundle Details panel (which we call a "flexpane" in viax's design system). This flexpane was an important part of the Product Bundling solution designed during the Design Sprint.