I got this blog post by a great design mentor I decided to follow very recently.
As I read through the very interesting article, I was really laughing my heart out.
It just brought memories of a similar article I put up on my blog some time ago.
When I was in full employment, I’ve had to fight, on several occassions to convince my bosses 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. Enjoy it…
“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.
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.
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.
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.
Written by Nathan Barry
Feel free to share your experience in the comments. I’d really love to hear it.