13. Experience Design

Experience design alternates divergent and convergent thinking in both the problem space and the solution space. As illustrated in Figure 29, “Customer Research” is in the “Problem Space” and “Product Discovery” is in the “Solution Space”.

fig-dt-logic
Figure 29. Design Thinking Logic

The purpose of customer research is to target the right customers and identify unserved needs. It requires an anticipation of the future, the identification of relevant trends, and an understanding of what is likely to change or to remain the same. Relevant trends are those the enterprise can leverage to solve customer problems in new and better ways.

Customer research aims at discovering a market which consists of all the existing and potential customers that share a particular need or set of related needs [Olsen 2015]. It is the home of all the customer needs to which you would like your product to deliver. The word “needs” should be interpreted broadly as it includes jobs-to-be-done, pain points, desires, or emotions.

In contrast, product discovery is in the solution space: “Any product that you actually build exists in solution space, as do any product designs that you create – such as mockups, wireframes, or prototypes” [Olsen 2015]. It is driven by outside-in thinking. The product is defined through the lens of the customer.

In his seminal Marketing Myopa paper, Theodore Levitt writes: “The organization must learn to think of itself not as producing goods or services but as buying customers, as doing the things that will make people want to do business with it” [Levitt 1960].

The focus shifts from products to problems customers want to solve: “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”. Customer research is about discovering the “quarter-inch holes” that customers are looking for. Clayton Christensen coined the term “job-to-be-done” to designate them.

“Job” is shorthand for what an individual really seeks to accomplish in a given circumstance. The circumstances are more important than customer characteristics, product attributes, new technologies, or trends [Christensen 2016].

13.1. Experience Design Approach

This approach drives experience design from an outside-in thinking stance. It iterates design thinking cycles, as described in Figure 30.

fig-experience-design
Figure 30. Experience Design Approach

Each iteration tests the hypotheses formulated in ideation using prototypes. As progress is made in the product development lifecycle, new hypothesis testing practices are used.

For example, companies like Netflix® and Facebook® have pioneered techniques like “canary deployments” and “A/B testing”. Two different features are tried out simultaneously, and the business results are measured. For example, are customers more likely to click on a green button or a yellow one? Testing such questions in the era of packaged software would have required lab-based usability engineering approaches, which risked being invalid because of their small sample size. Testing against larger numbers is possible now that software is increasingly delivered as a service [DPBoK 2020].

13.2. What is a Product?

Products are at the crossroad of strategy and marketing, design science, operations, and engineering. Understanding products requires the borrowing of practices and vocabularies from these disciplines. They jointly contribute to discover, architect, and develop products.

The term “product” is widely used in the Agile community. Though numerous articles and books discuss the shift from project to product, at the time of writing, few, if any, give a definition of product. This document believes the Agile and Enterprise Architecture communities need a shared understanding of what product means.

Theodore Levitt states that a truly marketing-minded firm tries to create value-satisfying goods and services that consumers will want to buy [Levitt 1960]. This implies that product includes both goods and services. In his book Innovation in Marketing [Levitt 1962], Theodore Levitt answers the question, what is a product?

He observes that designing a better and less expensive piano would have less impact on sales than providing a simpler and more enjoyable beginner’s piano method. He concludes that it is necessary to expand the product the organization wants to sell. It must be defined much more broadly to include non-core elements that contribute to a user’s satisfaction. The conclusion is that product refers to both goods and services.

Following Theodore Levitt’s path, Marty Cagan [Cagan 2018] provides a holistic definition of product:

“A product includes the functionality – the features. But it also includes the technology that enables this functionality. It also includes the user experience design that presents this functionality. And it includes how we monetize this functionality. It includes how we attract and acquire users and customers. And it can also include offline experiences as well that are essential to delivering the product’s value.”

