“My boss always has to change something about my designs.”
A friend of mine, who is a relatively new designer, was discussing his job with me the other day. I laughed. I’d encountered the same issue dozens of times.
I would bring a new design to my manager for approval and he would look it over and say “Looks great! Let’s start coding it …except change _______.”
That’s okay. I didn’t think my work was perfect in the first place. But often I didn’t think the suggested change would improve the design. In fact, it would often make it worse. I would argue against the change, and often win, but it was wasted time. Also, why was there ever only one thing wrong with my design?
Some designs ought to have three or four things wrong with them; others should make it through the approval unchanged. But the number of changes was always one. Huh.
This made me come to the same realization that my friend complained about: My boss always had to change something. That’s what was frustrating me so much.
I think managers, product owners, and other people who don’t directly create products find a need to leave their mark on it. Maybe they need to feel like they are part of the process or that their feedback is meaningful. Either way, it was wasting tons of time because often their suggested changes had huge implications. Instead of tweaking a color or some simple spacing they would suggest new layouts, changing the user flow, and worse.
But once I recognized the pattern, it could be fixed.
Intentional Flaws
Breaking managers of this habit seemed too daunting a task. If they must make a change, let’s control what change they make. When left to chance the change could result in many hours of extra work. You’re a designer, right? So don’t leave things to chance.
Add an intentional flaw that is easily “fixed” when they point it out. Things like spacing issues, color changes, or extra elements work well. Make it obvious enough that it can’t be missed. You want their approval to sound like, “Looks good, but change that color.” Your response is always, “Oh, you’re right! That would look a lot better.” Then hurry out of their office, make the 30-second change, and move forward with your newly approved design.
The Duck
After sharing my method with a few developer friends I was told about “The Duck,” which is a fantastic example.
It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.
The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: He gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.
Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “That looks great. Just one thing–get rid of the duck.“
Intentional flaws can work really well. I know they’ve saved me and my team members dozens of hours.
Note: if you are in a position to approve design work, think through if you always make one token change. If so, why? Then change that behavior. If elements can be improved, point them out. Otherwise, approve the design as is, without having to add your personal touch to the project.
Accepting Feedback
This doesn’t mean that all feedback should be ignored. In fact, some of my best design work has come after pushback from a client where I thought they were dead wrong. In order to finish the project I went back to make their changes and ultimately came up with something far better than the original, not because I implemented their feedback verbatim, but because I found a way to incorporate their changes while still improving the design.
More often than not, being forced to take another pass will improve your design, even if the feedback wasn’t all valid. So if you are getting legitimate feedback (i.e., not just from a change-one-thing-every-time manager), be humble, listen carefully, and take the opportunity to further improve your work.
Changes, Approvals, and Deadlines
In software development changes should be able to come at any point within the development process. After all, we are trying to create the best product possible. But there’s a downside: Changes mean extending deadlines. Again, that’s fine, except when your manager doesn’t agree that the deadline should be extended.
The problem we would have was that I would send a design to get approved and receive an email back saying, “Go ahead.” Then I’d start working with the development to get the new feature implemented. Part way through the process, the manager would take another look and want to make changes. Since we were working in two-week sprints, those changes could often really throw off the development timeline. Then there was often a discussion as to why we were late shipping the feature.
At one point I had three other designers working on my team, so changes would affect them and eight to ten developers as well. We needed a better system in place.
What I started doing was printing off the new designs and walking them into my boss’s office. After he looked them over I would give him a pen to make any changes. If there were none, I would request a signature and date on the design.
This served two purposes:
- My (very busy) boss didn’t have to dig in his inbox to find my emails. A quick, in-person approval would take just a few minutes right then. Approvals come much more quickly.
- If later someone wanted to make a change, I could point back to my approved design (with a signature). This was not to say we wouldn’t make the change, but to make it clear that changes would affect the development time. The message was clear: You approved this design and I told you how long it would take to build. Changes to the design will change the timeline.
There’s Something About Paper
Never show up empty-handed. There is something about having paper with you that adds credibility to your argument. A friend offers any official looking papers when he tries to enter a new country without a proper visa. When you have something, people are more eager to help turn that into the correct thing.
So I used the paper approvals to back up my case in project planning. It works wonderfully and is well worth the cost in dead trees and color ink.
Do you have a project management tip or story? I’d love to hear it in the comments.
This kind of thing is really annoying sometimes. I don’t imagine this happening with a doctor for example. But as a designer I always faced this kind of issue. And your point is right. POs, PMs and everyone who manage creative teams not actually create something but they usually say like they have it.
I guess is up to the new designers whenever and if they become managers please don’t act like this.
Managing several designers and coders, I approve designs all the time. Most of the time, I approve it without change since I’m not a designer and on the face of things, it looks right and functions well (I also work with great designers). If I change things, it’s usually because I wasn’t clear enough at the time of spec, since I often allow designers to have free reign.
A quick one edit change is a sign of “needing to add to the process,” but mostly it’s because they don’t take the time to sit down and go through the scenarios the design will be used in. That’s a very shallow review. Also, what may appear wrong at first glance may not be bad at all, but understanding why that person thought that, will reveal a lot about how that person thinks about things for future reviews. I often sit down to write critiques only to realize what the designer had in the first place is probably a better solution overall.
Agreed with your points Mike. Managers need to back up design changes with data or other unique insight they bring about customer preferences, or else they are just wasting peoples time. It’s a poor reflection on management if they feel the need to make some cosmetic change to feel like they added value.
Every problem is a people problem. Managing managers (stakeholders, whatever) is just the same. We “fixers” tend to think that what we’re *really* doing is fixing a problem or building a new thing, but that’s rarely how the people hiring us look at it. They’re the star of their own show (just like we’re the star of ours), and they are doing it for their own reasons. Often those reasons have to do with feeling good about their contribution, looking good at work, leaving a mark, as you say, or CYA, etc.
If you don’t understand that, and don’t want to deal with it, then being a consultant or employee is a bad career choice!
I feel that hacking the review process is a very bad practice. The relationship with a “superior” in the role of reviewer, should be of mutual respect. If that is not the case, and the manager let’s you change things even though you do not agree, you are in a bad relationship.
You should not defend your designs. You should embrace your choices, and show the options you explored. When there is feedback, you should have a decent discussion about it. It helps you to be a better communicator. Discussions will get shorter. Relations will get better.
Own and open up your progress. Check in with the manager while designing. Make him feel like a part of the process and he will respect you more.
And stop complaining about doctors not getting this kind of stuff. They save lives. We design. Firefighters aren’t complaining that “designers never get burned” either.
Haha, I love the intentional flaw.
Bosses have egos and sometimes you just have to play into them. If you don’t want to – start working for yourself. Much better anyways :)
Great article and even better advice. I’ve already tested this with my boss and it always worked out.
You should have written this article earlier, would have saved me time and nerves. ;-)
I am stunned to see the same mindset of this practices as mine.
Cool article. Reminded all my experiences.
This rejection experiences always makes you learn the another way of achieving the results.
Thanks a lot to writing this. It will be really guide & inspiring to all those new designers who are fade up with rejections.
Hey Nathan, I was really laughing my heart out as I read this post. I’ve had to fight, on several occassions to convince my boss with my design, I was tagged “STUBBORN.”
I tell them in simple terms that there is nothing like saying “a design is not good.” It would be better to ask to understand a concept than just condemn the whole effort outright. I don’t have any problem with constructive criticism, but I sure have an axe against destructive criticism. Good work.