Monday, January 11, 2010

How to Criticize Design

I regularly encounter people, or posts, that refer to all criticism as bad. That it stifles creativity, especially for us sensitive artsy designer types. I could hardly disagree more. Criticism is a key part of discovering new ideas and working collaboratively. I am not brilliant enough to get by without help from others.

This opinion comes partly from my art school experience of all things. In general, I think art school was the best education I could have gotten. Not for the art per se, but for the criticism parts. After the first few years, getting the basics of the craft down, I had to (regularly, more than once a week) present my work, ask for opinions, accept them and act on it for the next review. This taught me presentation skills, public speaking and an ability to think critically and rationally (not just emotionally) about my work, others' work and what others have to say about mine. Yes, rationality, logic and business-like skills from art school.

Design criticism (and especially interaction design criticism) is a bit different, in that there are absolute truths and needs underlying everything. Art (at least the way I practice it) allows for individual interpretations. If your experience means you see something differently than I do, that's usually fine. For design, as a general rule, it is important that everyone understand the functions and the intent of the communications in the same manner. Individual interpretations that vary from the designer's intent are generally a bad thing. Design criticism is much like the peer review process. While scientifically-backed (theoretically, everything is confirmed by existing best practices or user research) there is additional help in having others... actually, Wikipedia has a great summary of this:
It is difficult for authors and researchers, whether individually or in a team, to spot every mistake or flaw in a complicated piece of work. This is not necessarily a reflection on those concerned, but because with a new and perhaps eclectic subject, an opportunity for improvement may be more obvious to someone with special expertise or who simply looks at it with a fresh eye. Therefore, showing work to others increases the probability that weaknesses will be identified and improved.
Even the simplest system I have worked on in the past decade is so complex I can't hold the design in my head (and I am pretty good at this). The genius designer only goes so far, which is why my design documentation was created, and why I make myself stick to it. Another way to think about this is in this posting about reviewing for journals:
In the early years, critique is about identifying holes and mistakes that make ideas less plausible. In the later years, critique is about identifying the germs of ideas worth development despite the current holes and mistakes.
In this sense, the value of critique is not unlike that of the concept reviews and brainstorming your may have done with the designers when they first came onto the project. Your critique (assuming the schedule allows for it) is not just to tweak the design, but to discover whether there is something totally brilliant or totally different hiding somewhere in there.

Design presentations to clients, and the critiques that inevitably follow, are all too often avoided, or are held with everyone defensively braced. Ideally, I have almost no big formal critiques, and share regularly. This doesn't always happen though (scheduling, remote work, etc.) so the big review is still a part of my life. I like to plan for them, and specifically ask for input from clients and others. I like to know my limits, and if something cannot or should not be determined by me or my team (e.g. there's a good creative team at the client) I'll leave that for them. And I prepare by putting together a good presentation, knowing the topic as well as possible, having answers or options for any decision that might need to be defended and bringing along any other designers who might know certain parts of the system better.

More often than not, clients reviewing design either focus on the wrong thing (the colors!) or seem overwhelmed by the massiveness of the whole project, and just sit back and let it wash over them. As much as it's easy for me to not have to defend or revise anything, I like feedback, and need it to make sure the best product is going out the door. As a reviewer, and especially as a client reviewing design you have paid for, here's my ten tips for participating in a design review.
  1. Look at the product. Review it as the designers wish you to. Feel free to take notes, but let the review be completed (whether a self-directed website walk through, or a presentation) before offering any feedback. Whether it's a complex product, or your needs mean the presentation is out of first-time-user order, or the designer is just not that good as public speaking, you often will need to see the whole thing before you understand it fully.
  2. Encourage everyone else to do the same. That is, take notes and wait till the review is over. Short circuiting this in meetings especially means you might not even get to the good parts, and spend the whole time arguing about the terminology of the signon process.
  3. Follow up with details. Email is a great way to send more thoughts. Whether something didn't occur to you at the time, or you are just a junior flunky and didn't get a chance to speak up in the meeting, written commentary is useful. But do it quickly, before other changes are made or you forget the rest of what you saw.
  4. Express your personal opinions on how you might use the product. User research is just lots of personal opinion and observation, codified, so if nothing else your opinion can be slotted into existing knowledge, and explained. The "worst case" is that it's a brainstorming sort of point, and something else good can still come of it. Don't, however, believe that your experience is necessarily of key relevance.
  5. Relay anecdotes about use or understanding. Don't spout pithy sayings "my mom couldn't handle this" but do cite specific cases that seem relevant. Whether it's the first impression of someone looking over your shoulder, or just what your heard some people say about the competitors product, that you worry this doesn't do, it's okay to bring it up if it hasn't been heard before.
  6. Quote solid information. Even if it's "just" a marketing study or three year old use statistics. Ideally, the designers already know this, but if not it's definitely time to bring it up. Even if they do, explaining that you have concerns about the design because of specific background information is a useful place to start a serious discussion.
  7. Express personal opinions on style, aesthetic, etc. These might be trumped by brand standards, or consistency, or some other design needs. But bring it up. You might have found a hiccup in the standard implementation, or something else that needs to be fixed.
  8. Everyone's opinion is equally valid. Just opinion. If they have data to back it up, that's different and usually trumps opinion. Even if you are the VP of everyone in the room, and authorize payment to the design agency, your opinion is still opinion. Your employees (and the vendor) were presumably hired because they are good at their jobs, so trust them to say useful things.
  9. Allow the designer to counter your input. Don't feel sad about it, because it's not personal. If they have solid research, or experience, then think about trusting them on it. My guidance, whether reviewing other designers' work or talking to clients, is "if you have a good-sounding story, I believe you." Assuming you trust the guys you hired to do this work, you don't have to understand what they say, but do make sure they sound like they understand what they are saying. Treat design like anything else you pay good money for, and trust their well-founded argument.
  10. Review the changes later. Designers forget stuff, or don't understand, or might make a new solution once they get back to the office. This is another reason you should write everything down. Don't nag, but if you thought you understood that something different was going to happen, ask why. And feel free to ask for clarification; "we think" should be able to be followed up by "because of user research that indicates [something specific, with numbers]."
As a general rule, don't be this sort of client, but do take ownership of the product. Offer the feedback that your position, background and knowledge of your business provides you.

No comments: