Lean Startup is Brilliant Because it's User-Centered *Business*

Posted by Victor Lombardi on May 23, 2012 | Comments (0)

Like Jared, I didn't think there was much that was new to Lean UX or it's mom, Lean Startup. The user-centered design we've been practicing for decades has helped us avoid failure by iteratively going to customers, testing prototypes, and measuring the results.

But quickly I came to appreciate how nicely Lean Startup packages this and related concepts, like the cost reduction of lean manufacturing (e.g. use open source software) and customer development. But what's brilliant about it is this: Lean Startup is not just a collection of techniques; it's a method of doing business. That's big for two reasons:

1. User-centered design (now seemingly subsumed into the term user experience) exists at the team level. Teams have to appeal to business leaders to do their work, and even when the design work is excellent it exists somewhere inside a larger business process that ultimately determines the customer experience. Lean Startup happens at the business level.
2. Merely describing how a hypothesis-prototype-test cycle should exist at the front of business hasn't seemed to have as much effect. The Innovator's Dilemma described this back in 1997, the discovery-driven planning and assumption-based planning folks said it in 1995, and Block and Macmillian said it back in 1985. Those ideas were influential, but I haven't seen them change the way an organization manages itself. A business adopting an idea isn't as powerful or lasting as a business adopting a method.

Test Your Reaction to Experience Design Failure: Air France 447

Posted by Victor Lombardi on May 1, 2012 | Comments (0)

In the book I sometimes illustrate an experience design failure and then ask, "If you were in charge, what would you do next?" Then I tell you what the company did next. It's a great way to appreciate not only how difficult it is to avoid failure but also that having full hindsight doesn't make it obvious how to change a design to avoid failure again. Here's an example I'm fascinated by that won't be in the book.

Let's begin with the summary from Wikipedia:

Air France Flight 447 was a scheduled commercial flight from Rio de Janeiro -Galeão (GIG) to Paris -Roissy (CDG) involving an Airbus A330-200 aircraft that crashed into the Atlantic Ocean on 1 June 2009, killing all 216 passengers and 12 aircrew. The accident was the deadliest in the history of Air France, and has also been described as the worst accident in French aviation history.

After years of searching the black box was found and investigators were able to report what happened. This article by Nick Ross and Neil Tweedie in The Telegraph, Air France Flight 447: 'Damn it, we're going to crash', is a great summary. Go read it now then come back.

I discovered the article via Daring Fireball where John Gruber quoted this part:

As forward thrust was lost, downward momentum was gathering. Instead of the wings slicing neatly through the air, their increasing angle of attack meant they were in effect damming it. In the next 40 seconds AF447 fell 3,000 feet, losing more and more speed as the angle of attack increased to 40 degrees. The wings were now like bulldozer blades against the sky. Bonin failed to grasp this fact, and though angle of attack readings are sent to onboard computers, there are no displays in modern jets to convey this critical information to the crews. One of the provisional recommendations of the BEA inquiry has been to challenge this absence.

Then Gruber wrote, "User-interface design is, in some cases, life or death." I loved reading that statement because it supports the importance of my book, and I tweeted it. But on further consideration I'm not sure UI design is at fault here, for three reasons.

First, the above quote from The Telegraph article is technically incorrect. The angle of attack information is available on the display, but not by default. As this article points out, "it is possible to call up angle of attack on the ACARS (Aircraft Communications Addressing and Reporting System) display."

Second, and most importantly, the key reason this doesn't happen in Airbus A330 flights more frequently is that the problem was pilot error:

Bonin's instinct was again to pull back on the control stick. He left it there despite the stall warning that blared out some 75 times. Instead of moving the stick forward to pick up speed, he continued to climb at almost the maximum rate. If he had simply set the control to neutral or re-engaged the autopilot, all would have been well.

Third, the A330 cockpit today is already rather complex. I'm not convinced we should further complicate it with yet another data point if this problem is mainly due to pilot error.

On the other hand, research may support adding the angle of attack information: "Years ago both Boeing and Airbus consulted with management pilots worldwide on cockpit display preferences. Because the US military is such a strong influence in the United States, they asked for an angle of attack indicator; however neither manufacturer decided to install it..."

We might also assume that there will always be less experienced pilots in stressful situations in the cockpit, and we need to take all reasonable steps to insure the same problem doesn't happen again.

You're probably not a airplane cockpit designer with a Ph.D in human factors, and yet considering what you would do with this information may tell you something about how you would manage a similar situation in your work. Would you:

1. Add the angle of attack information as a standard data point in the cockpit
2. Somehow communicate how one pilot is manipulating the side stick to the other pilot (see The Telegraph for the side stick explanation)
3. Improve pilot training
4. Run simulations and usability tests
6. Something else?