“I don’t like it”—The most dreaded of all design feedback from your client/boss/co-worker. This isn’t so much a matter of your ego being damaged, it’s just not useful or constructive criticism.
In order to do better we need feedback grounded in understanding of user needs. And we need to be sure it’s not coming from solely the client’s aesthetic preferences, which may be impeccable but may not be effective for the product.
Aesthetics are a matter of taste. Design is not just aesthetics. I’m always saying it, but it’s worth repeating: there are aesthetic decisions in design, but they are meant to contribute to the design as a whole. The design as a whole is created for an audience, and with goals in mind, so objectivity is required and should be encouraged.
Is the client offering an opinion based on her own taste, trying to reflect the taste of the intended audience, or trying to solve a perceived problem for the user? Don’t take “I don’t like it” at face value and try to respond to it without more communication.
How do we elicit better feedback?#section1
To elicit the type of feedback we want from clients, we should encourage open-ended critiques that explain the reasons behind the negative feedback, critiques that make good use of conjunctions like “because.” “I don’t like it because…” is already becoming more valuable feedback.
Whether that audience can achieve their goals with our product is the primary factor in its success. We need clients to understand that they may not be the target audience. Sometimes this can be hard for anyone close to a product to understand. We may be one of the users of the products we’re designing, but the product is probably not being designed solely for users like us. The product has a specific audience, with specific goals. Once we’ve re-established the importance of the end user, we can then reframe the feedback by asking the question, “how might the users respond?”
Throughout the design process, we need to check our hidden assumptions about our users. We should also ensure any feedback we get isn’t based upon an unfounded assumption. If the client says the users won’t like it, ask why. Uncover the assumption—maybe it’s worth testing with real users?
How do we best separate out assumptions from actual knowledge? Any sweeping generalizations about users, particularly those that assume users all share common traits, are likely to need testing. A thorough base of user research, with evidence to fall back on, will give you a much better chance at spotting these assumptions.
The design conversation#section2
As designers, we can’t expect other people to know the right language to describe exactly why they think something doesn’t work. We need to know the right questions that prompt a client to give constructive criticism and valuable feedback. I’ve written before on how we can pre-empt problems by explaining our design decisions when we share our work, but it’s impossible to cover every minute detail and the relationships between them. If a client can’t articulate why they don’t like the design as a whole, break the design into components and try to narrow down which part isn’t working for them.
When you’ve zeroed in on a component, elicit some possible reasons that it might not be effective.
Reining it in#section3
Aesthetics are very much subject to taste. You know what colors you like to wear, and the people you find attractive, and you don’t expect everyone else to share those same tastes. Nishant wrote a fantastic column about how Good Taste Doesn’t Matter and summarized it best when he said:
If you’re making suggestions, don’t let a client say yes to your first one. These suggestions aren’t meant as an easy-out, allowing them to quickly get something changed to fit their taste. This is an opportunity to brainstorm potential alternatives on the spot. Working collaboratively is the important part here, so don’t just go away to work out the first alternative by yourself.
If you can work out between you which solution is most likely to be successful, the client will be more committed to the iteration. You’ll both have ownership, and you’ll both understand why you’ve decided to make it that way.