Managing Creative Differences

Guest Author: Scott Oldham, Creative Director

I was recently contacted by a writer for Signature Magazine to answer a few questions about managing creative differences between designers and…pretty much everyone else. It’s not a happy thought: the reputation of designers is so fundamentally bad that it’s assumed a priori that we will disagree with our non-designer peers as our default position. Is there truth in this? I don’t know, but you certainly won’t find me disagreeing with it. Not me.

But respecting the writer’s premise for the sake of argument, what’s the answer? How do designers navigate the creative differences that invariably arise between themselves and, say, editors or clients?

Let me put the question into context, however: it’s not as though creative differences are rare—or even occasional—occurrences. They’re part of our job. They’re omnipresent, so navigating them becomes as reflexive an activity as breathing. Without pushback, I’m not sure I’d know I designed things for a living, rather than as a hobby.

But, to take yet another stab at actually answering this question, here’s how it generally goes. 1) Designer submits solution; 2) Someone objects; 3) Designer asks the only question that matters: why?

This seems obvious and facile, but it’s a surprisingly uncomfortable conversation to have. I don’t mean it’s uncomfortable for designers, though I’m sure almost all prefer an audience that declares love for our work and tasks us no further. No, the discomfort comes from the source of the objection.

The fault for this isn’t an absence of consideration or education, on either side. It’s a failure of language. Words weren’t designed to convey visual information. It’s frustrating to cram visual ideas into a medium wholly unsuited to represent them. And this frustration almost always translates into the five least helpful words in the English language: “I just don’t like it.”

Too often, this is where the process breaks down. Everyone believes they’re entitled to their own tastes, but nobody likes to be challenged about them. For example, we might hear something like: “Our executive director doesn’t like red,” which is patently, nakedly absurd. Your executive director doesn’t dislike red. It’s as perverse an affectation as disliking sunlight. Suddenly, an intellectual examination is transformed into a dispute over flavor: “I don’t like serifs,” or “I hate circles,” or “I have a thing about dotted lines.” There’s a story behind each of those, and the good designer knows they must be teased out if there’s any hope of providing a new solution that might also crack the original problem.

That’s another key to managing this experience: the abiding belief that there’s more than one way to skin a cat. This genuinely trips up designers. We have a flaw: we fall in love too easily. Our designs are so beautiful and perfect and correct that an assault on them feels like an attack on our children. This is clearly indefensible within a professional context, but what’s a designer to do?

Here’s how I recommend handling it:

1) React honestly. There’s no shame in feeling pain, frustration and even anger when good work is rejected. Just keep it to yourself.

2) Grieve. Your design may have taken an hour or a day or a week to execute; you’re not expected to give it up at a moment’s notice. Let the sad truth sink in while you concentrate on something else for a while.

3) Drop it. Forget it. Pretend it never existed. Don’t try to adapt it or salvage it in some way. Move on. There’s a better solution out there and it’s your job to find it.

I didn’t think to say most of that to the writer who called me, but I made a related point: the process is all. The end result is important to someone but it shouldn’t be to the creative team that developed it. It’s the process—the brainstorming, the give-and-take, even the arguments—that earns us whatever credit and remuneration we deserve.

Full disclosure: no one has ever actually said to me, “Our executive director doesn’t like red.”

It was yellow.


Posted in