I recently had the pleasure of being a guest on Jeff Parks i.a. podcast. This was my first time being both interviewed and recorded, and kudos to Jeff for making it an awesome experience! The conversation we had revolved around failure and why it’s so important for designers. The topics include concepts I brought up in my three part posting on the importance of failure, and feedback we received on the wiki he set up. Thank you to Christian Crumlish, Daniel Szuc, Jan Jursa, Valeska O’Leary, and Eric Reiss for that feedback btw! You can listen to the podcast either here or via iTunes. Hope you enjoy!

In the final part of this series on the importance of failure, I’ll be getting a little philosophical on the subject. Part 1 and Part 2 covered some practical means to take advantage of failure. The final two methods are meant more to change the mindsets of both individuals and organizational leadership to encourage an environment that takes full advantage of failure. Failure always has a negative connotation to it, and these final two approaches are perfect for finally putting a positive spin on the subject.

Embrace Failure

It’s a natural human response to put up our defenses once something goes wrong and we are deemed at fault. This response normally comes out as a series of excuses, attempting to divert the blame to others, or just hanging our head low while the situation steamrolls everyone over. A better response would be taking control, and asking questions like ‘What could I have done differently?’ or ‘What did I miss that lead to this?’ Not only is this the more professional, but it can jump start the conversation towards finding possible solutions.

Conversation Points:

• What kind of policies should be in place to encourage failure?
• How serious does a failure need to be before serious action needs to be taken?
• How does traditional damage control fail to inform project teams and designers on how to avoid the same mistakes again?

Open Minds and Open Ears and Open Hearts

Negatively responding to someone who has made a mistake does nothing to resolve the overall issue. In fact, it makes the whole situation that much worse. Keeping an open mind that everyone screws up every now and then, listening to what lead to the failure, and supporting someone in picking up the pieces greatly is whats need to  improve the situation. This is the keystone to turning everyday design failures into a positive aspect of designing.

Conversation Points:

• What was the worse project/design review you’ve had that did nothing but point out all the flaws and didn’t offer any tips for improvement?
• How do you empathize with a peer on their failure, but still maintain a sense of authority?
• Obviously, there is such thing as failing too much and too often. Where should this line be drawn?

This closes the proposed framework on how to deal with failure as a designer and use our failures to ensure the work we do tomorrow is a vast improvement to the current ‘disaster’ that is causing so much heartache today.

In Part 1, I showcased the first two methods for dealing with failure and learning from it. Part 2 will focus on activities that can be during a retrospective, or stand alone. These next two methods have a certain risk associated with them due to the emotions that can arise during the resulting conversations. If done successfully however, the passion these emotions invoke can help solidify the lessons that are available to be learned.

Assign Blame

There are some that believe that a single person can shoulder the responsibility of an entire project. The truth is though, whether a project is large or small this is impossible. The responsibility of a project is a partnership of the team, even if it’s a team of one, and the sponsoring client. The advantage of this shared sense of responsibility is that when something goes wrong it’s possible to pin point who was the cause. There are many dangers associated with calling someone out, but if done in a respectful and constructive manner it can be a great motivator.

Conversation Points:

• How have you dealt with being call out when you were responsible for a project failing, or an aspect of the project going a-rye?
• Have you ever had to assign the blame to a project member? How did you approach them?
• What are some safe ways for assigning the blame to someone?
• Does the emotional risk outweigh the possible benefits of pin pointing the person responsible for a mistake?

Highlight the Success

All this talk about failing and finding faults in people can eventually become too negative. No project is a complete and utter failure. Shedding light on the successes helps give the team, and the client, a positive view on the overall value of a project. It helps bring the team back together, and if the client is involved it makes them feel better about investing in the project. Talking about all the stuff that was a success helps to mitigate the negative emotions that may have popped up over the course of the conversation as well. Yes, Bob might have delayed the project a week due to a database issue, but he really hit a home run optimizing the database making the app super quick. In the end, a nice pat of the back goes a long way.

Conversation Points:

• What is more difficult, highlighting failures or successes?
• What is the proper ‘reward’ for someone being responsible for a big success?
• Should highlighting a person’s success be public or private?

Related Posts:

Part 1 of The Importance of Failure for Designers

Part 3 of The Importance of Failure for Designers