When using the terms product and service, ambiguity often remains:

  • For some, product means a good as opposed to a service

  • Sandra Vandermerwe and Juan Rada coined the term “servitization of business” to refer to market packages or “bundles” of customer-focused combinations of goods, services, support, self-service, and knowledge [Vandermerwe 1988]

  • Mohanbir Sawhney describes how high-end professional services firms can embed products in their service offerings [Sawhney 2016]; product here refers to the standardization and industrialization of portions of the service value chain

To avoid terminology and meaning ambiguity, the definition of product can be found in Section 2.40.

Note

Products are bundles of services and/or goods. Products have features through which customers and users interact:

  • A product feature can be a service feature or a goods feature

  • A feature is a “handle” through which customers or users experience products

Products deliver outcomes which are defined by the customer/user experience and depend on circumstances. In the piano example, the outcomes could be:

  • Enjoying good music, and sometimes not so good music

  • Feeling proud of your child’s musical performance

  • Aesthetic pleasure from a piano decorating your living room

13.2.1. Intangible Goods

The tangibility criteria is sometimes used to distinguish services from goods. While services are obviously intangible, goods can be both tangible and intangible. In the case of software, a High Court case in 2016 held that software was indeed goods, although it was intangible [Rezai 2016].

When buying a word processor package from a software vendor, a client makes the software available to some users (including themself) to act upon this software. They use the various software features (spelling features, formatting features, printing features, etc.) to achieve the outcome of a text document. When printing, user satisfaction comes from experiencing both the printing process and the quality of the printed document.

The reasoning is not different when the word processor is an online word processor. Users still act upon the online word processor to get their printed documents. However new software-enabled services have been added to the word processor product: automated upgrade, cloud backup, etc.

The case of online banking applications is different. They are software resources used by banks to deliver web-exposed account management services. Such applications are part of the account management service provision; they are not goods. Another example is “Infrastructure as a Service (IaaS)”. The main outcome of IaaS is computing resources (similar to rented computers). They are goods as there is a need to act upon these resources to install and run software on servers. Of course, IaaS products go beyond server goods as they also embed online services, such as the dynamic provisioning of resources.

Consequently, the distinctive characteristic between goods and services is that goods are acted upon to deliver outcomes while services are delegated acts that deliver outcomes. The distinctive characteristic is not tangibility.

13.3. Customer Research

Customer research combines traditional market research with customer/user experience research.

13.3.1. Market Research

Market research identifies customer segments and analyzes customer needs and behavior. It explores current and potential customers to identify unmet customer needs and/or opportunities for business growth.

Market research can focus on simple demographics of an existing or potential customer group, defined by age, gender, geography, or income level. Customer research also seeks to understand customer behavior and motivation.

The goal is to understand who is – or will be – using a product as well as the reasons behind their doing so and how they go about using it (including the contextual areas of “where” and “when”).

Customer research may be conducted via a variety of quantitative and qualitative methods, such as interviews, surveys, focus groups, and ethnographic field studies. It also commonly involves doing desk research of online reviews, forums, and social media to explore what customers are saying about a product.

Examples of customer research outcomes are:

  • Brand awareness analysis

  • Markets segmentation

  • Customer behavior modeling

  • Pricing strategies assessment

13.3.2. Jobs-To-Be-Done

The “job-to-be-done” framework was created by Harvard professor Clayton Christensen, in part as a reaction against conventional techniques that: “frame customers by attributes – using age ranges, race, marital status, and other categories that ultimately create products and entire categories too focused on what companies want to sell, rather than on what customers actually need” [Christensen 2016].

Jobs-to-be-done analysis complements classical market research techniques by shifting the focus from the customer to what the customer aspires to achieve in some context.

“Some products are better defined by the job they do than the customers they serve” [Traynor 2016]. This is in contrast to many kinds of business and requirements analysis that focus on identifying different user personas (e.g., 45-55 married woman with children in the house). The job-to-be-done framework advocates that “the job, not the customer, is the fundamental unit of analysis” and that customers “hire” products to do a certain job [Christensen 2016].

