Why Failure Isn't Working for Me

A response to a number of posts and talks on failure recently, particularly this one by Michael Krigsman, Five Reasons to Discuss Project Failure, linked from Scott Berkun's blog.

Based on Krigsman's points, I wonder, Is failure really instructive? In my observation, there are a lot of people who don't learn from other people, or even hear what they say. Maybe they're "experiential" learners. Maybe they don't think like researchers--who are trained to build on other work--or they aren't smart. I personally hope they are genetic dead-ends. It seems a rare person who takes on board the lessons or advice from others; at least, it takes a listener, and someone who isn't arrogant.

On the subject of arrogance: A lot of organizations suffer from "not invented here" syndrome. They're in successful companies, don't see why they should do anything different, don't think they need to do other than tweak their current environment. And they're unlikely to hear from outsiders or new people. No matter how much they say they embrace change, learning, growth, new ideas... in general, in practice, it's not so true. Or it's better coming from someone internal with an extremely tailored message for that environment.

Do success stories really not work? The fun book Made to Stick doesn't entirely agree. One of my issues with stories of failure is that they end up being a lot like usability test results: Show you everything you did wrong, but provide no solutions for how to fix things. And it's hard to get the "right" lesson, because lessons are almost always hypothetical. IF we hadn't cut this feature, it would have sold better. IF we had done user testing earlier, we would have caught this. IF we'd had longer to develop the right architecture, this would be faster and people wouldn't be complaining about performance. IF IF IF. No one really knows, it's all just opinion.

If you don't understand your successes, you can't replicate them. And you can't use them to inspire anyone. You had a project team that cleaned up a disaster in record time and shipped something people loved. What was different about that team? What did they do better? Okay, it may be partly a comparison with the failure before, but it's surely instructive!

Root cause analysis of failure always has to skirt around sticky, difficult, subjective personality issues. This is often unproductive to discuss, and doesn't lead to positive outcomes. The people who name names look bad, and often suffer for it later. That guy who's the blocker for a zillion projects - everyone hates working with him, but he's critical path. Yes, it's been elevated to his boss before. VPs have been involved. Multiple VPs, on one occasion, during which ego bristles poked everyone. Nothing has changed. That guy is going to continue being a root cause problem on a lot of things. Talking about it means VPs and bosses are implicated too. And isn't it just personality issues for everyone involved? (Note, I advocate firing his ass, or moving him to another role; but I'm not in charge. The organizational dysfunction, which is usually just human nature, is in charge.)

