The Art of No
Just a thought from 2 May 2006 about Design.

Being a designer is all about embracing the word "no." When we sit down with a blank slate and a job to do, we have to say "no" over and over again. Choosing a primary audience means saying "no" to all the others. Picking a task to enable means saying "no" to all the other possible tasks (or, at the very least, deprioritizing them). Selecting a font, a color, a photo ... almost every decision we make is about selecting the best option and saying "no" to the rest.

As a result, we can be a pretty grumpy bunch. We learn to be hard on ourselves and each other in design classes and reviews. Ask a designer about the design of something and we're emphatic. "I can't believe they chose that font," we'll say. "Anyone who would letterspace blackletter would steal sheep." "That photo ruins the page."

But what nobody ever teaches us is perhaps the most important thing you can learn to be a successful working designer: How to not say "no." If I could give one piece of advice to the designer just getting into client work, or even some who's been doing this for a while, it's this: The next time you want to say "no" to a client, boss, or colleague, say this instead: "Why?"

Here's the scenario. A boss hears a criticism of his site. Somebody doesn't like the way something works, or looks. The fix is obvious to him, so he says to his designer: "Go make this change." The designer knows better, and says no. This is a conversation that happens in every company with a website at one point or another.

Here's how the conversation looks to the boss:

Boss: "Hey, I think we should do this totally reasonable thing."

Designer: "No. That's a horrible idea and I'm offended that you'd even mention it."

At this point the boss has two choices, both of which suck. Choice 1: He can walk away feeling stupid for asking. It's the rare boss that likes feeling stupid, so he will more likely select Choice 2: Make it an order. And since no designer likes being ordered around, the designer walks away angry, implements the horrible idea, and decides to find another gig as soon as possible.

Wash, rinse, repeat.

Here's where the "why" comes in. What if we substituted the word "Why" for "No"? Let's look at the conversation from the designer's vantage:

Boss: "I think we should do this totally idiotic thing."

Designer (wants to say "no" but instead says): "Why?"

Boss: "Because Bob from accounting said he had a hard time accomplishing this task."

Now the designer has something to work with. Maybe Bob is not a member of the audience the site has been designed for. Or maybe the task he's trying to accomplish is something the team decided not to support. Or maybe Bob's using an unsupported browser. Or maybe, just maybe, the designer has something to learn here. Either way, the added information can only help.

When a client comes to me with a specific design request, I often ask: "What problem are you trying to solve right now?" To the client, the problem was so obvious, they just skipped it and went right for the solution. But we designers know that there's always more than one solution to a problem, and all solutions will have different ripple-effects. It's our job to keep the entire site, every page and every feature, in our heads at all times. We have to do this to keep our eyes on the user experience we're creating. Making a quick fix may solve one problem, but create more.

I know my clients don't want to be designers – that's why they hired me. And even though it may seem like they're making design choices for me, they're really just trying to solve a problem using the only language they know. It's my job to deconstruct the request, and that takes more information. If I can get the client to verbalize the problem they're trying to solve, we can come up with a better solution together. I can talk them through the ripple-effects that come from any solution. In the end, my client gains a better understanding of the role of design, the site gets a better solution, and I don't feel like I've been micromanaged to death.

Of course, it would be nice if the clients and bosses of the world knew how to frame design requests with what they're trying to accomplish, but let's face it, entrepreneurs and bosses aren't doing what they're doing because they just love to communicate and compromise. They're people who are used to fighting for their vision. They tell people what to do for a living. It's our jobs, as designers, to coax information out of them. And if we want to be successful in our jobs, and in our products, we need to teach them a little bit about the design process.

When you say "why" instead of "no", you open a design conversation that can help inform both sides. You also make it more likely that the boss will ask you questions in the future, which is all designers want. We'd all much rather hear, "Why did you make this design choice?" than "I don't like this – change it."

Don't get me wrong: designers still need the ability to say no. After all, we're hired to do a job specifically because we know how to do something that the boss doesn't know how to do. A designer without the word "no" in his vocabulary is going to produce a crappy product. This isn't about rolling over – it's merely a technique to work better with the people who give us interesting things to design. But if you've got a dictator for a boss who never listens to you no matter how hard you try, pack a box. Life's too short and there's plenty of good design to be done elsewhere.

And, in the end, being open to the "why" of things is the way to become a better designer. Every design request comes with a kernel of truth. Yeah, maybe Bob's out of the target demo, or doing the wrong thing, or using the wrong browser. Maybe he's just an idiot. But if he's having a problem, no matter how small, chances are more your users are, too. And the best way to learn from that, to make a better design, to become a better designer, is to ask one simple question and then open your ears and just listen.