To apply the job-to-be-done approach, Des Traynor suggests filling in the blanks in the following:
People hire your product to do the job of ------— every --------— when ----------. The other applicants for this job are --------, --------, and --------, but your product will always get the job because of --------.

Understanding the alternatives that people have is key. It is possible that the job can be fulfilled in multiple ways. For example, people may want certain software to be run. This job can be undertaken through owning a computer (e.g., having a data center). It can also be managed by hiring someone else’s computer (e.g., using a cloud provider). Not being attentive and creative in thinking about the diverse ways jobs can be done places you at risk of disruption [DPBoK 2020].

13.4. Combining Product Discovery with Customer Research

“A lot of times, people don’t know what they want until you show it to them.” (attributed to Steve Jobs)

Product discovery is about defining products from an outside-in viewpoint. Experience mapping helps to articulate the product’s value proposition and discover its features, outcomes, and benefits. It combines customer research and product discovery.

13.4.1. Experience Mapping

Experience shall be considered holistically as the sum of all interactions between a customer or user and the enterprise. Experience maps are made of all the stories which, together, describe the end-to-end customer or user experience.

Each customer/user map is defined by:

  • A persona which represents the character subject of the story

  • A final outcome that results from the story

  • A chain of events, starting from an initial state of affairs to a conclusion (final outcome)

  • External participants who interact with the persona

In the insurance claim story below, the initial event is a car accident. The persona is Diana, the policy owner and driver. John is a participant with whom Diana had an accident. The final desired outcome is a repaired car. The events represented in Figure 31 are:

  • “Proof of Insurance (POI) Exchanged” between Diana and John

  • “First Notice of Loss (FNOL)” registered by Diana to the insurance company

  • “Loss Assessed”: set of interactions to determine the amount of loss or damages covered by the insurance policy

  • “Car Repaired”: set of interactions resulting in the car being repaired

  • “Claim Settled”: final event resulting in issuing a payment to the benefit of the car repair shop

fig-claim-events
Figure 31. Claim Experience Events

As much as possible, each event should be connected to an intermediate outcome that is necessary to reach the final outcome. All intermediate steps should be left out for clarity. Too often, detailed steps tend to pollute the problem space with solution concerns. For instance, the fulfillment/repair event could be described as such: Diana selects a repair appointment with a nearby repair shop; Diana’s car is picked up at her office for repair. Actually, the hidden product features are: car-repair shop selection (outcome: a car repair shop close to Diana’s home) and repair service organization (outcome: repaired car). There are different ways to achieve these outcomes, ranging from an automated selection of the provider to bringing the repaired car to Diana’s parking lot.

Each experience map is made of a set of touchpoints through which the persona interacts with the enterprise or with external parties; see Figure 32. Each touchpoint gives an opportunity to wrap product features that can provide valuable experience to users and make them more engaged and satisfied. The aspects of experience below shall be analyzed at each touchpoint:

  • Understanding the job-to-be-done

  • Products involved (goods or services)

  • Product features used

  • Pains and gains felt by customers at the touchpoint

  • Improvement opportunities based on customer insights

