Design as a problem-solving activity can never, by definition, yield the one right answer: it will always produce an infinite number of answers, some "righter" and some "wronger". 
 - Victor Papanek, Design for the Real World​​​​​​​
We all know there's more than one way to skin a cat––though some ways will be more difficult (and messier) than others. The same goes for designing a toaster; of the limitless options, no single form or mechanism is the correct answer to designing something that toasts bread. The ultimate toaster design is not out there, like some undiscovered chemical element, waiting to be realized––it doesn't exist.
When I first started working as a product designer, this underlying uncertainty––that a design would never be definitively "right" or "wrong"––was a source of unease. Not only were there no right answers, there was no longer a guarantee that a feasible solution to any particular problem existed at all. After so many years of engineering school, of growing accustomed to working primarily on prescribed problems with defined answers, this was unnerving. The security and satisfaction of converging upon one right answer was nowhere to be found. I had to adopt whole new way of thinking about "rightness" and "wrongness"–– which took some practice.
When you pick up a hammer for the very first time, you can't be certain that the hammer isn't going to just fall apart on the first swing, or that you'll even hit the nail; but with practice, trust is built in both the tool and in your ability to use it. Similarly with design, after every effective cycle of ideation, prototyping, testing, and iteration, and with every successful problem-solving effort, confidence is gained in both the process and in one’s ability to implement it. However, there's no getting around the uncertainty––there's always the risk of failure, of ending up at one of the "wronger" answers. 
Failure is key to what makes the design process so powerful, and fear of failure can bring the process to a full stop. It's by failing quickly, often, and cheaply––by breaking prototypes, by repeatedly challenging our assumptions and decisions, and by iteratively re-designing what doesn’t work––that we move closer and closer towards the "rightest" answer we can find. ​​​​​​​
Back to Top