How to Criticize Design
Just the other day, during a Q&A at a conference, the moderator said “you hate everything.” With a nice tone of voice, since I’m also giving useful info, but it has quite stuck with me.
Mostly because the top three most Important People at the same conference were seen as really positive speakers, but I — and I happen to know, many others — saw a lot of backhanded insults. Tired old tropes like how we’re wasting time drawing comps were rolled out when: hardly anyone draws “comps,” but many of us do design specifications, and there are good reasons to do so and lots of reasons we can’t — or shouldn’t — just go straight to code every time.
That’s as good as an insult to the hundreds of thousands of practitioners who draw, and believe in drawing. So, why are they considered positive speakers? Because it’s backhanded, instead of out in the open maybe?
The Hard Truths
I’m writing another book, and as I get from many editors, I am regularly accused of being negative there a lot also. Since I don’t do backhanded insults, I don’t think I am just a big meanie. But I think it’s because I am trying to be clear, and effective.
I don’t actually personally hate any design solution, but have found out a lot by doing research, and reading even more how well things work. I have data. I can tell you, in detail and with links to resources to find more about it, why something we’re used to doing all the time is a terrible, terrible idea. And so I tell you that critical, key information.
That works. People remember these, and they make better designs. Because the other data we all have is that people absorb the first thing they see, or you say.
This is a well-known issue with news reporting. The headline is what is remembered, even for people who read or listen to the whole article. So if I had a talk that said “help topics are important” and buried halfway through that the “FAQ” format and style is downright insulting to users, that key info would be forgotten. A lot of the people who saw and remembered my talk would go off and write FAQs, as that’s a category of “help topics” which I said to do.
So, I tend to lead with “the bad news” because that’s the important part, and is what the baseline knowledge is that needs to be modified or discarded. You’ll remember that. Then, I’l tell you the good part, how to design the right way, and if you forget that… well, you remember NOT to do the old way so are pretty likely to go look up the right way then.
Just like here. In another paragraph or so, I’ll stop saying the bad parts, and start getting into how to perform criticism — of process or design — the right way.
Criticism isn’t Critical
I regularly encounter people, or posts, that refer to all criticism as bad. That criticism 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 history, the foundational thinking, and 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 design criticism of interactive products) is a bit different, in that there are absolute truths and needs underlying everything. Design school doesn’t teach this (I took plenty of Design classes as well, and they are too often checkbox, by-the-book solutions, without history or context).
Art (at least the way I was taught, and practiced 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 the way it was, and why I make myself stick to it. Another way to think about this is in this post 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.
The Danger of Avoiding Criticism
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.
How to Give (and Receive) Design Criticism
More often than not, clients — and too often, designers — reviewing design work 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.
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.
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 sign on process.
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.
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 so insist it be taken over all other data.
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.
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.
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.
Everyone's opinion is equally valid. But it is just their 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.
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.
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.