When your organization’s goal is to differentiate on the experience, you must start every product-development project by defining the experience that you want people to have with your product or service. Companies that differentiate on the experience do not begin by defining feature sets. They first define a vision for the experience outcome that they intend to deliver to their users and customers. Only once your team fully understands the experience outcomes that you want users to have can you make good decisions about what features and technologies would optimally support that vision.
This is the fourth column in our series about what companies must do if they want to stop producing average user experiences and instead design great experiences. As we have already stated in our previous columns, great UX teams focus on differentiating their companies through design. If that’s your goal, you need to work for a company that shares your aspirations.
Champion Advertisement
Continue Reading…
When we say that companies must start by envisioning experience outcomes, we mean that you must take the time and do the work to set a clear and worthy vision for your product or service—one that will delight your users and customers. Isn’t it the same with anything in life? Don’t we first have to have a vision for the outcome we want to achieve, whatever it is? Have you ever heard the story about two pilots flying an airplane, when one pilot asks, “Where are we going?” and the other replies, “I don’t know, but we’re getting there really fast!” This reminds us of what often happens on agile projects when teams understand their short-term, narrowly focused goals, but have no conception about what the big picture should be or whether their product will really deliver value to users. Unfortunately, teams often abdicate their responsibility for the experience outcome. When that happens, the result is a poor user experience.
Nevertheless, the goal of envisioning experience outcomes does not stand at odds with agile methods. It just means that you need to take a bit of time at the beginning of a project to look at the problem you’re trying to solve holistically, so you can understand where you’re going. Many teams call this Sprint 0. When teams start working on sprints in earnest, they don’t need to know every detail about the final outcome—they can refine their concepts as they go—but they do need a reference point against which to assess all of their decisions. That’s the experience outcome.
Still, we don’t want to focus too much on trying to achieve experience outcomes within an agile development context, because, in our view, agile is a less than optimal development model. It was conceived to meet the needs of developers, doesn’t take the UX research and design process into account at all, and presents too many obstacles to producing great experiences. Today, both of us prefer the more user-centered Lean Startup and Lean UX approaches, which are even more nimble than agile.
Defining Clear Goals
Crafting an experience outcome means first developing a deep understanding of the ultimate experience toward which you’re aiming. The goal in defining any experience outcome should be to deliver an innovative or much improved user experience for a product’s key capabilities. However, during each development iteration, as your understanding grows, your team can potentially improve on the experience outcome that you originally conceived.
Let’s take Visual Voicemail as an example. Once a team had defined its experience outcome—as letting users tap their screen just once to listen to any voicemail message—they would never expect users to go back to the old method of dialing their number, entering a password, waiting 45 seconds, listening to each message, and interacting with each one in sequence. Instead, they would try to improve on their vision for Visual Voicemail during each sprint.
Too often, teams define features and technologies for a product, without understanding their goals for its user experience. As we pointed out in our first column in this series, it’s important to remember that research has proven companies that differentiate on the experience outperform their counterparts by over 200%. Any company that wants to differentiate on the experience must define a product’s intended experience outcome first, then define its features and technologies to support that experience outcome. Back in 2007, Bruce Temkin of Forrester Research told us that, for companies to create experience-based differentiation, they need to obsess about user and customer needs, not features. Why haven’t more organizations learned how to do this?
Some Examples of Differentiated Experience Outcomes
Now, let’s look at some examples of companies that deeply understand the value of envisioning highly differentiated experience outcomes.
Uber and Lyft
Both Uber and Lyft first defined their intended experience outcome, then designed a solution that is usable, useful, and creates positive emotional engagement. The total experience—not just the app—has inspired customers who would otherwise have had to rely on a stodgy taxi system that has not changed for more than 80 years to try something new. Because their goal was to increase engagement, the Uber team decided that a critical experience outcome was to make the sign-up process not only easy, but also cool. For customers to add a credit card to the system, instead of having to type a card number, they just hold their card up behind the phone’s camera. The smartphone captures a photo of the card, and the app automatically adds all of the credit card information. No typing is necessary and signup takes only a few seconds, delighting users, who think “Wow, what a super-smooth experience! I want to see what else they have going.” Achieving this solution required the multidisciplinary effort of Engineering, Product Management, and User Experience.
The experience outcomes that Uber and Lyft defined also included removing bottlenecks that reduced user engagement at every step. Once Uber realized that they needed to simplify the signup process, they had to build software that communicated with a smartphone’s camera, enabling them to read the credit card information. This is where they confronted the biggest challenge: Many companies would allow or even encourage their teams to say, “Time to market is critical. Users can enter their credit card information themselves. Let’s drop that credit card–reader feature, so we can add more features,” thus, sacrificing an important experience outcome.
In contrast, companies differentiating on the experience understand that delivering more features faster is not the goal. When defining experience outcomes, the goal is to get each feature right, so users love your product. By defining the experience outcomes first, teams gain insights into the impacts of any compromises to the experience. In the cases of Uber and Lyft, both companies understood that signup was a choke point for users. If they didn’t remove this hurdle, they would lose a significant percentage of potential customers. So they didn’t merely simplify the experience. Instead, they leveraged the signup process to create positive emotional engagement, making users smile and say, “This is awesome!” Again, this means thinking about the total experience, not just the experience of an isolated feature—or even just of the app itself. Uber and Lyft applied this principle to their entire product and service experience.
Of course, teams typically must find some areas where they can compromise. They can never ship every feature they think of. Developing the product would take forever. So teams must decide which features are critical and which are not. Unfortunately, product teams often ship feature-rich products rather than products that have great user experiences.
For example, when Jim worked in the Advertising group at Yahoo!, product managers were famous for thinking up new features that nobody ever used. If they had instead focused on experience outcomes and making the features that they developed indispensable to users—an adjective they loved to use—Google would have had a harder time winning the search business, and Yahoo! would never have needed to sell their search marketing business to Microsoft. Once you define a product’s experience outcomes, you can evaluate all proposed features relative to those experience outcomes.
The Lean Startup movement has given us the concept of a Minimum Viable Product. However, recently, there has been a bit of a backlash against that term for setting the bar too low. So UX design luminary Larry Tesler has suggested a new term: Minimum Lovable Product, which suggests that product teams should define the few essential features and implement them very, very well, so users will love the resulting product or service.
Later, we’ll talk about how you can define experience outcomes up front, as well as describe some techniques that will let you define experience outcomes in minutes. But, first, let’s consider an example from Apple.
Apple
When Apple produced the first iPhone, they did just what we’re talking about here: they built very few features, but implemented them very, very well. When Apple was about to launch the first version of the iPhone, its SMS texting feature did not meet the team’s minimal intended experience. So, rather than release a substandard user experience, they launched the iPhone without SMS. Later on, once the SMS feature met their expectations for its experience, they added it in a software update. Did customers hate the iPhone because it had one less feature? Just the opposite: They loved the experience and forgave the lack of functionality.
So many product managers today feel pressured to get features out the door fast, regardless of whether the features are actually useful and well designed. Companies must realize that good product strategy is not about just shipping lots of features. You must deliver the right features, with the right user experience, so users will actually use them and even love them. Any features that you release to market should first satisfy whatever minimal experience your team has defined. Until you accomplish that, those features are simply not ready for release. Great experiences sell.
Because users felt an emotional connection with the first iPhone and its subsequent versions, Apple was able to open and sustain an entirely new market for smartphones. Sure, other companies have followed their lead, but Apple has set the precedent, so companies that are successful in the smartphone industry do not compromise on the user experience.
Unfortunately, most companies get this wrong. They include more and more features, bloating their products with useless, poorly designed features and compromising their user experience.
A Strategic Triad: Product Management, User Experience, and Engineering
The points we’ve made so far beg an important question: how can you define your intended experience outcome at the beginning of a project if User Experience does not have a role in defining product strategy? You can’t, and the entire project will suffer as a result.
Working in close collaboration with core team members from Product Management and Engineering, User Experience should play a key role in the early stages of a product development project, adding value through generative user research, envisioning, ideation, requirements definition, and strategy. All of these contribute to the definition of a successful experience outcome.
We know that, in companies that differentiate on the experience, Product Management, User Experience, and Engineering form a strategic triad—a cross-functional team that defines product strategy—and User Experience owns the ultimate user experience. Since Pabini has previously explored this topic in depth in her UXmatters article “Sharing Ownership of UX,” we’ll just touch on this briefly here.
As Marty Cagan points out in Inspired: How to Build Products Customers Love, having disciplines other than or in addition to Product Management, User Experience, and Engineering involved in decision making around product strategy is a certain way to decrease the effectiveness of the resulting product. Defining strategy requires a small, cross-functional, core team of highly entrepreneurial experts in each of these disciplines. Thus, the team defining strategy must always include Product Management, User Experience, and Engineering—and only these roles.
Unfortunately, today, many companies do not differentiate on design. Typically, there is a poor balance of power in such companies: Product Management may believe that they should own all strategic decisions. Or Engineering may push back on a UX vision because they either do not know how to implement a design solution or think it would take too much time. Of course, time translates to cost, and cost is always a valid issue. But what is the potential value of the experience outcome versus that cost? Is the experience outcome worth the cost? Our primary point here is that what we refer to as the strategic triad, or core team, should work on making such decisions jointly. Then, even if one of them has to take a decision because the team can’t reach consensus, they’ll be making a well-informed decision. Otherwise, a compromised and diminished user experience would result, making it impossible to differentiate on the experience.
Once the strategic triad defines the intended experience outcome, it is the job of Engineering to find a way to implement its critical capabilities and build the product exactly as designed. If front-end development resides on the UX team, as it ideally should, it becomes easier to achieve that goal—as Jim highlighted in a previous column, “Great User Experiences Require Great Front-End Development.” Nonetheless, an application’s back-end implementation and performance also have a huge impact on the user experience.
Let’s briefly consider another context in which creative teams define the intended experience outcome first: creative studios such as Pixar, DreamWorks, and Lucasfilm. The need to realize the profoundly new experiences that their creative directors envision has driven their technical disciplines in ways that have pushed them far beyond what they initially thought possible. Their engineers have achieved feats of technical wizardry that the typical engineer in a product development corporation might say would be impossible. In such contexts, creative directors work with a cross-functional team to envision an experience outcome. Achieving the intended, highly differentiated experience often requires innovation—and, thus, a greater initial investment of time and money in a project—but it also creates significantly more value for customers and, in turn, the creative studio and its shareholders. Differentiation is all about value creation.
In companies that differentiate on the experience and care about the user’s or customer’s ultimate experience, designers visualize the desired experience first and only then does Engineering take on the challenge of supporting the experience technologically. In such a company, the entire core team is aligned on the intended experience outcome before coding begins, so it would be unthinkable for an engineer to redesign a user interface to his own liking or suggest compromises that would result in an average, undifferentiated design.
Defining Intended Experience Outcomes Using Journey Maps
An intended experience outcome for a new product or service that you’re creating may be simple or complex, but defining one requires that your core team identify the most challenging parts of the ecosystem within which it will exist at the very outset of the project. You can define the entire user or customer journey for a product or service by creating a journey map. Journey maps are a great way of visualizing experience outcomes.
Teams creating journey maps must start with user research that enables them to understand users’ or customers’ needs and identify their painpoints and challenges. If you are about to redesign an existing system, map every touchpoint in the current system, noting any roadblocks to user success or missed opportunities to delight users. Then map a re-envisioned journey that removes those roadblocks and leverages those opportunities. By leading cross-functional teams in abductive thinking, User Experience can identify potentially unique and delightful solutions that satisfy users’ previously unmet and possibly even unstated or unconscious needs.
Journey Mapping a Travel Ecosystem
Here’s an example of a project on which Jim used journey mapping in a very specific way. His UX team worked cross-functionally with Product Management and Engineering to define a future product in the travel space. Their goal was twofold: Identify a solution that they could deliver by 2020, and build its components incrementally, along the way. This solution needed to increase customer loyalty, delight users, and drive revenues for both Jim’s company and the many different companies making up the total travel ecosystem.
Based on their initial user research, the team created a persona, Candice, who lives in Los Angeles. In one scenario, Candice’s boss called her on a Tuesday and informed her that she needed to be in New York City on the following Monday to meet with a customer. The cross-functional team worked together to define the intended experience outcome at each step in Candice’s journey. They identified a new product concept that they called the Travel Buddy to help illustrate their desired experience outcome. Their total solution would comprise tools for travel-booking companies, airlines, airport authorities, rental-car companies, hotels, and other companies in the total travel value chain. It would result in an improved user experience and increased customer loyalty and earn significant revenues for all of the companies in the travel ecosystem.
The cross-functional team created a journey map that provided a visualization of the entire suite of products that they needed to define and build, but depicted very few details about any of those products. Figure 1 shows the original journey map for this experience. The team designed the journey map for large-format printing, so they could look at the total flow from end to end. However, for publication on UXmatters, we’ve split the map into four separate images.
Figure 1—Mapping the total customer journey, steps 1–3 Figure 2—Mapping the total customer journey, steps 4–6 Figure 3—Mapping the total customer journey, steps 7–9 Figure 4—Mapping the total customer journey, steps 10–12
The key point of this story is that Jim’s cross-functional team worked collaboratively to define a possible experience outcome. The UX team then created this high-level visualization of the journey map depicting that experience. The cross-functional team reviewed and helped to iterate the journey map. Next, the strategic triad of Product Management, User Experience, and Engineering would define each of the products in this map, highlighting both the minimum lovable features and the technologies that would support the intended experience outcome.
Conclusion
When you first define the vision for a product’s or service’s intended experience outcome through journey mapping, your product team will be able to achieve clarity on that product’s eventual experience early in the product development cycle. This will enable you to truly differentiate on the experience. Regardless of the product development process that your company follows, your UX team can help start a dialogue about your product’s intended experience outcomes among the members of your multidisciplinary product team. If you need other examples or have questions, please let us know in the comments.
Resources on Customer Journey Mapping
Check out these resources if you want to learn more about journey mapping.
“Customer Journey Mapping: Illustrating the Big Picture,” in “UX STRAT 2013 Workshop Reviews,” Margie Coles’s review of Megan Grocki’s workshop at UX STRAT 2013.
Bruce Temkin’s extensive writings on journey mapping include the following:
Great article. I’ll have to look more into the journey mapping because, from a high level, journey maps don’t seem to take into account all possible outcomes or challenges. The example in this article is very happy path and not very realistic. For example, why include the possibility of the flight being cancelled when so much more could go wrong. The limo might be double booked; the limo might get a flat tire; there might be a parade closing the road that the limo takes to the destination; the flight might be delayed. What if TSA is completely backed up or they have an emergency?
I guess I think that system maps might always be a better solution. You can map out the touchpoints rather than some hypothetical future journey. When mapping touchpoints, you can also take into account the different scenarios that relate to each touchpoint, thus preparing for general edge cases and negative events that cover a wide range of possible incidents. I’d list all the possibilities of hindrance at each event or touchpoint and devise a high-level solution to take care of those challenges rather than focus specifically on one like this example. I’d also have to have several other actors and systems to show how the all interact together and influence each other—for example, other people that communicate with her, staff, public, officials, technology stack, electronic needs, fetches to database, battery power, backup power, and communication channels.
Chief User Experience Strategist at Experience Outcomes
Los Altos, California, USA
A design leader for 17 years, Jim loves every minute of helping companies create competitive advantage by designing experiences that differentiate. He has worked with a range of companies—from startups to Fortune-500 companies—most recently as Senior VP of Customer Engagement at Monaker Group. He previously led User Experience at HP, Yahoo, and Cisco and has advised numerous startups. Jim chooses to work with brilliant clients, helping them unlock their unbounded potential by envisioning and designing end-to-end experiences that disrupt markets and engaging users emotionally. He often works with UX leaders to help them work through organizational challenges and ensure User Experience has the visibility it deserves and can design experiences that make the team proud. Jim also conducts design-value assessments for his clients, identifying gaps in their ability to differentiate on the experience, then helping them close those gaps and become extraordinary. Read More
Founder, Publisher, and Editor in Chief of UXmatters
Silicon Valley, California, USA
With more than 20 years working in User Experience at companies such as Google, Cisco, WebEx, Apple, and many startups, Pabini now provides UX strategy and design consulting services through her Silicon Valley company, Strategic UX. Her past UX leadership roles include Head of UX for Sales & Marketing IT at Intel, Senior Director of UX and Design at Apttus, Principal UX Architect at BMC Software, VP of User Experience at scanR, and Manager of User Experience at WebEx. Pabini has led UX strategy, design, and user research for Web, mobile, and desktop applications for consumers, small businesses, and enterprises, in diverse product domains. Working collaboratively with business executives, multidisciplinary product teams, and UX teams, she has envisioned and realized holistic UX design solutions for innovative, award-winning products that delighted users, achieved success in the marketplace, and delivered business value. As a UX leader, she has facilitated conceptual modeling and ideation sessions; written user stories; prioritized product and usability requirements; established corporate design frameworks, standards, and guidelines; and integrated lean UX activities into agile development processes. Pabini is a strategic thinker, and the diversity of her experience enables her to synthesize innovative solutions for challenging strategy and design problems. She is passionate about creating great user experiences that meet users’ needs and get business results. A thought leader in the UX community, Pabini was a Founding Director of the Interaction Design Association (IxDA). Read More
