I’ve recently been working on a framework to help designers deal with failure. Failure can occur many times over the course of a project, and knowing how to use that failure effectively helps a team continue to work without losing steam. Over the next couple of weeks I’ll be posting the methods I’ve identified two at a time that form the framework. The goal of these posts is to gather feedback on the value of these methods, and any suggestions you want to see that will help flush them out. In other words, have a nice virtual conversation around how to scare off the bogeyman that is Failure.
Retrospective
The recent popularity of Agile has helped bring about the importance of a retrospective. Performing a retrospective is a great tool for looking back and identifying the problem areas that occurred over the course of an iteration or project. This activity can, and should, occur throughout the entire course of a project. The earlier problems are identified, the quicker they can be dealt with. This is especially important in the world of design, and software development as a whole, since the longer a problem persists the more expensive it is to fix.
Conversation Points:
- What have been some of your experiences with retrospectives?
- How did you handle the pressure when a problem area was identified that you were responsible for?
- How have retrospectives made you a better designer?
- Have retrospectives ever failed to improve things? Why?
Document Warning Signs
There is little value in identifying our failures if we don’t learn from them. Any failure can be traced to a particular step, or event, that was the catalyst the calamity. Cataloging the missteps that were the ultimate cause of a mistake is great approach to ensure the lesson hits home for a designer. Having this history both helps for posterity, and serves as an early warning system in order to avoid the same mistakes in the future. A designer should look at their book of failures as a matter of pride, proof of all the experience they’ve had dealing with issues that can come up over the course of a project.
Conversation Points:
- How do you keep track of your design failures?
- Why is it important to capture the reason for design failures?
- Should the reasons behind a failure be private or public?
- Is a book of design mistakes as important as a portfolio?
Thanks for all of your responses!
Related Posts:
