UIEtips: Failure Is Not an Option — It’s a Requirement

Jared Spool

October 29th, 2008

One of the many highlights of our recent UI13 conference was Scott Berkun’s Why Designers Fail and What to Do About It presentation. It generated a tremendous amount of buzz on the topic of how we can learn from our failures.

Interestingly, the theme of how to learn from failure was pervasive throughout the conference. Dana Chisnell talked about how to extract takeaways from usability tests. Jeff Patton discussed techniques for learning during the iterations of an Agile development process. Peter Merholz presented his challenges for organizations. And I discussed how teams need to celebrate failures, so teams have a chance to savor the rich insights that come from them.

It turns out that it’s no accident people are talking about failure these days. Over the last few years, our research has shown that the organizations that embrace the mistakes they make are more likely to show growth and improvement in their designs. That’s the great paradox: failure is strategically important to success.

In this week’s UIEtips, I describe how one nameless client got themselves into big trouble, how Amazon.com minimizes the risk from major design changes, and eight common mistakes preventing organizations from getting the most from their failures. I think you’ll enjoy it.

Read the article – Failure Is Not an Option — It’s a Requirement.

What does your organization do to embrace its failures? We’d love to hear from you. Share your thoughts below.

14 Responses to “UIEtips: Failure Is Not an Option — It’s a Requirement”

  1. Samantha LeVan Says:

    Larger organizations tend to be afraid of admitting failure. They’re afraid of backlash from the public and from their own employees. Individual contributors have come afraid to fail and afraid to admit to failure for fear of losing their job.

    At the highest organizational level, failure needs to be accepted and supported. Reward teams and indivuduals for documenting failures (the “whats” and “whys”). Encourage honesty and require all failures to be a learning event.

    In my user research work, I always divide my findings for the client into “successes we should continue in future iterations” and “failures we can learn from”. Often I have to rephrase it so it doesn’t sound like failure, but my hope is that over time, people will learn to embrace failure because with failure comes learning and with learning comes success.

  2. Steve Gentile Says:

    We have been conditioned to assign positive value and attributes to success, negative value and attributes to failure. Herein lies the issue. Until we turn that thinking around (or inside out or from another point of view), the outcome of every effort will remain the same, plus or minus.

    I look at “failure” as currently unrealized and unrecognized potential and “success” as currently realized and recognized potential. That being said, all “successes” become mainstream immediately, “failures” take a bit more time and effort. It doesn’t stop the innovation process or throw countless babies out with the bathwater — lucky for us.

    Remember, success is not without fault or blemish, it’s just greatly diminished in the bigger POV.

    Steve –
    http://www.thinktanknyc.com
    thinking done differently!

  3. Grammar Pedant Says:

    “Why Designer’s Fail”, eh?

    Maybe because they can’t use apostrophes correctly?

  4. Roy Zornow Says:

    This is kinda cliche but absolutely true. There’s a due diligence in trying out a new direction and not giving up on it. When confused try to be led by heuristics, but yes sometimes you get smacked down. I much prefer an employee who is innovating though.

  5. Steven Clark Says:

    Jared, it reminded me of the story of 3M and how they learned to accept innovation. Apologies but you may find the post I wrote quite interesting…

    http://stevenclark.com.au/2008/10/30/our-corporate-culture-should-support-failure/

    I’ve long had this very subject in mind if I do a dissertation next year or do research masters or even PhD in the future – the failure of organisations to capitalise on failure. More to the point of my interest is how the human factor in performance reviews can systemically work against the innovator. On the surface we all understand that new ideas are worth capturing, yet most businesses fail at it miserably.

    Interesting subject. Apologies for linking to my own article written as a response but it’s a pet subject of mine so I couldn’t help it. If I’m wrong it it about any of the 3M story then people should probably email Seth Godin, that’s where I got the meaty detail of the tale about the invention of masking tape. 3M are indeed a legendary innovative company worth exploring.

  6. stephen Says:

    what was the site that failed? uie?

  7. Daniel Szuc Says:

    Enjoyable reading and unfortunately seen too many projects afraid of failure.

    Its interesting to note, that so much gets invested into the build and implement stages and little into failing early or doing enough research early on to assess value of the thing you are about to build. Why are teams so afraid to invest up front to see if something will work or needs to change? (seems such a waste of time and monies)

    What is UIE seeing? Are companies started to invest more in user/design research to help better understand value proposition to drive products forward?

    Seems just as there are gaps between design and implementation, there are huge gaps between user research (if any is done at all) and design.

  8. porno izle Says:

    thank you.

  9. şiir Says:

    I have not said anything about this before, because no one was taking credit for it. It was originally supposed to be an “adult” children’s book. I have the original sketches and I am pretty sure that I have the original notes. I have often wondered how (and if) this leaked to the internet. The guy that I am pretty sure wrote it, would have definitely taken credit if he had posted it.

  10. Inder P Singh Says:

    I imagine several organizations make the following arrangements to mitigate risks and allow learning from failures:
    1. Execute small a.k.a. pilot projects (small for resources committed/ dollar value at risk/ etc.) in areas where several factors are unknown.
    2. Perform reviews and testing.
    3. Gather feedback from real users (as early as feasible and as frequent as feasible)

    Inder

  11. Email subject lines: Are yours a big yawn? » Interactive Marketing - MIMA Blog Says:

    [...] the ubiquitous Jared M. Spool: UIE Tips: Failure is Not an Option — It’s a Requirement UIE Tips: Four Essential Skills for Information Architects UIE Tips: How to Innovate Right [...]

  12. name Says:

    My first failure will be to not “embrace failure” :-) Sorry, but I just don’t think it’s that complicated…

    “no risk, no reward”
    “learn from your mistakes”

    Those are fine ideas, but “celebrating failure” is a bit hard to swallow and seems a little overly exaggerated.

    Counter-intuitive statements like the following will make you do a double-take, think twice, and ponder the idea in depth.

    “One thing is clear from our research: Failing is hard work. All teams need to get better at it through regular practice.”

    But software/web development already suffers greatly from excessive smoke and mirrors. Common sense and a pragmatic approach are in short supply.

    I will continue to simply avoid mistakes and failure as a general rule.

  13. Roger Belveal Says:

    There are things that are learned through failure that cannot be learned through success. Case in point, in the airplane industry, along with the huge number of tests done on the ground and in the air to verify airworthiness and safety, there is a deliberate destructive test done on every airframe. This is expensive and really unreasonable as it subjects the airplane structure to forces many times over what it will ever face in normal service. The goal of course, is to discover how much force it can actually withstand and what is the source and nature of the failure when it finally does occur. And the test doesn’t stop until failure occurs. Then changes are made and it is repeated.

    So what can be learned by this for software? There has long been controversy in every project it seems over what constitutes a “fair” usability test. Indeed there are many kinds of tests, each having its own objectives and methods. I suppose the premise of making a test “fair” is faulty itself or not, depending upon what you want to accomplish by it; whether to learn something or prove something.

  14. Komik Videolar Says:

    Thanks all.

Add a Comment