Scenario-Focused Engineering (2014)
Part I: Overview
CHAPTER 1 Why delight matters
CHAPTER 2 End-to-end experiences, not features
CHAPTER 3 Take an experimental approach
Chapter 2. End-to-end experiences, not features
Emotional delight truly matters in getting the attention of customers in today’s rapidly maturing technology market. The key to achieving a much deeper sense of connection and delight with a customer is to understand and satisfy the customer’s real-world needs, which are inherently complex and multifaceted. To do that, you must focus on building end-to-end experiences, not individual features.1
What’s wrong with features?
It’s common to see a software team start a project with a list of features. To engineers, this may feel like a natural process—to approach a problem by first doing some data analysis (market, customer, competitive, and so on), and from that analysis generate a list of requirements, which is used to create a set of features that is expected to meet those requirements. The team then prioritizes those features by using some criteria (relative importance, cost to implement, risk), draws a cut line based on budget, and begins to build in priority order. That’s simple enough, right?
But customers don’t see the world that way. Customers have specific problems in specific contexts, and guess what, they just want their problems solved. The trouble is that technology is everywhere these days, so it is natural for a customer’s real-life needs to require many pieces of technology just to get a simple task accomplished. Customers don’t care whether a solution to their problem happens to cross organizational, architectural, or competitor boundaries—they just want the solution to work smoothly and seamlessly. Nor do they have patience for one-size-fits-all solutions—increasingly, customers expect products to meet them where they are and don’t want to adapt their habits and reshape their mental model to match what the software happens to be able to do.
For example, let’s say Ed wants to send a photo that he sees on his friend’s Facebook wall to his sister in Germany who only has email. He expects that to be easily possible, in just one or two clicks, and will be frustrated if it isn’t. Or consider Jeanine, who needs to book a business trip to Detroit and align her travel plans with a colleague who is also going to be in Detroit at the same time. She hopes that they can see each other’s travel plans and arrange to sit next to each other on their shared flight home. Imagine how relieved and delighted she feels, having worried that the coordination might be awkward, when she learns that it was easy to arrange and is confident that it was all done correctly. Or consider Kent, who is collaborating on a research paper with three classmates, and the group needs to share their ideas, author the text, review their work with one another, and hand in a single document to their professor. A feature for emailing documents back and forth doesn’t cut it anymore if what Kent really needs is a great tool set to support ongoing collaboration.
Even 10 years ago, customers didn’t have the expectation that complete, ready-made solutions like these were possible. It used to be that our industry primarily built standalone products, and marketing campaigns focused on which feature list was longer. But as the shift to online services has intensified, it has both enabled and encouraged end-to-end solutions that aren’t tied to just one piece of software sold in a box. With the advent of apps and services like Evernote, Dropbox, Salesforce.com, Zipcar, Nest, and countless others that continually push the boundaries of what is possible, people are expecting much more from technology. The startup market is vibrant and barriers to entry are low. If your solution doesn’t support a customer’s real-world, end-to-end needs, you can bet a competitor’s will soon enough.
Of course, you will still build features as part of your product-development process. But you want to avoid building islands of individual features that don’t interrelate with each other. To do that, you need to use your understanding of customer needs to determine which complete solutions you can build that stitch those features together to solve end-to-end problems. Individual features aren’t bad; they’re just too small in scope to address real-life usage scenarios. You need a bigger construct to capture the essence of your customer’s situation.
Mindshift
Seamless experiences, not just integration. You might be tempted to think about this bigger construct as the need for integration across all parts of your system. But while you will almost definitely do some integration work, don’t think of integration itself as the goal. The goal is to create a seamless experience for the customer. To achieve that, you will likely need to do some integration across your products, services, devices, and possibly with external partners or even competitors. But integrating with everyone and everything you can think of probably isn’t the right approach.
For example, integrating your new photo-sharing service with every possible email service is a noble undertaking, but from your target customers’ perspective, all they care about is the one email service they actually use. Your time may be better spent doing really tight, seamless integration with a few of the biggest email systems to cover the bulk of your target customer base.
Consider that when Nest started building a next-generation thermostat, the company explicitly chose to not interface with every kind of heating system; however, the ones they did support, they served extremely well. Then, over time, they broadened support to include more types of systems, but only if they could be sure of a high-quality end-to-end experience. The point is not integration for integration’s sake, but to figure out which integration scenarios are most important for delivering a seamless, complete solution that solves your target customers’ real-life needs.
Think end to end
A great way to think about building complete, seamless solutions is to think of the end-to-end experience that your solution enables. What is the customer’s total experience with your solution, and how well does that experience match his or her needs and expectations?
Vocab
An end-to-end experience is what the customer sees, feels, and does when he or she uses your product, device, or service in a real-life situation, from the very beginning to the very end.
A customer’s end-to-end experience may be short and straightforward, such as a teenager reading a text message from a friend while standing in line at the grocery store, a developer writing a few lines of code to fix a bug, or an event planner sending an email to advertise a charity auction. An end-to-end experience can also have many moving parts and be quite complex, such as an event planner using a database, spreadsheets, email, online meetings, mobile phone, and word processor to organize and put on a charity auction event; or a software developer on a project team who uses bug-tracking tools, source control, API documentation, and a development environment to fix a bug, check it in, and mark it fixed. Or consider a teenager who buys a piece of music online and wants to listen to it and the rest of his music library first on his phone, later on his laptop, and again in the evening as background music in the living room as he plays his favorite Xbox game.
But what most assuredly is not an end-to-end experience is someone changing the view of his or her Word document from Draft to Print Layout. Clicking the button to buy an app in the Apple App Store is not an end-to-end experience either; the total purchase experience must include how that app is discovered, chosen, and then made available to use on the customer’s devices. Individual actions like these are too small in scope to capture the essence of a customer’s real-life usage situation; they are a part of a larger customer scenario.
However, these examples do illustrate that you can consider potentially multiple scopes of the same experience. You can zoom out to see the larger, end-to-end job being done, or you can zoom in to focus on a specific end-to-end task—but be careful that you don’t zoom in so far that you no longer see the customer’s real-life situation, context, and motivations. The important step is to align your perspective with the way the customer perceives the task at hand. If the customer sees it all as one connected job—or really wishes it could be all connected—then you should be thinking about it that way also. Zooming out to consider the larger job the customer is undertaking can help you see customer needs and identify opportunities for delight that you may not have noticed otherwise (and that your customer may not have considered either).
As the technology industry has matured, customers have also come to expect their experiences to flow seamlessly at larger and larger scopes. They want their end-to-end experience to hang together across their entire job, not just individual tasks. As more products and services deliver on this promise, this trend of rising customer expectations will only intensify.
What job is your product actually doing?
Harvard Business School professor Clayton Christensen, author of The Innovator’s Dilemma, tells an insightful story about the need to zoom out to uncover a customer’s actual end-to-end experience, which may not match what you initially thought.2 The story conveys an important lesson about not assuming that you know what’s going on in the customer’s head and is particularly surprising because it’s about people buying milk shakes. I mean, how complicated could the experience of buying a simple milk shake possibly be?
Christensen tells about a company he worked with that wanted to improve sales of their milkshakes. They did all the usual demographics research of their current customers, and even sat down with individual customers to ask their preferences about flavor, texture, and other qualities. However, none of the changes inspired by this research improved sales one bit.
It was only when the company noticed the curious fact that nearly half of its milkshakes were sold during the morning commute that its customers’ true end-to-end experience was revealed. It turned out that those milkshakes were being purchased by commuters who wanted a distraction during a boring drive. They needed something that they could handle in the car with one hand, with no mess, and would stave off their 10:00 a.m. hunger pangs. Christensen talks about this as understanding what “job” the customer is “hiring” your product to do. In this case, the job didn’t have anything to do with milkshakes per se, it was much more about spicing up the morning commuting experience with the simultaneous constraint of needing to drive a car.
Armed with that insight, you might decide to make those morning milkshakes a bit thicker so that they take longer to drink, maybe throw in some bits of fruit for extra excitement, and certainly make sure they fit well in cup holders. And conversely, milkshakes sold in the afternoon to parents who are trying to placate their kids should probably be smoother and thinner so that the kids can easily gulp their treat through a straw and not take forever to finish.
Understanding a customer’s true end-to-end experience requires insight into the customer’s motivations and overall situation. Obtaining this insight requires you to zoom out to look beyond the immediate task at hand. With that understanding, new ideas for how to make a truly delightful experience for the customer become more apparent. This is true not just for milkshakes but for software as well.
For instance, you would optimize online credit card payments quite differently if you knew that instead of one-time purchases, the dominant usage pattern was for a customer to make several small purchases in quick succession as she browsed app listings looking for good games to try. This would allow you to minimize per-transaction fees and provide the user with a single, unified bill.
A customer’s end-to-end experience with your product or service is deeply rooted in the real-life environment, situation, and motivation that surrounds its use. However, representing this all-important situational context is tough, with even the crispest list of requirements or features. Nor is it possible to enumerate every possible customer situation a product might need to address—that list is too long and unwieldy. You need some new tools and new ways of thinking to enable this kind of end-to-end approach.
Optimizing features doesn’t make an experience
Around 2001, Procter & Gamble (P&G for short), the makers of products such as Pampers, Tide, and Oil of Olay, came to the realization that it needed to spend a lot more time understanding customers’ real-world usage patterns, whether that was how families managed their laundry over the course of a week, how women chose skin-care products, or how parents of newborns approached diapering. However, the idea that an overall experience and the general aesthetics mattered more than any individual feature was a tough one for the company’s more technically minded employees to grok.
Claudia Kotchka, the company’s vice president of design innovation and strategy, would often tell a story about a hypothetical exercise to fold a competing brand, Altoids breath mints, into P&G’s product line.3 In the story, she shows the team a box of Altoids. She handles the old-fashioned tin with affection and opens it slowly. She wrinkles the paper inside and reveals a box of what look like old-fashioned homemade confectionaries, as the scent of 100 percent pure peppermint oil wafts through the room. She remarks that Altoids, with this old-time feel and great flavor, is able to charge a 400 percent price premium over its competitors.
She then asks the group of executives—as a thought experiment: What would they do with this product if P&G were to purchase the brand? The answers she got were almost always the same, regardless of audience—they would keep the 100 percent pure peppermint oil formula (taste tests show this is a clear winner), but replace the tin container (too expensive), remove the paper (serves no functional purpose), make the mints uniformly round (aids production, cleaner look and feel), and pack the mints tightly (optimize packaging—don’t ship air).
“Exactly!” she says. “And this is what you will get . . . Proctoids!”4 The room laughs as she reveals the new product packaging mockup, which utilizes a cheap white plastic container repurposed from P&G’s line of baby wipes. The container is packed tightly with uniform rows of beige balls reminiscent of bleached rabbit pellets and has no paper.
Even though the Proctoids taste great (they still have 100 percent pure peppermint oil), she asks the people in the room, “Would you pay a 4X premium for this product? Would you even want to put one of these in your mouth?”
After telling this story, Kotchka says the light bulbs would go off. “The difference between these two products,” says Kotchka, is that “while they both have 100 percent peppermint oil . . . the difference is design.”
Let’s step back and think about what’s really going on here. Each change the executives proposed was a reasonable, logical decision that optimized some aspect of the product or process. And while each of the suggested optimizations made sense—make the packaging less expensive, remove the paper because it serves no function, don’t ship air, pack the mints tightly, and so on—somehow, when they’re all added up, the magic is lost. The story illustrates that it’s quite possible to make a lot of sensible local optimizations and, in doing so, lose a meaningful end-to-end experience.
Mindshift
Big picture first, details later. Engineers are trained to look for the causes of problems, to break problems apart, to create abstraction layers, to compartmentalize, to fix issues at the root level, and then later reassemble the whole. This is also the approach that the engineers at P&G took when they thought about improving Altoids. But when designing for a great customer experience, and before you dive headlong into features, functionality, and requirements, you should be sure to broaden your approach and look at the end-to-end experience of your customers while they are using your product.
Take a few moments to consider your current team’s engineering culture and results. What kind of product or service does your team deliver today? Is it more like Altoids or Proctoids?
Less—it’s the new more
We’ve all heard this saying before: less is more. When you design for an end-to-end experience, the concept of using less to do more can be especially powerful. The reason is that it’s all too easy for “extra” features in a product to get in the way of the overall experience. Yet, the instinct of engineers is that more must be better—and you can always find a customer who is asking for this capability or that feature or this other alternative view.
Many times, however, having fewer features and less functionality actually makes for a better customer experience, creating the streamlined, simple, and straightforward experience that customers desire. Focusing on features—how many, which ones, relative priority, and so on—is an upside-down way of thinking. Remember that the features in your product should serve the experience, not the other way around. And when you put customers and their experience at the center of your focus, you will often find that less really is more.
Bump is a popular smartphone application that was introduced in March 2009 as a simple way to share contacts between smartphones by physically touching, or “bumping,” them together.5 People thought that was pretty cool, and Bump quickly became one of the more popular downloads in the iPhone App Store. Subsequent versions of Bump began to expand on that idea by adding features for sharing additional file types, photos, and recommendations for apps and music. In 2011, Bump’s CEO David Lieb said he ultimately wanted Bump to stand for “anything you want to do in the real world using your phone”—think near field communication (NFC), payments, and the like.6
But the Bump team started noticing that although customers would explore the different features of Bump, if they tried a feature that wasn’t particularly useful to them (such as sharing a music recommendation), the customers most likely wouldn’t return to the application at all. This data raised concerns and caused the team to make some tough decisions.
The team decided that it could get more customers to return by focusing on the few features that were being used the most. They decided to focus on those that seemed to have the most value to customers, that customers were actively using on a regular basis. As a result of this new strategy, the company made a drastic product change. It removed all extraneous features in the product and released Bump 3.0, which boasted a grand total of two features: the ability to exchange contact information with new acquaintances, and the ability to share photos with friends and family.
Before Bump 3.0 was released, the application had 75 million mobile-phone installations, but growth had stalled and the future looked uncertain. A year later, after Bump pared down to a simpler feature set, Bump had 125 million mobile-phone downloads and became one of the most popular programs in Apple’s online store. It seems they made a pretty good decision.7
Bump’s future was looking quite rosy. It won many awards, including Fast Company’s top 150 most innovative companies. So, perhaps it shouldn’t be a surprise that Bump was acquired by Google in 2013. Sadly, the service was shut down soon after and has not yet resurfaced in Google’s portfolio of services. We’re curious to see how and if it reappears.
Easy, seamless, pain free
Even if there is nothing really new, having an experience flow seamlessly from beginning to end truly matters. You don’t necessarily need to create some fancy new thing to win your customers’ love. Just stitch the pieces together so that the experience actually works end to end. That alone counts for a whole lot. Especially if along the way you can proactively solve the key pain points that customers are likely to encounter, turning what could be an emotional disaster into a pleasantly painless surprise.
Have you flown on Delta Airlines recently? I had the pleasure of flying on Delta last summer and happened to make a stop in Minneapolis-St. Paul, where Delta has installed hundreds of iPads in its lounges throughout the terminal.
The sea of iPads was an instant draw for my kids, and I have to admit that my interest was piqued as well. Each iPad had the Fly Delta app installed and running. Not only did the app provide access to a few games the kids occupied themselves with while we waited, it also showed real-time information about our gate, that there was a slight delay, and a preview of the weather at our destination. If you left it idle, it rotated a tantalizing, full-picture menu for a nearby airport café.
It was certainly a nice touch for an airport waiting area, but that was nothing compared with what I got by installing the Fly Delta app on my own device for my next trip. That’s when the experience really kicked in to high gear. The app handles the basics smoothly, allowing you to check in for your flight while you’re on the go in a taxi or in your hotel room. And as expected, it shows real-time updates about your flight and serves as your boarding pass by displaying a code that the gate attendant can scan.
On an uneventful trip, the Fly Delta app provides all the little bits of info that help you get through the airport more smoothly, without the hassles of needing to print out your boarding pass or having to find your flight while you stare at the list on an airport monitor. But the clincher is that the Fly Delta app manages the single most dreaded aspect of air travel: cancelled flights. If your flight gets canceled, the app will likely notify you before the loudspeaker does. And it provides a quick and easy way to switch to a new flight, right from the app, in just a few taps. No waiting in line with a hundred other angry passengers, no worrying about whether there will still be space on the next flight by the time you get to the front of the line, no harried airport employee to interact with.
That’s not rocket science. It’s not even new functionality per se. It’s actually a very simple, proactive solution to an age-old pain point. But Delta has clearly struck a nerve, and it’s a good one. And the company was the first one to do it.
You can find gobs and gobs of reviews of the Fly Delta app that report experiences like “Never have to keep track of a boarding pass ever again” and “A much easier way to stay on track when traveling” and “Gives me the best chances of getting an upgrade” and “My flight was canceled, but the app told me this before the announcement and rather than wait to talk to the folks at the desk, the app had me rebooked in two minutes! LOVE IT!” Dealing with a canceled flight is never fun, but this new approach exceeded customer expectations so dramatically that it actually delivered customer delight. Ironically, the app’s overall score is pulled down by consumer demand for this experience, with low-rated reviews that look like this: “Why isn’t this app available on <platform> yet, because I really want it.”
As a consumer, I hope that the other airlines don’t take too long to figure out how to replicate this experience, and for Delta to port its app to the other mobile platforms. This may not be a competitive differentiator forever, but for now Delta has managed to smooth out and simplify what historically can be a nerve-racking experience, and that is making a lot of customers very happy. Airline travel is hardly the only domain that could use some end-to-end smoothing and solving of pain points. There’s a lot to be gained just by pulling all the pieces together to provide an easy, seamless, hassle-free end-to-end experience.
Remember the ecosystem
Considering the larger ecosystem surrounding your solution is another way to make sure you’re covering the user’s complete experience. Often, after the initial purchase, the presence or absence of supporting elements makes the biggest difference in your customer’s experience of your product, and often these are elements that are not directly under your company’s control. Think about all the touch points a customer has with your solution. Does the customer interact with it via a single website, or are there third-party providers, retail partners, social media, and support channels the customer interacts with as well?
Let’s take a look at Amazon’s Kindle e-reader. It has an extensive customer experience that seamlessly integrates book publishers, public libraries, and application developers, in addition to what Amazon delivers with its device and retail website.
Most people’s experience with a Kindle goes way beyond just ordering the device on Amazon’s website. Sure, it starts with receiving a box in the mail, opening it, and reading a favorite book on a device with an amazing no-glare screen. But the end-to-end experience of using a Kindle goes much further. It also includes shopping for and downloading e-books, sometimes at a significant discount over conventional paper-based books, which required Amazon to develop special agreements with a multitude of publishers. Beyond those basics, Amazon considered a lot of other factors, too. How about the experience of reading reviews from other customers to help pick your next book to take on vacation? And if you like it, how do you recommend this e-book to someone else?
And how about being able to loan a book you’ve purchased to a friend so that she can read it, too? Oops, perhaps you’ve already loaned the book to someone else, but maybe your friend can check out the e-book from the local library? How does that work; are there partnerships between Amazon and the public library system? Who writes that library application, and what is that experience like? Is it easy to borrow an e-book from the library? What if I want to read an e-book on a different computer? Is it possible to do something else with a Kindle other than read books? Can I play games on a Kindle like I can on an iPad? If so, are the games any good? Are developers writing for this platform? How easy is it for a developer to get an application into the Kindle store?
It turns out that Amazon has steadily, over time, answered all of these questions and has built a powerful ecosystem around its popular Kindle reader to enable a complete user experience. That ecosystem goes beyond the walls of Amazon and involves book publishers, public libraries, and application developers. Not only is that ecosystem a powerful competitive advantage because it is so difficult for a competitor to replicate, but it also provides an incredibly smooth experience for customers. It’s worth noting that Amazon is the top-rated technology company in Forrester’s 2012 customer experience index, above even Apple.8
As you think about end-to-end experiences, don’t think only about the one piece that your team delivers. Chances are that customers expect that piece to interface naturally with the rest of their lives as well, and that’s going to require you to integrate with entities outside your company.Making all those interfaces smooth and seamless is just as important a part of your job as getting your part of the experience done to a high degree of quality.
Cradle to grave
Another way to think about an end-to-end experience is to think about the customer’s experience over a longer period of time, from cradle to grave. That is, don’t think just about the use of a device itself, also consider how the customer first heard about that device, how he purchased it, how he installed it, and what the first-run experience was like. And then think about what the support experience is like in the event of a problem, what happens when the device finally dies, and how the customer eventually replaces it. Zooming out to consider the complete cradle-to-grave experience over time is another way to spot customer needs and opportunities for delight that you may not notice otherwise.
Here’s an example of applying cradle-to-grave thinking in a service business.
Amtrak hired the design consultancy IDEO and branding consultants OH&Co to help reimagine the Acela high-speed train route between Boston and Washington, DC, in an attempt to differentiate it from airline travel.9 Imagine taking on that design challenge. Your first instinct might be to think about the train cabin experience—more comfortable seats, power outlets for business travelers, delicious food, sophisticated ambiance. This was Amtrak’s first instinct as well.
Surprisingly, however, what the team found was that the customer’s complete experience with train travel had 10 distinct steps, only one of which was riding on the train itself. The other steps happened before and after riding on the train—purchasing tickets, checking in, boarding, and collecting baggage had a significant impact on the total customer experience. In fact, these other areas were the ripest for making significant leaps forward; the cabin experience itself was secondary.
Toward that end, the team built a 60-foot-long walk-through prototype that served as a physical, tangible tool for thinking through the experience across all the steps of the customer’s train experience. In the end, the team did create innovative train interiors, but it found that this aspect alone was not enough to deliver a great overall experience. It also designed station layouts, signage, and systems for handling ticketing and luggage, which together created an outstanding end-to-end experience for customers. Amtrak posted a tremendous increase in ridership and satisfaction, reaching one million riders of the new Acela line in less than a year, well ahead of its projections.10
Is it always necessary to consider the complete cradle-to-grave experience to have a successful product? No, sometimes it’s fine to look more narrowly. But make that an intentional decision, consider the maturity of your particular market, and vet that decision with your competitive strategy. The last thing you want is a competitor who pops up and solves the entire cradle-to-grave scenario, making your solution look weak in comparison because you addressed only a piece of it.
Getting the details right
It is this sort of end-to-end thinking that leads you to consider not only the software experience for your service but also the specifics of the hardware it runs on. You would think not only about marketing but about where your device is placed on retail shelves and how it looks next to your competitor’s product. You’d think about packaging for sales appeal and also about how that packaging might create a sense of anticipation when it is first opened. You’d think not only about whether all of the error conditions are covered but about how friendly the tone of voice is throughout the user interface. You’d think about performance and latency to ensure that the customer’s perceived experience feels fast and fluid. In short, you’d think about how every aspect of your product could possibly affect the customer’s end-to-end experience.
It turns out that considering these various aspects of the experience, and getting the details right, is what makes for a high-quality end-to-end experience for your customers. The vast majority of customers have no knowledge of the level of engineering quality under the hood. The elegance of the architecture, the efficiency of the algorithms, and the maintainability of the codebase means nothing to them. Rather, what customers see is what’s on the outside, and human psychology is drawn to believe that beautiful packaging implies beautiful innards. So the user interface and the other visible parts of your software, device, or service matter quite a lot in conveying the level of quality and care that went into the rest of the solution as well.
However, it’s going to take time to get the details right, to get feedback from real customers to learn which details they notice, to take a bit more care to polish the edges, to fix those fit-and-finish bugs, to get the performance to be not just acceptable but outstanding and responsive. Naturally, there are tradeoffs. This level of detail and customer empathy requires extra work. If you want to get your product to market in a timely manner so that you can actually make some money, you need to choose to focus on delivering a smaller number of end-to-end experiences in order to have the time to execute each of them at a higher level of quality.
What if there is no GUI?
It’s fairly easy to imagine what a smooth, end-to-end customer experience for a consumer product might look like, especially for one that uses a lot of graphical user interface elements. However, we’re often asked whether an end-to-end approach is relevant to more technical endeavors, like software platforms or APIs, software that has little or no visible user interface. Is there such a thing as an end-to-end experience with an API? Does delight really matter when the customer is a developer?
Perhaps the simplest way to answer this question is with another question: Have you ever been excited about using a programming language or an API? Have you ever witnessed an argument between two developers over their favorite programming language or model? The emotion displayed in those discussions can be very strong, and that emotion is evidence of a customer experience that has gone either very right or very wrong—we’ve witnessed both, and we’re guessing you have as well.
As I think back to the early 1990s, I can recall a number of offerings that captured the hearts and minds of software developers. I was lucky enough to be part of the Visual Basic 1.0 team at Microsoft. I was able to experience firsthand what it’s like to demonstrate a new product that customers (in this case, developers) love and to watch the creation and nurturing of a loyal fan base. It seems strange now to be using words like love, nurturing, and fan base when talking about a programming language and tools. However, in the early 1990s, when rapid application development (RAD) tools were becoming popular,11 audiences commonly gave resounding standing ovations during demos. Typically, the presenter would say something evocative, like “Have you ever tried to finish a project only to discover you can’t because of FOO?”, and the whole audience would moan in agreement and empathy because most of them had suffered through that exact scenario. Then the presenter would type a couple of lines of code or drop a widget onto a UI element, and voilà—FOO was magically solved! Audiences would go crazy. It makes sense. The presenter would skillfully describe a real-life situation in which most of the audience had experienced frustration. And then, in front of their eyes, they would see how to solve that problem with ease.
Mindshift
I is for interface. To point out the obvious, the I in API stands for interface—not just the interface between one piece of code and another, but the interface between a piece of technology and a human being (the developer). The customer in this case is a developer who is writing code against an interface. A well-thought-out API that considers the end-to-end needs of the developer is a wonderful thing.
Sadly, many APIs are written in a utilitarian manner to serve the function of providing connections between two libraries or to expose the raw functionality of some technology to a developer. Perhaps because the customer’s end-to-end experience is more remote, it’s common to race through the design phase of GUI-less components. Have you ever seen the results of a quick API design captured as a whiteboard full of lollipop stick drawings?
But while an API built this way can be functional, it’s rarely fun to use. Why? Because it doesn’t intentionally account for the customer (you, the developer) and your needs. Instead, it focuses only on the technology and how to expose that technology externally.
Ruby—a love story
Visual Basic is not the only programming environment to have elicited strong emotions from customers. FoxPro, Delphi, Smalltalk, NeXTSTEP-Cocoa, and Lisp are all examples of integrated development environments (IDEs) that captured a large, loyal, and enthusiastic fan base. Remember how some developers reacted to the Java language? The early JavaOne conferences were reminiscent of something between a rock concert and a love-in.12 Over the years, developers have doled out a lot of adoration for their beloved programming languages, frameworks, and tool sets. It’s not solely the user interface that generates this affection; it’s the combination of programming language, API framework, and IDE that allows developers to get on with the business of creating while minimizing unnecessary hassle and maximizing the fun, rewarding part of developing software.
A more contemporary love story between developers and a programming environment is Ruby on Rails. (Ruby is the programming language, and Rails is the application framework.) Ruby was created in 1993 by Yukihiro “Matz” Matsumoto, who said, “I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python.” He says that he designed Ruby for programmer productivity and fun, and stresses that systems design needs to emphasize human rather than computer needs. He had a very strong sense of focusing on the user rather than the technology:
Often, people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.
Rails is an end-to-end (or full-stack) development framework for writing web applications using the Ruby language. It includes support for the web server, the database, business logic, the routing system, and test-driven development. In its design, Rails emphasizes a few key principles, which include:
Model-view-controller (MVC) pattern
Convention over Configuration (CoC)
Don’t Repeat Yourself (DRY)
Poke around the web a bit looking for information on Rails and you’ll run into additional principles that people either attribute to Rails or apply when writing Rails applications. Search for “Ruby+Rails+Love,” and you’ll discover Ruby has a lot of fans. And as is often the case with great design, you’ll also find a few anti-fans.
Mindshift
Great end-to-end experiences can be polarizing. While a well-thought-out design can deeply delight the customers you have targeted, the customers you have not targeted may not see the value you have created—their needs are not being met by you. Consider the C++ language, which was designed for a very different type of user than Ruby was. C++ also has a lot of fans—and a lot of anti-fans. Its design principles are in stark contrast to those of Ruby. Instead of optimizing for productivity and fun, C++ optimizes for control, choice, and zero overhead. These languages serve two different audiences, with two different sets of design principles, and two sets of fans (and anti-fans). Is it possible to optimize for both types of customers and usage patterns with the same solution? Usually, when you try, what you end up with is a mediocre solution that doesn’t solve either set of needs particularly well, and neither customer is delighted. It’s a tough decision, but if you strive to have passionate fans, you’re going to have to live with the fact that not everyone will love what you build. We’ll discuss strategies around how to maximize the quantity and business value of your target customers, and how to choose them, in Chapter 4, “Identifying your target customer.”
It’s interesting to look at the similarities between the design of a successful programming language and the design of other successful products.13 Ruby had clear focus on customer needs and desires—it was all about developer productivity and fun. The Rails framework embraced an end-to-end philosophy that considered all the layers necessary to write a running web application. They were woven together into a great solution that really solved the end-to-end needs for the rapid application web developer. And the market responded with a large and loyal following. The point here isn’t to delve into the design of programming languages, it’s simply to state that it is absolutely possible for code that has no GUI to be designed with a target customer and an end-to-end experience in mind. And if that is done well, a non-GUI component can generate a strong emotional response from the user. With that context in mind, here’s the rest of my Ruby story.
The things developers say
When writing this section, I reached out to a few friends who I know enjoy programming in Ruby. I asked them what they love about Ruby and why. I wanted to be able to summarize those attributes for you at a more detailed level than “Yeah, people really like Ruby—they say it’s fun.” I thought that providing details on the design philosophy of something like Ruby could be a valuable template for you to use when designing your own components. And so, to get feedback from Ruby programmers, I summarized my analysis like this:
The Ruby language was highly principled from the very beginning, while Rails embraced an end-to-end strategy of creating a full-stack offering. I was excited to discover that, in fact, the early design of Ruby and Rails seemed to strongly support the thesis of this chapter—that an end-to-end design trumps a set of features every time, even in an API with no GUI.
When I contacted my Ruby-loving friends with this analysis, what I heard back was fascinating. I received plenty of affirmations of Ruby principles that my friends found important in their day-to-day programming, things like:
“Ruby is a phenomenally expressive language.”
“I love that it favors convention over configuration.”
“I think the cradle-to-grave concept of Ruby on Rails is very true.”
“The Ruby [and GitHub] culture is that it is okay to make breaking changes if it makes the library better. So instead of people being scared of pushing a library too early and being stuck with a non-ideal interface, people push very early and see where it goes.”
“It’s inherently readable and expressive.”
“Along with Python, [Ruby is] widely considered ‘beautiful.’”
“Ruby on Rails gets out of my way so that I can be a great developer.”
It was somewhat surprising but also encouraging to me how many of the comments were based on subjective emotion, not necessarily fact (which some might assume trumps emotion in programming). I also received this note, which is an insightful articulation of the deep connection developers sometimes have with their language:
As far as emotional connections between products and people, my very strong belief is that everyone has an artist in them. Sure, some people are legitimately great artists: writers, actors, painters, sculptors, etc. But all of us have an innate desire to create things, to marvel at our creation, to share our creations, and to revel in watching others enjoy our creation. It’s what makes us human beings. We aren’t just here to eat and sleep. We are here to create something that lives after us. When a product helps us create something AND makes the act of that creation enjoyable, people fall in love with it: they fall in love with the output of the product and they fall in love with using it.
At the end of one particularly long email message, full of code examples describing why Ruby is so great, was this simple reminder: “But don’t forget: it’s fun. It’s really, really fun.”
Is delighting customers with an end-to-end experience indeed relevant to software that has little or no GUI? The answer is absolutely yes.
Don’t forget what you already know
Building a set of end-to-end experiences that satisfy your customer’s deepest needs is a wonderful thing. But it isn’t everything. It’s entirely possible to build the most beautiful, most compelling end-to-end experience ever that nobody actually cares about—or, rather, they care, but not enough to part with their hard-earned cash in exchange for that experience. You need to have a robust, realistic business plan behind your venture so that you will actually make money.
It’s also possible to build a great experience on top of such poor technology that . . . well, it just doesn’t work.
To build a successful product, you need to have a viable business strategy, technology that works, and a great end-to-end experience that meets customers’ needs. You need all three, flawlessly executed. If any one of those components is missing, your chances for market success become severely limited.
You surely already have great methods and years of experience for how to build reliable, performant, secure, scalable software. Chances are you also have a business team or leaders who are experts at shepherding your business strategy.
The difference is that now you need to add a new capability to the mix. You need to develop your skills at building delightful, end-to-end customer experiences. It’s likely that you are already trying to improve your abilities here. However, to do this well requires more than ad hoc efforts that rely on star individuals to lead a team (and that tend to fizzle when those people move on). To build great customer experiences, and to do that consistently on every project, requires the same level of rigor and attention that you are giving to technology execution and business strategy already, and this is usually a pretty big leap for most teams.
While there is some overlap and interplay between business, technology, and experience that we will mention along the way, this book focuses mostly on the new skills and approaches you need to develop to create great experiences. However, just to be sure we’ve said this out loud, the methods and mindsets we present in this book do not replace what you already know about delivering great software and managing a robust business. We hope this book helps you dramatically increase your skills in designing, iterating, and building great customer experiences, but don’t forget all the things you’ve always been good at—you still need that stuff.
Summary
Customers want their problems solved, from their point of view, as seamless end-to-end experiences. By focusing on an end-to-end experience, you ensure that your features work together to provide a complete solution rather than isolated islands of individual functionality. Whether you go wide to consider cradle-to-grave situations or focus on specific pain points, thinking about end-to-end experiences as complete solutions to real customer problems helps you focus on solving them very, very well.