[fig-claim-experience-map
Figure 32. Claim Experience Map

A single event often involves several touchpoints. For instance, fulfillment and repair in the claim journey involves car-repair provider selection (outcome: a provider close to Diana’s home) and repair service organization (outcome: repaired car). Pain points or gains can be identified for each of the product features involved at a touchpoint. For instance, a long waiting time is only felt for the repair product feature but not for the service provider selection.

13.4.2. Goods Features

“Goods” includes all man and machine-made objects (artifacts), whether tangible or intangible, that are offered to clients. Goods expose features through which users interact. For instance, a word processor application provides editing and printing features; refrigerators provide storage and freezing features.

The experience or value of goods comes from clients directly acting upon features. Food is properly preserved (outcome) if it is stored at the right place (acted upon) in a fridge: eggs and butter in the door, vegetables in the vegetable tray, etc. People willing to have room temperature butter (job-to-be-done) may store it in the warmest part of the fridge.

The shared experience between providers and consumers is mediated by the functional form of goods (temperature) and the physical manifestations (various trays in the fridge) upon which clients act.

13.4.3. Service Features

“Service” is work done by one person or group that benefits another. A service involves at least two parties. One applies competence (a provider) and the other experiences an outcome (a consumer). For example, a taxi ride is a service used by a person to travel (outcome) and is delivered by a taxi driver (provider).

Clients delegate some acts to the provider to get the desired outcomes. Banks provide consumer-credit, which allows clients to defer payments. A mechanic fixes a car to provide the outcome of a repaired car. Barbers provide a haircut service, applying their competence to perform acts clients would otherwise have to perform for themselves.

Service features are the functionalities of a service. For example, beyond the basic car wash, a car cleaning service could also propose wheel cleaning or rust protection.

Service provision may include the mediation of some artifacts, such as an ATM machine used to retrieve cash. However, such artifacts are not goods per se but instruments used to provision the service.

13.4.4. Feature Outcomes and Benefits

A feature should not be confused with a service benefit. For example, for a few more dollars car washing companies offer to spray a solution on the vehicle’s exterior that washes off in short order. Given its lack of durability, this feature does not protect the car from rusting.

A better rust protection feature would include opening up body panels, door panels, getting under the hood and into trunk areas, and finally accessing the boxed areas of the vehicle frame or unibody construction. This improved feature delivers a lasting benefit but costs between $100 to $250 per vehicle.

A benefit is an outcome that a client or a user values. For example, spraying a solution on the vehicle exterior could deliver peace of mind (first benefit) to clients who do not know better. On the other hand, delivering true rust protection (second benefit) is valued by knowledgeable clients. Two equivalent product features (two types of rust protection) deliver results valued differently depending on the client’s knowledge. For example, spraying a solution on the vehicle will not deliver the peace-of-mind benefit to knowledgeable clients.

13.4.5. Digital Products: Connected Goods and Fingertip Services

Digital technologies have provided the ability to embed software in objects. They range from traditional ATM machines, connected wearables, connected cars, to healthcare devices.

When goods become connected, a direct experience can be established between providers and consumers beyond the mediation of users acting upon goods. Goods become agents through which consumers and providers can interact. Through sensors, connected goods provide a wealth of information to providers, with an increased ability to reach customers at various touchpoints. When service provision includes connected resources, these new mediating agents can enrich service delivery by offering self-care features. Services come closer to their consumers; they become fingertip services, bringing product features to sight: smart cars can learn about their passengers to provide tailored entertainment experiences, smart locks can open based on face recognition, smart lighting can adjust brightness and colour hue based on both the weather outside and the user’s mood.

13.4.6. Quality Properties: The “ilities” of Products

Product features and their outcomes are not completely defined until measurable properties are specified. Altogether, they help define the purpose of products. Purposes shall not be confused with objectives or goals. For instance, the purpose of a chair (its main feature) is sitting. Chairs have other features such as the ability to be carried by a single person. Providing better sitting and/or easier lifting is setting improvement objectives. They do not change the purpose of the chair product.

The various quantitative and qualitative properties of product features are often named -ilities after the suffix most of the words share (availability, maintainability, scalability, etc.). The term “Non-Functional Requirements (NFRs)” is also used, but it is vague and belongs to traditional requirement-driven approaches.

A quality property is a measurable, testable, and experienceable property that indicates how well a product feature and/or its outcome satisfies customers in a specific usage context.

Wikipedia records a plethora of quality properties [Wikipedia®] and academia has defined multiple taxonomies over the years, including a couple of ISO Standards such as ISO/IEC 9126 [ISO/IEC 9126-1:2001] and ISO/IEC 25010 [ISO/IEC 25010:2011]. While many of these taxonomies are related to software quality properties, many of them apply to any product. Among all quality properties, Don Norman [Norman 2013] identifies three main kinds that matter for product experience:

  • Discoverability: the product must be self-explanatory – the user should be able to discover what actions are possible and how to perform them

  • Understandability: users must be able to understand how the product is supposed to be used, and what all the features mean

  • Usability: how easy and pleasant product features are to use

There are many other quality properties and each discipline has a different perspective: products have to be reliable, attractive, safe, etc. All of the quality properties may look crucial, but some tend to have a negative influence on others. For instance, maximizing maintainability may lead to a sacrifice in efficiency; increased reliability may have a negative effect on performance or usability. A study from Professor De Weck at the MIT [De Weck 2016] reveals a highly-connected network of quality properties. Further discussion of some of this area is included in Section 21.4.

13.5. Example: Ride-Hailing Company

Note

This fictional example is presented here for illustrative purposes only, to support the text and to enable a clearer understanding for the reader.

Ride-Hailing Company provides the features below:

  • Geolocation: live tracking, positioning, map display, routing

  • Ride management: instant ride request, scheduled ride request, rider/driver matching process, driver notification of request, acceptance, rider notification, driver rating by rider/rider rating by driver

  • Pricing: price estimation, surge pricing of ride request, fixed price, fare splitting, wait time fees, tips management

  • Cashless payment: card registration, in-app card payment, receipt

  • Driver administration: driver registration, driver profiling, status, payment and transaction history, ride history, vehicle management, earning report

  • Rider administration: rider registration, rider profile, payment and receipt history, ride history, SOS, promotion and loyalty program

  • Generic features: notification, internationalization (i18n), multiple currency, SMS verification, authentication

This list of features does not say much about the benefits that riders and drivers experience. The major benefit for riders is to get a ride with minimum waiting time at a reasonable price. The major benefit for drivers is to maximize revenue while minimizing idle time. The relationships that link features to benefits are indirect and require an understanding of the system as a whole.

The business model of Ride-Hailing Company is based on a two-sided market platform. One side of the market caters to riders who need transportation. The other side of the market caters to drivers who need to earn money.

The value to each of its participants grows the more people use the service [Parker 2016]. Ride-Hailing Company’s network effect is captured in Figure 33.

fig-uber-network-effect
Figure 33. Ride-Hailing Company Network Effect

Ride-Hailing Company has to balance rider demand with driver capacity, and needs to motivate drivers so enough of them show up at pickup time, otherwise riders have to wait too long.

The interest of the drivers is not aligned with that of the rider. The more drivers, the less waiting time for riders but the more idle time for drivers.

Behavioral science has shown how drivers can be subtly influenced to act against their own interests through the employment of social scientists and data scientists who experiment “with video game techniques, graphics, and non-cash rewards of little value that can prod drivers into working longer and harder – and sometimes at hours and locations that are less lucrative for them” [Scheiber 2017].

This example epitomizes the complex relations that can link features to outcomes. Just adding new features or managing a feature backlog does not guarantee success. Instead of prioritizing features, a competent product manager should prioritize outcomes. This implies shifting from a product owner role toward a product manager role, as described in Section 12.4.1.

Of course, the experience delivered by features can be enhanced by “killer” User Experience (UX) ideas; for example, see Figure 34. However, what used to be a killer UX is no longer differentiating. For example, several online services now include an equivalent UX to track delivery. Enjoying a lasting competitive advantage requires much more than adding features and flashy user interfaces to a service that is undergoing continuous evolution.

Finally, without also considering the “ilities” of the product, drivers and riders may quickly tire of the service due to poor performance and/or availability. One mechanism to ensure these are always being considered is through the use of Fitness Functions, as described in Section 6.3.2.

fig-uber-ux
Figure 34. UX Example