Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible, serving us without drawing attention to itself. Bad design, on the other hand, screams out its inadequacies, making itself very noticeable.

—Don Norman, The Design of Everyday Things

Design Thinking

Design Thinking is a customer-centric development process that creates desirable products that are profitable and sustainable over their lifecycle.

It goes beyond the traditional focus on the features and functions of a proposed product. Instead, it emphasizes understanding the problem to be solved, the context in which the solution will be used, and the evolution of that solution.

Note:  This article focuses on the tools and practices associated with implementing design thinking. It should be read along with the Customer Centricity article, which focuses on the mindset and impact of customer centricity.

Details

Traditional waterfall approaches to product development are sequential: requirements are defined; then, solutions are designed, built, and delivered to the market. The focus tends to be on the most apparent problems. Often, success is determined by implementing a solution that meets the requirements instead of the needs of the user, resulting in products and services with unusable or ignored features that frustrate users and fail to meet the business goals of the enterprise.

Design thinking (Figure 1) represents a profoundly different approach to product and solution development, in which divergent and convergent techniques are applied to understand a problem, design a solution, and deliver that solution to the market.

Figure 1. Design thinking activities

Design thinking also inspires new ways to measure the success of our efforts:

  • Desirable – Do customers and users want the solution?
  • Feasible – Can we deliver the right solution through a combination of build, buy, partner, or acquire endeavors/activities?
  • Viable – Is the way we build and offer the solution creating more value than cost? For example, in a for-profit enterprise, are we profitable?
  • Sustainable – Are we proactively managing our solution to account for its expected product-market lifecycle?

Successive applications of design thinking advance the solution over its natural market lifecycle, as shown in Figure 2.

Figure 2. Advancing the solution over the solution lifecycle through design thinking

The Problem Space and the Solution Space

In Figure 1, the core processes of design thinking appear visually as a ‘double diamond’. This represents the focus on thoroughly exploring the problem space before creating solutions. The activities associated with exploring the problem are elaborated as follows:

  • Discover – The discover phase seeks to understand the problem by engaging in market and user research to identify unmet needs. This creates fresh perspectives that drive innovation. Unlike research that confirms or refutes a hypothesis, the inquiries associated with the discovery phase occur without preconceived notions about how users should work. Instead, it focuses on how users do work. An essential research technique is Gemba, also known as, “going to the place where the work is done.”
  • Define – The define phase focuses on the information gathered during the discover phase, using convergent techniques to generate insights into the specific problems and/or unmet needs. These create opportunities for the enterprise and new product development. Results of this phase typically include personas and empathy maps (described further below) that focus the product team on the kinds of solutions the customer would view as desirable. Epics and Features capture the perceived changes needed for existing products and solutions.

With a clear understanding of the target market and the problems it’s facing, the enterprise can move towards designing a solution, the second diamond of design thinking. These are:

  • Develop – The develop phase uses journey mapping, story mapping, and prototyping to design potential solutions to problems quickly and cost-effectively. Each of these techniques is discussed more thoroughly later in this article. The develop phase also embraces SAFe Principle #3 – Assume variability; preserve options, using design techniques to preserve options in a responsible manner.
  • Deliver – The deliver phase produces artifacts that are suitable for creating the solution and vary based on context. They often start as prototypes that are expressed as a validated set of Features in the Program Backlog for ongoing delivery through the Continuous Delivery Pipeline.

Note that each diamond focuses on divergent thinking (understanding, exploring options) followed by convergent thinking (evaluating options and making choices).

Using Personas to Focus Design

Bespoke solutions offer designers the advantage of speaking directly and frequently with a few targeted users, permitting them to participate in design meetings, PI Planning, System Demos, and other SAFe events. In several organizations, these people are considered part of the team, so creating a Persona to represent them isn’t typically needed, but may be helpful when the organization is highly distributed.

In contrast, in an indirect customer market, which is common in B2C solutions, product teams need a way to maintain a connection with their target customer. So, they develop ‘personas’, fictional consumers and/or users derived from customer research. [2] They depict the different people who might use a product or solution in a similar way, providing insights into how real users would engage with a solution. User personas also support market segmentation strategy by offering a concrete design tool to reinforce that products and solutions are created for people. Personas drive product development and several SAFe practices, as shown in Figure 3.

Figure 3. How Personas can drive key activities in SAFe

In addition to user personas, buyer personas extend design thinking to include the individuals and organizations that authorize purchasing decisions. They help ensure that the design encompasses the whole product purchase experience, including after-sales service, support, and operations.

Establish Empathy Through Empathy Maps

Customer-centric enterprises use empathy throughout the design process. Broadly speaking, empathetic design dismisses preconceived ideas and uses the customer’s perspective to inform solution development.

Empathy maps[1] are a design thinking tool that promote customer identification by helping teams develop deep, shared understanding for others (Figure 4). They help teams imagine what a specific persona is thinking, feeling, hearing, and seeing as they use the product. The greater the degree of empathy that a team has for their customer, the more likely the team will be able to design a desirable solution.

Figure 4. Empathy Map Canvas

Designing the Customer Experience through Journey Maps

A customer journey map illustrates the experience as a user engages with a company’s Operational Value Stream, products, and services. As shown in Figure 5, journey maps are powerful design thinking tools for operational value streams. They allow teams to identify ways in which the specific deliverables of one or more Development Value Streams can be improved to create a better end-to-end experience.

