Evaluation: critique

As part of evaluation, critique gives you a structured way to discuss usability issues with the developer of a system. Aim to give and receive feedback in positive way. Be kind, though. You don’t need to put the recipient on the defensive (although that takes skill and practice).

A quick overview

Where heuristic analysis typically happens without having contact with either developers or users, critique is ideally more of a dialogue. It gives a designer the opportunity to hear criticism and ask “why?”.

In a well-run design critique, the designer presents what they have been working on, explaining who it is for and what it is meant to do. The  audience then critically assesses it in this context, i.e. it is definitely not meant to be a personal, judgemental attack!

Carrying out heuristic evaluation first may provide a good set of questions to take into a critique session if you’re reviewing someone else’s work. On his or her own, an evaluator using heuristics may identify issues or reach conclusions that can in fact be clarified through simple discussion. Perhaps there were certain constraints on a project. Perhaps some way of representing data, while seemingly difficult to use, is actually conventional and expected.

But critique is even more important for the designer. If you’re close to something all the time, you know all the quirks and gotchas. It can be very hard to set away from something and assess it objectively. A well-intentioned critique can give you a fresh perspective.

Andrew Harder (experience strategist and design researcher), back in 2010, recommended:

The anatomy of critique (preferred):

• “fillets” the findings (just give the main points, not everything)

• gives designers creative authority

• engages with the design intent

• interpersonal (i.e. face-to-face, not written)

• makes everyone feel smart

• talks about design

Importantly, critique (at least, as far as I’m concerned) is not simply likes and dislikes, nor a list of complaints. It is an honest, open discussion of the “what” and the “why” of a system, and it is meant to be helpful (not unpleasant!). Amongst other great advice, experience designer at MadPow, Adam Connor, recommends that “critique should have good intentions”. 

It isn’t necessarily a problem-solving session or brain-storming, either. That can use up a lot of time. Present perceived issues and invite dialogue and discussion. But let the developer think about solutions.

Resources

Inspirational designer and educator, Jon Kolko, recently wrote “Do you want critique or a hug? How to gain valuable criticism on your design” (goof timing, Jon – thanks!) and Cassie McDaniel has a nice article on A List Apart titled “Design Criticism and the Creative Process“.

An article from 2011 that I found very influential was Mark Boulton’s “A better critique for web stuffs” (which includes some nice “how to” ideas). Mark also later wrote in more depth about how his art school training taught him a lot about critique: “It’s not working for me:#crit“, which is great.

Aaron Irizarry and Adam Connor have a really good slidedeck online: “Discussing Design: The art of critique” – I’d love to learn from those guys!

Scott Berkun also has a very informative, in depth article, “How to run a design critique“. There’s a related video, too – “Feedback without frustration“.

At the tutorial I ran at Vizbi 2014, we used the 2×2 method (find two things to keep, two things to change) and the Ritual Dissent method, both of which I learned from Will Evans.

[June 2015] See also the Google Ventures Guide to Critique (thank you, Rachel!) and this great article on Design & Redesign in Data Visualisation.