Why We Fail is available in eBook form at O’Reilly and all the reviewers there gave me 5 stars! Yay!
Paul in Austin writes:
The case studies alone provide an very interesting read to anybody who has some interest in technology in general.
Each case study has been thoroughly researched with plenty of references. The author also provides video clips to help the reader visualize the user experience of the discussed products.
In addition to user interface developers or designers, product managers and architects will also benefit from the methods for avoiding future UX failures described in the second half of the book.
BOTTOM LINE Yes, I would recommend this to a friend
Ken in Hoboken writes:
Too many books focus on success but I feel the best way to learn is by studying failures.
Prior to reading “Why We Fail”, the only other book I read along the same lines was “Billion Dollar Lessons: What You Can Learn from the Most Inexcusable Business Failures of the Last 25 Years” by Carroll & Mui.
I am an engineer, not a designer, but I often consult on projects where no UX person is hired, forcing me to assume that role in some fashion. I found this book to provide great insights that I would not have otherwise considered.
For example, as an engineer, I focus on meeting the user requirements, but the case study on the failure of the Microsoft Zune music player (Chapter 5) demonstrates how much more powerful the user experience is over the feature set.
I found it an eye-opening revelation in Chapter 9 that Microsoft’s many expensive failures is due to its practice of sweeping mistakes under the rug and never sharing experiences with their product groups.
Chapter 7’s discussion on ethics is a valuable addition to the material.
I highly recommend this book.
BOTTOM LINE Yes, I would recommend this to a friend
While I was researching my book Why We Fail: Learning from Experience Design Failures I spent some time reading about people’s experience with RealNetworks, particularly the RealPlayer, and wondering if they were worthy of inclusion in the book, particularly the don’t be evil chapter. At that point there was no smoking gun, no hard evidence that Real intentionally did the wrong thing.
But this week a story was published which confirmed my suspicions. It’s called The Graph That Changed Me. Here’s an excerpt:
One day my manager showed me a horrible graph. It was pretty simple: the graph was steady, then it dropped straight down, then after a short period, the line shot straight back up and stayed level again:
Artistâ€™s rendering of why you probably donâ€™t like RealPlayer much
â€œThatâ€™s what happens when we do the right thingâ€, he said while pointing at the drop, â€œand thatâ€™s how much money we lose. We tried it just to see how bad it was for our bottom line. And this is what the data tells us.â€
â€œWow,â€ I said, taken aback. My employer clearly had two options: â€œdo the right thingâ€ or â€œbe profitableâ€. That was the position they had maneuvered themselves into through a series of bad management decisions.
That “series of bad management decisions” may involve a slippery slope of subtle temptations and minor rationalizations, not one big bad decision to be evil. But having been there I know it’s all too easy to fall into the trap of binary thinking. You can hear it in that story:
two options: â€œdo the right thingâ€ or â€œbe profitableâ€.
Design thinking is abductive, inventing new options to find new and better solutions to problems. In the universe of all possible businesses, were there more options than just â€œdo the right thingâ€ or â€œbe profitableâ€? Of course. We just need to be willing to try harder, apply our creativity, and make “do the right thing and be profitable” two constraints of the design problem.
Love this Steve Jobs story:
…Jobs turned around Apple and did it pretty quickly. He did two primary things as far as I can tell. First, he got his people into the top jobs and got rid of the executives who had been calling the shots before he showed up. And second, he brought focus to the product line, and thus everything else.
There’s this great scene in the book where Jobs draws a classic four quadrant chart, consumer and pro on one axis, desktop and laptop on the other. And he says “we are going to make one computer for each quadrant and we are going to kill all of the other product lines”.
This blog has been quiet for so long because I’ve been working on my first book, and it’s finally published. Why We Fail: Learning from Experience Design Failures is about websites and consumer electronics that were successfully launched and hailed as great designs, but failed unexpectedly when people used them, plus my attempt to explain why that happened and what people who make them can do to avoid failing.
John Cassidy penned a powerful piece for the current issue of the New Yorker titled, Mastering the Machine: How Ray Dalio built the worldâ€™s richest and strangest hedge fund. Part of Dalio’s success in creating massive financial returns while controlling risk stems from his financial wisdom, but the success of his 1000-person organization that runs their three funds has been attributed to how he’s created a culture of “truth and transparency” which helps them (among other things) avoid and learn from failure.
My summary of the key characteristics as described in the article:
- Discussing issues by citing evidence and experience rather than mere educated guesses
- Expressing opinions in a transparent way, and giving forthright feedback to anyone else in the organization
- Removing the emotional reaction to mistakes so people understand clearly why they happened and can logically discuss how to avoid them next time
And one quote from Dalio:
What weâ€™re trying to have is a place where there are no ego barriers, no emotional reactions to mistakes…. If we could eliminate all those reactions, weâ€™d learn so much faster.
I’m a huge fan of the ‘old’ Readability — I hit a button which sucks out the content of a web page into a nicely formatted view, then I usually hit the Evernote button to save it for reading on my Macs or iPhone.
The Readability folks recently amp’d the feature into a business. They added the ‘read later’ function of Instapaper/Evernote, and most notably a subscription revenue model from which they pay 70% to the content creators or publishers to compensate them for the ads Readability sucked out.
There’s a lot I like here, from their reader-first philosophy to the fine folks they’ve chosen as advisors (a few are friends of mine). But I can’t help thinking it’s not going to work. My doubts:
- They’re competing with ads. Large organizations that depend on ad revenue have huge investments in ad serving and tracking. Readability to asking publishers to give that up for what Readability gives them. 70% sounds generous, until you do the math and realize 70% of not much is not much (see They’re small below)
- They’re competing with free in the form of their free Read Now offering, the open source version, and Evernote. And Evernote is very, very good.
- They’re small, so besides the fact that what they pay publishers won’t be much, they haven’t revealed any way to scale to the size necessary to make a material difference in how the publishing industry works. They have an API for developers, but they need to focus on the publisher side of the equation.
- They’re not giving publishers control. Sophisticated ad serving systems let publishers tweak ad buys based on calculations of page views, content costs, clicks, etc. Readability simply offers a set percentage. And Readability is hoping publishers will do the work of coming to the Readability site to sign up, just to get the deal Readability dictates.
- The legality is questionable. If I’m an asshole publisher (you can be sure they exist) I only see someone who is stripping out my revenue stream as a threat to my livelihood, and I call my lawyers for their opinion. Chances are the big media houses have more lawyers than Readability.
- 30% is expensive. Apple takes 30%, but has gorgeous devices and stores and the iTunes marketplace and credit card numbers galore. Publishers can bitch about Apple, but they offer a lot for their 30%. The value that Readability adds is small in comparison.
I could be wrong, there could be a huge infusion of this function into every reading tool. And once it gains a critical mass of readers the publishers get on board. But I don’t think the product is quite positioned for that yet. Here’s an alternate business model leading the same, and sometimes better customer experience:
Readability develops an ad network-facing API and partners with the biggest ad serving networks to integrate the API. When a publisher serves a page, the ad network checks the visitor’s machine for a cookie and if present serves a ‘clean’ page to Readability subscribers and a normal page to everyone else. The impression is recorded and Readability pays the ad network who in turn pays the publisher. In this model publishers don’t have to configure anything new and get paid automatically, the ad networks get paid and get a new revenue stream, Readability gets paid, and Readability subscribers get beautiful, clean pages often with zero clicks.
A few years ago I wrote an essay on “Strategic Delivery Points” to try and show how great product/service design, customer service, and other points where we deliver service to a customer can actually be a strategic advantage. There’s nothing new about this idea, of course, except that the emphasis on this approach is more important now more than ever, and why we read so much about design in the business press. Where before the product design or customer service was the responsibility of a low- or middle-manager, executives are now focusing on it.
Does that sound like hyperbole? Stop rolling your eyes and read this:
Robbie Bach, head of Microsoft’s entertainment and devices division, admitted that Windows Mobile isn’t losing market share because of sales or marketing or distribution or feature set, but that, “Our experiences aren’t as rich as they need to be.”
This one is better:
“The engagement with our users wasn’t there. One of the things we’re focused on is relentlessly improving the user experience.”
— Owen Van Natta, a former Facebook executive who replaced Chris DeWolfe as chief executive of MySpace six months ago
Interesting — we’ve now got CEO’s talking about the strategic importance of user experience.
So who’s advising them?
“Meanwhile, Nokiaâ€™s attempt to match the iPhone, with the N97 launched in June, has failed to impress. Credit Suisse analysts gave the N97 a score of 63 out of a 100, compared with 91 for the iPhone.”
Credit Suisse? Yes, I’m sure they can hire for UX expertise, but when thinking of core competencies is a bank the one you go to for UX expertise? Or even for a quote in the Financial Times?
People, fill this gap.
Note: Over the next few weeks I’m blogging my notes on Amy Shuen’s book Web 2.0: A Strategy Guide: Business thinking and strategies behind successful Web 2.0 implementations. (O’Reilly Media). The book is both a good introduction and a synthesis of diverse theories that should offer something to even experienced strategists.
Background: What is Web 2.0?
What is Web 2.0?, the seminal article by Tim O’Reilly
Chapter 1: Users Create Value / Flickr
- Alvin Toffler predicted the “prosumer” in his 1980 book The Third Wave, and with recent technical advances in web and digital technology his vision is being realized.
- Like so many startups, Flickr started out doing one thing (a game) and by listening to customers transitioned to another offering, online photos. The small team including technically-smart founders could turn customer feedback into rapid release cycles. A key to Flickr’s growth was making photos public by default.
- The freemium business model was first described on Fred Wilson’s blog: “Give your service away for free, possibly ad supported but maybe not, acquire a lot of customers very efficiently through word of mouth, referral networks, organic search marketing, etc, then offer premium priced value added services or an enhanced version of your service to your customer base.“
- Flickr’s platform was timely in compounding the positive network effects of broadband, digital cameras, blogging, social networking, and online syndication.
- Flickr’s core business message: Don’t build applications. Build contexts for interaction.
- Stages in the open systems movement: Linux; APIs; user-generated content. Flickr combines the last two to compound their use.
- Flickr’s interestingness algorithm factors in popularity, interaction, identity, and time.
- Flickr uses the first three of the six kinds of revenue models: Subscription/membership; advertising; transaction fee; volume/unit-based; licensing and syndication; and sponsorship/co-marketing/revenue-sharing.
- They managed to avoid the four major cost drivers (inventory, payroll, IT, and marketing/advertising/CRM) compared to retail photo printing and online stock photo companies.
- In March 2005 Yahoo! brought Flickr for an estimated $40 million, a value that can be calculated using a customer-based formula in which revenues are directly tied to customer fees, not unit prices. Tracking customer behavior and metrics on an ad-supported site can result in an average revenue expectation per customer; in 2006 it was $13 for Google. Flickr had advertising, premium services, and partner revenue, making the average revenue per customer about $20. Multiplied by Flickr’s 2 million customers, we arrive at the $40 million valuation. More sophisticated formulas might give different weights to customers based on how actively they use the platform.
If you’re a member of the AIGA and in New York, you might enjoy a fun little breakfast gathering planned for Tuesday, January 13, 2009…
Redesigning the RFP response
Maybe youâ€™ve gotten one: the RFP that asks for mountains of miraculous work, for no money, delivered in 20 minutes. Or the one for a project so boring you wouldnâ€™t give it to an intern. This morningâ€™s Breakfast Club asks: Can we perform a Jedi mind trick and turn those nightmare RFPs into satisfying, rewarding work? â€¨Victor Lombardi, veteran consultant and teacher, will lead a discussion about rethinking how to conquer the dreaded RFP.
Not long I was talking to a project manager who was writing her first request for proposal, explaining the common wisdom on budget disclosure: “You’ll want to give them a ballpark idea of what your budget is without telling them your actual budget; agencies will sometimes configure the work to take all the money on the table.”
But as I, with fresh eyes, watch her go through the proposal process, I do wonder if simply telling the agencies the budget wouldn’t be such a bad idea. Floating this idea on Twitter sparked these replies, mostly from peeps on the agency side:
“I always make them tell me the budget. If they can’t then I don’t send a proposal. That’s my tough love policy. Very few balk. I [tell them] we could propose $1M site, but its best that I know what the constraints are. 99% find it helpful.”
“It would certainly decrease wasted effort.”
“Absolutely! It would eliminate spinning our wheels too. Why waste the time proposing something they can’t afford?”
“I’ve worked at agencies where we lost jobs because we proposed too large a project. This could have solved it.”
Money is a great constraint for spurring creativity. And if the same budget were disclosed to all agencies, the client can still compare the relative value of each proposal. The only drawback I can think of is if the budget is far out of alignment with the work requested, and if this is the case the client should be working with an expert outside resource to craft the RFP anyway.
(I’ll add this is specific to RFP situations. I still agree with the usual consultative selling advice to not talk about price until the very end of the sales process.)
So we all know that at the heart of creativity lie constraints. And one constraint I love is money.
I thought of this today as I read about a friend’s company who spent “tens of thousands of dollars” on legal fees just for their domain name. Maybe that was money well spent, but from personal experience I know legal fees are one of those line items that is almost always expensive, difficult to predict, and difficult to control once set in motion. For a start-up, this problem can be turned around into a creativity driver to say, “Here’s how much similar companies say they wished they had spent on legal fees. We’re going to stick to that. Let’s figure out how.”
Note that this is different than merely setting a limit on how much to spend. A simple cap could still allow for business-as-usual behavior that doesn’t generate any new solutions: “we did what we usually do until we ran out of money.”
A real design approach would involve experimentation.
With prototypes for solving legal problems.
Working with lawyers.
Measuring the costs of iteration and the opportunity costs.
I haven’t heard about anyone doing this yet; it’s one of those ripe areas for true business design innovation.
There was a New York City IxDA event at Roundarch last night that challenged 10 teams of designers to invent the portable electronic ink magic paper of the future. In addition to the usual functional stuff, fun ideas emerged like using it as a yoga mat, a DDR mat, or modules that could be connected together to make various sizes.
There wasn’t enough time to do a lot of critique of the designs, but it was fascinating to see how each group of 3-4 people self-organized. One group compared their process to speed chess — each person took a short time to iterate on the design and then ‘hit the clock’ passing the baton to the next person. Two groups talked about working together to define the problem and environment, then working independently on separate tasks. One of these groups actually moved apart physically.
The composition of the groups of course was pivotal. One father of a 3-year old was inspired by his son’s toys. A business analyst on another team ensured specific requirements were achieved.
And the methods varied too. Most accepted the advice in the brief to prescribe and describe scenarios, but others just picked a strong theme like “magic” and riffed on this pleasingly, having the device learn your gestures and automatically load images from a camera. It was a great reminder to me that the questions you ask determine the conclusions you reach.
You need a great design to please your customers, and a great business model to pay for the design, so we’re offering classes on both topics to help user experience practitioners, managers, and entrepreneurs thrive in New York City.
For 10% off any class, enter the code NBS when registering. If you plan to attend with friends or colleagues, contact me for a bigger discount: victor (at) smartexperience.org.
The common way that financial people will judge the potential value of a project, or a design concept representing a potential future concept, is by building a model, usually a discounted cash flow model like Net Present Value (NPV). The calculation essentially asks, if we do this project and gain the profit we think we’ll gain, how much is it worth to us right now? That way we can compare it against our other options.
The problem with these models is that they assume the world doesn’t change. The model tries to predict everything that will happen in the project from beginning to end in order to arrive at a single numerical value. But in the technology world, there’s lots of change.
So peeps at the forward edge of product and service development have started using real options to value projects. Real options essentially breaks the project down into a series of decisions. At each decision point a number of outcomes can occur, and for each outcome there’s a probability it will occur. There’s also a revenue associated with each outcome that we receive if it occurs. By multiplying the probability by the revenue we get the value of the option.
This is often illustrated using a decision tree, as with this analysis of a drug in clinical trials…
What’s the big deal? It turns out this is a better way to value investments in Internet services for at least three reasons I can think of off-hand…
- Versioning: The Web 2.0 way of doing things is to release our work in stages, the public beta being a perfect example. If the beta is a big fail, we stop there and cut our losses, or we go down a different path of the decision tree.
- Uncertainty: There’s a great deal of uncertainty in our work. Twitter, for example, is a big success, but at the cost of a very tricky technical challenge. Instead of an NPV model that would judge the value of the project to be either simply negative or positive, we can model this reality of “large audience / technologically expensive.”
- Fast Risk Management: The ease of building betas makes it tempting to skip a big financial modeling activity, especially if it can’t accurately reflect (i.e. predict) how customers will react. Creating at least a simple real options analysis can save a lot of investment before building a beta that is hard to emotionally trash once it’s built. And while it’s tempting to say predictions are impossible so we should just run a trial, few managers with any P&L responsibility will invest in that.
Real options isn’t a perfect technique, however. Proponents claim it supports decisions with “mathematical certainty,” but the probabilities are derived from managers’ experience and judgment which is subjective and imperfect. Getting a group of people to agree on the probabilities may be difficult, and once a project is up and running a team may be unwilling to revise their estimates downward to reflect new information, much less kill their own project. Still, for the kind of work we do it’s better than the old ways.