Don’t Say This to a Designer
I have worked with numerous designers, developers, managers and other team members of all shapes and sizes. With some I’ve developed lasting friendships, with a few I have developed lasting white hairs. But we were all trying to do only one thing: make the product better. Unfortunately, good intentions don’t always translate to helpful comments. Here’s some things you’re better off not saying to your designer and what you can do instead.
“Can you make that bold?”
“Like designers, if you give a programmer a problem with parameters, they’ll apply every bit of genius they have to solve it in the best possible way. If you tell them how to do it, you’ll suffer the wrath of an angry God.” — Derek Powazek
But unlike programming, design is a collaborative process that benefits from constructive feedback.
So do tell your designer what you honestly feel. Raise questions about the interactions, talk about scenarios they may not have thought of, point out inconsistencies they might have compromised on, comment on the feel and the style if it doesn’t feel right. Your feedback can bring in a new perspective and help a lot. What doesn’t help however, is when somebody tries to micro-manage instead of explaining the problem.
You are looking at a new design and it looks great but it is painfully obvious to you that that heading will look better if it is bold. So you tell your designer to “make that bold”.
What you don’t know is the context. Are the headings like this on all other screens and will making it bold here break the consistency? Are there complex visual hierarchies the designer has maintained? Will the clarity of some other element be sacrificed if she makes it bold? Did she already try it in bold and decided regular was the best balance? Is she already aware of the problem you are trying to solve but made a conscious trade-off for some reason?
Now, in most cases she will ask you why you think it should be bold and if the problem is legit, suggest a solution that fits best. But if you do this too many times (especially if you’re in a managerial position), she will start picking her battles and give you the smaller changes. This sucks for everyone because it sucks for the product.
So what should you do? Just frame the feedback better, that’s really all. Instead of telling her to “make that bold”, tell her that you don’t think the title has enough emphasis, or that the headings don’t stand out enough and then let her decide what to do about the problem. Also be ready to support all your feedback with arguments and examples.
A lot has already been written about how to give constructive Design feedback. Check out the footnotes for some links.
“There were some problems with the design; don’t worry I fixed them.”
Never ever make design changes in the final product without consulting the designer. This is the worst thing you can do and you’ll instantly earn your designer’s absolute distrust. It is as if a designer took your production-ready code and made some changes because things didn’t feel right. The small changes you make on the fly might seem small but they will accumulate. If you’re not satisfied with a design, talk to the designer. Give them honest, constructive feedback and trust them to do their job well.
Side note for managers:
If you’re in a managerial position and find yourself making changes at the final stage without consulting the designer, that’s a symptom of a larger problem. If you have been giving your designer constructive feedback but still aren’t satisfied with the final designs, you need to either have an honest conversation with them or find a designer you can trust. You are paying them to do a job and if you have to do it instead, there’s no point keeping them around. If you don’t have the time to provide feedback and go through the iterations, you are about to lose even more time fixing the haphazard fixes later (these can accumulate really quickly, trust me), plus you will end up iterating in product cycles instead of at the design level.
“Will moving that button 5 px to the left really make a difference?”
It’s our job to sweat the details. Mis-aligned UI elements is the stuff of our nightmares. But that’s not why you should care about those 5 pixels; you should care because every one of those 5 pixels strewn around the product accumulates and reflects on the final feel. Can you tell the difference between the millions of shitty-looking apps in the stores and the few high-quality, well-designed ones? Well, each of those painfully 5-pixel-aligned buttons contributes to making those high-quality apps look that way.
“Nope, can’t be done.”
Say that it will take too much time, more than the deadline permits. Say that it will lead to compromises in the code. Say that it’s not a priority. Say that you don’t think it’s worth the time to figure out how to do it. All of which can lead to a conversation rather than shut it down.
There’s nothing more frustrating than repeatedly hearing “That’s not possible” every time you want to try something new. We all want to enthusiastically build the best product. That involves going to 100% polished not just 70% functional. I realise that too much AfterEffects and Photoshop can sometimes keep designers out of touch with real-life constraints. If that is the case, please remind us of the limitations of the platform or framework. As designers we can dream up wonderful things, but we rely on your brilliance to help make these dreams a reality.
Designers, feel free to correct me if I have generalised unfairly or left something out. Developers, I welcome tips on what designers can avoid to get along better with you.
- How to Work with Designers: A Cheat Sheet for Engineers and PMs
by Julie Zhou on Medium
- Design Criticism and the Creative Process
by Cassie McDaniel on A List Apart
- How to Give Designers Better Feedback
by Dennis Field on InVision App Blog
- UI, UX: Who Does What? A Designer’s Guide To The Tech Industry
by Lo Min Ming on Fast Co Design
This is the first time I am writing about Design and will hopefully get better so please give me feedback. Thanks to all the wonderful developers, PMs and founders I’ve worked with and learned from!
Published in #SWLH (Startups, Wanderlust, and Life Hacking)