Figure 5. Operational Value Streams and Customer Journey Maps

Delivering Benefits Through Features

While a journey map captures the high-level experience of the customer through the operational value stream, product Features manage the specific deliverables that fulfill a stakeholder need. Features are commonly described through a features and benefit matrix using short phrases that provide context and a hypothesis of the benefits that the user experiences.

Design thinking practices promote changing the order in which we consider elements of the Feature-Benefit Hypothesis. They help Agile teams explore better and faster ways to deliver the desired benefits (Figure 6).

Figure 6. The traditional ‘features and benefits’ matrix becomes a ‘benefits and features’ matrix

Designing User Workflows through Story Maps

Features are implemented through one or more Stories. There are two types of stories in SAFe:

  • User Stories are the primary means of expressing needed functionality. They can be written in a role format or a persona format:

Role: As a <user role> I want <activity/goal> so that <some reason, such as creating business value or personal value>

Persona: Frank wants to <activity/goal> so that Frank gets <value>

  • Enabler Stories capture system, architecture, or infrastructure requirements, such as building improvements to support the continuous delivery pipeline.

The Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise from the team’s local context. Like all backlogs, the Team Backlog is prioritized, and stories are implemented in priority order.

Features that capture a workflow present a unique challenge to Agile teams: A workflow is a sequence of steps that must be completed to accomplish a higher-level user goal. The linear order of a backlog can make it hard for Agile Teams to understand the relationships between the steps. Frequently a given step can be improved, and teams must also balance completeness (all of the steps must be supported) before improving a specific set of steps. Potential conflicts arise when the divergent phase of developing a solution envisions improvement opportunities, while the convergent phase of design thinking focuses on what’s essential for the next release.

Solutions contain both large and small workflows. Consider the small workflow of a businessperson importing a credit card statement into an expense reporting system for processing. The user must:

  • Download the credit statement from the bank
  • Upload the credit card statement into the expense reporting system
  • Match transactions from the credit card statement with expense receipts stored in the expense reporting system
  • Remove any non-reimbursable transactions

As described earlier, each of these stories can be captured in a workflow. Moreover, each can be improved over time: We could, for example, imagine a direct connection between the bank and the expense reporting system, or an automated AI agent that managed the task of matching transactions.

Features that represent a workflow are captured through story maps [3], which organize a sequence of stories according to the tasks a user needs to accomplish their goal (Figure 7).

Figure 7. Sample Story Map

Story maps enable teams to understand how the stories in the team backlog support user objectives (Figure 8).

Figure 8. Relationship between Story Maps and Team Backlogs

Story maps also clarify the relationships between quality and value:

  • Quality – Each Story in the backlog must be completed with quality
  • Value –  All the selected Stories in the Story Map must be completed to create value, because if a Story is missed, the user cannot complete their workflow

Increasing Design Feedback Through Prototypes

A prototype is a functional model of the Feature or Product we wish to build. It helps the design team clarify their understanding of the problem and reduces risk in developing a solution. Prototypes provide a myriad of benefits to product teams:

  • Fast feedback. By definition, a prototype is cheaper and faster to produce than a full solution. This enables faster feedback from users and customers, increased understanding of solution requirements, and greater confidence in the final designs.
  • Risk reduction. Prototypes can reduce technical risk by enabling Agile teams to focus initial efforts on the aspects of the solution associated with the highest risk.
  • Intellectual property / patent filing. Prototypes can be used to satisfy strategic requirements for managing intellectual property as early as possible in the development process.
  • Models for requirements. Prototypes can provide more clarity in the requirements of the desired feature or solution than pages of documentation.

There are many kinds of prototypes, each optimized to provide different types of insights:

  • Paper prototypes are typically hand-drawn sketches of the intended solution. They can be automated to illustrate workflows as complements to user story maps.
  • Mid-Fi prototypes are visually-complete representations of software-centric solutions but are not typically functionally integrated.
  • Hi-Fi prototypes are visually-complete and interactive models which users and customers can directly explore.
  • Hardware prototypes provide critical feedback to the Agile team on such things as form factors, sizes, and operational requirements. For example, when exploring form factors to see how a new tablet might fit into existing backpacks, briefcases and cars, one Silicon Valley company simply cut a multitude of plastic models from a single sheet plastic. Later in this design process, this same team found they needed to redesign the power supply so that it would not unduly interfere with the WIFI signal.

To help them gain actionable feedback, product teams should strive to leverage the lowest-cost, fastest form of prototyping. Often, paper prototyping is the best choice. [4][5]

Learn More

[1] Empathy Map Canvas. https://medium.com/the-xplane-collection/updated-empathy-map-canvas-46df22df3c8a

[2] Cooper, Alan, Robert Reimann, David Cronin, and Christopher Noessel. About Face: The Essentials of Interaction Design 4th Edition. Wiley, 2014.

[3] Patton, Jeff, and Peter Economy. User Story Mapping: Discover the Whole Story, Build the Right Product 1st Edition. O’Reilly Media, 2014.

[4] Snyder, Carolyn. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann, 2003.

[5] Gothelf, Jeff, and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media, 2016.

 

Last updated: 10 February 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.