lovehistory.net

“Design Criticism and the Creative Process” had rules that I think can be applied across the board for giving (and receiving) critiques, even if what you are evaluating/presenting is not a digital history project. This article took a very interesting approach in that it did not detail how to give critique (advice on that involved reading between the lines), or how to react (passively) to it, but instead it advised its readers on how to participate actively with the critique they are receiving in order to make it most useful to their project.

At this stage in our academic careers, it seems to me that many of us have adopted at least some of these tactics, whether through direct inculcation of instruction or through trial and error in our own creative processes, but it was nice to see them laid out here, and there are a few important ones I will keep in mind while receiving oral criticism on my project presentation.

For example, the point that most caught my eye was the bit on “Taking it personally.” I believe McDaniel’s suggestion to bring it back to the question of audience, i.e. “Will the audience like purple?” to be a very effective and relevant way to deal with this kind of design issue (or critique). At the end of the day we are producing a product for users whose needs and opinions might end up surprising us, but it is still their projected needs that we are attempting to address with our projects and in our designs. Reminding those critiquing and being critiqued of this fact strikes me as a good way to bring everyone back into the room and to refocus on the functionality of the site from user-driven perspective. These personal observations can still be useful, however, which McDaniel doesn’t delve into in this paragraph. Another tactic might be to ask the “critiquer” why the purple is so distracting – is it truly that they just loathe the color, or do they find it distracting in some sense that might also repel your users or make your site less navigable?

I also liked the idea of attempting to “put the other person in your shoes.” Most of this article seemed to have a subtext that sought to advise on how to avoid becoming defensive or disheartened in the face of criticism. Asking someone to evaluate your design from their perspective strikes at the heart of collaboration, and I’ve also found it’s when people become most responsive and generate the most useful insights while participating in a creative dialog.

Another point McDaniel’s makes when speaking of a indecisive critique is to back up your argument with good logic. I think it’s important to remember that in a process of critique, part of the role of those offering criticism is for them to flag parts of your project where you might not necessarily have good logic, or a logic that seems inherent and/or clearly expressed to you may not be so obvious to those critiquing your project, and therefore, may also be lost on the user. This lack of clarity does not make your project invalid, but it is important for others to point out their own confusion when it arises in order to help you strengthen and clarify whatever is lacking. This insight can provoke new lines and of thought and reasoning that may never have occurred to you, or allow you to re-articulate/re-design something in a way that allows you to get your point across more clearly.

Of course, in certain cases it is okay to simply decide that a critique is not something you are going to incorporate in your project (which may be more difficult if it is coming from a client or boss as opposed to a peer). But I think we all know how important the process is, no matter how nervous it might make us. I think the point of this article was to give creators tips for handling the stress that arises from situations involving presentation and critique by demonstrating that the presenter can control or direct the critique and does not simply have to be subject to it.