8 Ways We Fail at Failing

I recently read a great article about failure on the UIE blog, it really sparked some thoughts about failure. The majority of us work from the position of trying not to fail, this sounds good initially but in reality it it puts us in the position to design/develop in fear.

When we work in order not to fail we are unable to tap into our true potential, and creative genius, most of work hoping that people like the designs that we have poured our hearts into. It is good to want to provide what our clients/bosses want and like, but is it ok to just give them what they want, or should we reach towards going above and beyond?

It is ok to fail… as long as we fail the right way…

Good judgment comes from experience and experience comes from bad judgments.

Here are eight ways to succeed at failing…

Mistake 1: Operating without a clear vision. If the team doesn’t know what direction they are heading, it’s hard to know when they’ve made a misstep. With a clear, unified vision, everyone on the team can instantly detect a failure and make the necessary corrections to the course.

Mistake 2: No introspection after each failure. There’s a natural desire to quickly move .. something bad occurs. However, it’s important for the team to resist that urge and stop to ask, “What just happened?” and “What can we learn from this?”

Mistake 3: No communication of learned lessons. On larger teams, small mistakes (and some bigger ones) may escape attention by those team members who aren’t directly involved. It’s critical the lessons from the failure are communicated across the entire team, so everyone has a chance to learn.

Mistake 4: No time allocated for iteration or experimentation. The mantra, ‘Ready, Fire, Aim’ only works when repeated. Teams exhibiting excessive optimism without planning for failures find themselves backed into a corner when something does go wrong. As in the Amazon approach, leaving time to iterate and experiment will give the best results.

“Experience is the name everyone gives their mistakes.”

Mistake 5: Inflexible platform. We frequently hear comments such as “We’d love to try that, but we can’t make our content management system do it.” Teams that lock themselves into a platform that doesn’t give flexibility will have trouble reacting when a failure occurs. Teams that build on a flexible platform (and have the skills to take full advantage of that flexibility) are in the best position to recover from a failure.

Mistake 6: Building too much before a feedback cycle. Too much code locks teams into a direction that’s hard to change. The best teams get feedback early in the cycle using a variety of quick prototyping tools. They don’t start coding until they’ve collected substantial user feedback to know they are heading in a solid direction.

Mistake 7: Not instrumenting the design. Many teams don’t think about how they’ll tell if the design is working. They launch without measures in place. The best teams conceive and build in their instrumentation from the start of the project. We’ve seen some that start with the measures as part of their vision.

Mistake 8: Not enough depth in feedback. “Was this helpful? Y/N” is an interesting question, but what does it tell the team? If a large percentage say no, what should the team do differently? The best teams ensure they are going deep when collecting feedback from users. (For example, Netflix combines both live site A/B tests with in-lab usability testing, so they can see design issues from both a quantitative and qualitative viewpoint.)

How do you view / handle failure?

I would love to hear your experiences, as well as your thoughts on failure, and how it can hurt or benefit.

~ Aaron I

Worried about 70-681 & MB6-827 preparation? We offer up-to-dated 642-437 dumps and practice questions and 70-433 dumps. Braindumps are also a great resource to get in the 352-001 dumps.

09. December 2008 by Aaron Irizarry
Categories: Design/Development | Tags: , , , , , , | 12 comments