Now, to switch onto on the subject of design failure. A hot topic among design gurus right now (see Spool on "Failure is Not an Option, It's a Requirement" and Scott's recent talk on "Why Designers Fail"), we're being told that good design involves failure and failure is important for innovation. I'd argue that designers themselves often know that design is iterative and exploratory, with important dead-ends that lead to strong results, but their managers or other necessary stakeholders don't know this. I hope Scott and Jared are being heard by these other folks, too, and not just by designers.

The people with the money are the ones that matter. They determine what constitutes failure, in the short term, like it or not. Many design consultants worry that client judgments don't take this iterative process into account. We are paid to be fast, creative, and accurate, all at the same time. Mistakes or dead-end work aren't seen as productive value for the money by many hiring managers. And their own sometimes flawed design judgments are at play in their judgments of our work. What should be a success is seen as a failure, through the squinty eyes of a manager that doesn't get it. It takes design talent to recognize design talent, yet most hiring managers aren't skilled or talented in this way.

This phenomenon leads to failures that shouldn't have been failures - good work was thrown out, bad work was done instead. Happens all the time. Happens on every dialog, every icon, every wording argument. Most of us live with failure very regularly: The little voice inside blaming us for not arguing the point just a little longer, for not standing up to that bully on the team about this important issue, for not getting to that other issue that's probably more controversial and yet more important for the user in the long run, for not making one more mockup to try to show how it could be better, or moving to Flash to show how it would work for real.... Oh yeah, we've got a lot of failure all the time. And our failures are much more visible than the guy writing some code on the backend that thrown an uncaught exception, which may not be noticed for years!

My point of greatest concern about these homages to failure right now is that they don't take into account power dynamics in most engineering organizations. (To be fair, Scott's talk does, and he found that managers who aren't skilled in design are a major cause of failures.) Designers are a minority discipline, and often we're trying to change processes and methods while also delivering on our work. We're trying to set an example with our deliverables and methods. The odds of success are already long against, given the weight of org history and number of people we need to convince. As minorities, we're often trying to argue for more headcount, and every misstep can be seen as another argument against hiring more of us.

Visible failures aren't generally a positive option, when disciplinary credibility is at stake.

CAD is Just a Tool: SolidWorks World 2009

The guest speakers at SolidWorks World 2009 really brought home to me how wonderful a rigorous design process can be - driving the product development, rather than struggling to catch up! There were 3 guest speakers that hammered on this: Sir Richard Branson of Virgin, and design managers from New Balance and Sony Ericsson.

Branson was charming and very sharp, as one might expect from his serial business successes. Rather than just a greedy mega-money maker, he came off as a human being, and reminded me of the late Randy Pausch in his advice to "have fun, or find something else to do." His approach to business showed him to be a design thinker from the get-go: His prime advice was to talk to customers and do a ton of research before you ever start making anything. And that the details will kill you: If your airplane seat is second most comfortable, you lost your edge. Hey, let's have standup bars so people can stretch their legs on long flights. Think differently, and solve real problems no one else has tackled!

Then we met designers from New Balance. Jon Hirschtick, a founder of SolidWorks, was shown on video interviewing them at the office first. I was amused by his physical dismissal of the pre-CAD design - he pushed it behind them, visibly, and wanted to get to the CAD part. Makes sense for a guy from a CAD company, but it's not the reality of the design process for the customers.

They showed many iterations with industrial designers sketching the soles and talked about "capturing the designer's vision" in the CAD tool - because that vision is driving their design. It's not the CAD tool or what's possible in it that's driving the product design! Few of their industrial designers use SolidWorks, they use Illustrator--noted by the Sony Ericsson manager up next to be "at least as complicated as SolidWorks if not more" (I say, YES - CAD manufacturers need to comprehend that other tools are professional caliber, too, and also quite complex). New Balance designers were shown drawing by hand on the interview video, as well.

CAD is the "middle part" of their design process. We saw nice rounds of 3D printing, and then an excellent example of making a mold in-house for a real prototype sole to glue onto the bottom of another shoe for field trials (see smooth-on.com).

The physical prototype on the shoe bottom was the "end" of that interview, but I shook my head sadly. The design process isn't over: They're field testing it now! There's a whole range of feedback to process, and design revisions to be made, based on how it feels to walk on! The design manager himself was wearing prototype soles on his feet during his presentation.

Oh, the frustration of getting the truncated design process, to focus only on CAD. Design is computer-aided, not computer-exclusive.

Then came Sony Ericsson. SE works hard to stay competitive in a crowded mobile market. In keeping with Branson's advice, they do a lot of research up front, and employ more cultural and social anthropology approaches than most companies. They look at consumer and design trends or "tendencies," to try to predict what will resonate in 2 years, to keep ahead. (Hirschtick acknowledged this was "a great model for all of us.")

Again, SE design starts in 2D with sketches and Illustrator. About half of their industrial designers want 3D CAD in hand, the others use other tools to express their vision. Their prototyping works the way software prototyping should, using less detail and fidelity initially, to get the egonomics and scale right. He talked about a "form language" they are trying to express first. The design teams produces product animations early in the process, to show to customers for input and feedback, well before development.

Like (most?) other designers, when asked what their biggest challenge is, they said, "Internal politics." Apart from politics, the other challenge cited was "staying fresh." Sometimes it pays to go off on a "no rules, no assumptions" design kick and get crazy. Question what makes the front different from the back of the phone, and why? Why should we sell through normal channels? What if we didn't??

Sony Ericsson wants tools for design that are very accessible, with fewer features for quick and simple use. Again, Photoshop and Illustrator are already more complex than most CAD tools, and industrial designers are experts with them. What I liked about this was the recognition that their design expertise and skill wasn't seen as useless simply because they didn't use CAD: It's the tools that have to speak to the designers better. (And, quite possibly, an employer that could make more time for learning more tools on the job.)

As a software designer who has spent more than the last decade trying to get design pre-coding taken seriously, I could only hope that the owners of software companies in the audience were thinking about how these successful businesses might teach them something. Important points, for me:

• Design requires a lot of customer input up front - take the time to do it, and do it seriously. Consider using skills from anthropology, sociology, or cultural studies while doing this - because those people see things differently. (They might not, for instance, shove the pre-CAD design behind them to get to the CAD part of the company process.)
• Design is iterative, even before coding/modeling: Review ideas, discuss them, and revise the design. For software, this can be a simple as mockups and sketches.
• Prototypes are a part of design, in that they give the designer and team something to feel and play with and revise.
• Prototypes should start low fidelity and get higher fidelity, as the design progresses. This means breaking the problem down into "first part" and "second part" etc. In software design, this is also doable, but rarely done and requires sufficient time and analysis.
• Tools of a variety of types might be wanted and needed. A designer might still be great, even if they don't speak your tool language. Can you tool be made to speak their language? Can you change your process to incorporate other tools and, even better, other voices?
• Good design can save you expensive mistakes - the CAD world has been preaching this for years, but few software companies have gotten it yet. Design it before you code it, if you want quality products.

Go forth and design better software, folks!