This is another of my attempts to clear out my drafts folder. I started writing it on 3 August 2011 (So long ago!). Still seems relevant.
Let’s talk about critiques, or as engineers call them code reviews. I am going to start with a major caveat: I do not have a design degree. I spent two years pursuing a degree in Industrial Design before changing my major. These are insights I gained during those years and during my career since then.
Also every time I mention Critiques, if you are a developer insert the words ’Code Review’. They are the same thing after all.
With that out of the way let’s get down to brass tacks. Critiques are an essential part of our practice, and we should be cautious in ignoring them. We only know what we know, and critiques provide us an opportunity to reevaluate the things we thought we knew. That is critical to our development as designers, coders, and the quality of our work.
When I was studying Industrial Design we had weekly formal critiques. The kind where you pin your work on the wall explain it quickly and then sit back while everyone discussed it. We also had many informal critiques as we talked to fellow students and professors. These critiques were critical to our development. We were able to identify things that were not working, and then ways to correct them.
The formal critiques rarely resulted in others sketching ideas for ways to improve our ideas. But, the less less formal peer critiques often did. Sketching was the easiest way to convey what could be better. It was the clearest way to communicate concepts.
Part of being a designer, or engineer, is being able to examine our own work through the lens of others’ eyes. We have to be able to cut the parts that don’t make sense and identify the areas of improvement that will help our design. Without them we limit the quality of our work to the finite realms of our own experience.
Top comments (0)