Looks great! Lose the duck.

Looks great! Lose the duck.

duck /dək/

duck /dək/ noun: an element added to a product design for the sole purpose of drawing attention and directing scrutiny away from other elements – specifically to appease meddling managers.

This idea has become a part of the software development canon. Like many, I first learned of it from Jeff Atwood’s classic post on programmer jargon:

This started as a piece of Interplay corporate lore. It was well known that producers 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.

A Wasted Opportunity

I will freely admit it’s a funny story and clever problem solving. And honestly, it’s an experience that most seasoned developers and designers can empathize with.

However, it also feels unnecessarily hostile and dismissive of other members of your team. It reminds me of the way I’d manipulate a young child by giving them the illusion of power.


Me: It’s cold outside. You have to wear a jacket, gloves, and this horrible itchy scratchy scarf that you hate, okay?
Child: NO! I’m not wearing that scarf!
Me: Oh, alright, fine. No scarf this time, if you get dressed quickly.

While that’s okay for getting your five year old out the door on time, it’s much less okay when you’re working collaboratively with other adults to solve problems in a professional setting.

At Simple Thread, we have a weekly continuous learning meeting on Fridays where we discuss books and topics around building digital products. This idea came up in one of those meetings, and I’m happy to say that others on our team shared my distaste for this idea.

It’s not just that doing this is arrogant and dismissive. It’s not just that it’s a colossal waste of time and effort. It’s also that it’s a tremendous wasted opportunity.

Why Does It Happen

That said, we also can’t pretend this doesn’t happen. In a long enough career, you will inevitably encounter this situation where someone outside of the creative process compulsively changes designs. If it’s wrong to distract the manager with a duck, what’s right?

Well, let’s go back to the origin story:

The assumption was that subconsciously they [the producers] felt that if they didn’t, they weren’t adding value.

That’s interesting. We’re not saying the meddling project manager or producer has bad intentions. We’re saying they want to feel valuable.

I think that’s right. People want to feel valuable, feel like they are making an impact. People want to feel like their work has meaning. If you sit through a design review meeting every week and nothing is changed in that meeting, why do we even have that meeting? If the world is no different after a meeting, then a status update email would suffice.

So if the reason for last-minute meddling is that people want to have input and feel valuable, then what if we try to involve them more not less?

What to Do Instead

Instead of concocting elaborate schemes to distract and manipulate, we should strive to seek their input earlier in the process.

This can cause problems of its own:

  • Asking for input takes effort and can slow down the process.
  • If people are not aware of their own limitations, they may get offended if you routinely disregard their input.
  • Involving too many people in design can lead to watered down design by committee results.

More fundamentally, is asking for input when you don’t really want it truly more honest or respectful?

Reasonable people can disagree somewhat, and asking for feedback is definitely an art. But ultimately, I think asking for an opinion is better than inventing a misdirection. The difference is that by asking, you are opening the door to legitimate feedback and legitimate influence. You are giving them the chance to surprise you and change your mind – a chance to prove their value.

If you are inventing questions, then it’s no better, but you don’t need to invent fake questions. When you are designing a system, you are making dozens of decisions every week, small decisions where there are often multiple good options. Make a list of those and ask for feedback when appropriate.

You could either save this list of small decisions for the next review meeting, or if that’s a big group affair where you don’t want to spend that time, just fire off an email or quick chat to the manager who’s feeling a need to show value.

Briefly describe the problem, the options you’re weighing, and an argument for which you think is best.

There’s a decent chance they’ll bring context you weren’t aware of, and the design will improve as a result. But even if they just agree with your recommendation, they now feel some ownership. They’re not just reviewing the design; they’re involved in the design process.

Valuing Design

When done well, you are not only making them feel valuable; you are also educating them on the many factors that go into a design decision.

You are making them see the value of design – see your value and the invisible work underpinning the visible output. You are helping them understand why arbitrarily changing designs is frustrating and often has unforeseen negative effects. In extreme cases, you can turn an adversary into a champion.

There will occasionally be people with bad intentions or people who just want to seem important, but most of the time, when somebody is annoying you with design tweaks and change requests, it’s because they are legitimately trying to improve the end result. They are striving to add value to the process and don’t have a better outlet.

Instead of looking for ways to distract them like they’re a fussy toddler who needs to feel valuable, we should look for ways to channel that energy into constrained areas where they can truly be valuable.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (1)

  1. The article completely misses the point of what the duck is all about. Sometimes testers or management don’t feel that they’re doing their job properly unless they find something wrong. Even if the new feature is faultless, they still feel compelled to find something that needs to be fixed so they can feel satisfied that they’ve made a difference. This is where the duck comes in. If the only thing they can find to complain about is the duck then the developer has obviously done a good job. So the duck is removed and everyone is happy. The ‘duck’ should be something really easy to add and remove, it shouldn’t be a huge additional effort. The duck should not be used as a diversionary tactic to deflect attention away from real bugs. No developer worth their salt would do that and no tester worth their salt would fall for it.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All