No One Nos: Learning to Say No to Bad Ideas

                
                
No. One word, a complete sentence. We all learned to say it around our first birthday, so why do we have such a hard time saying it now when it comes to our work?
Guilt. Fear. Pressure. Doubt. As we grow up, we begin to learn that not doing what others expect of us can lead to all sorts of negative consequences. It becomes easier to concede to their demands than to stand up for ourselves and for what is right.
Need to no
As a user experience designer, I have made a career out of having to say No. It is my job to put an end to bad design practices within an organization before I can make any progress on improving the lives of our customers. And it’s rarely easy.
My client says, “I want to build a spaceship!” I say, “No, we need to make a kite.”
My client says, “We need to keep that space blank for my next genius idea!” I say, “No, we’ll find space for your idea once you have one.”
My client says, “I want this done tomorrow!” I say, “No, it will take a month.”
I am a human brake pad.
Each one of us brings an area of specialization to our projects, and it is our responsibility to exhibit that expertise. If you don’t know anything that no one else on your team knows, then it’s probably time to walk away. But if you do, it is your duty to assert that capability and share your knowledge for the betterment of the final product.
Mahatma Gandhi said, “A ‘no’ uttered from deepest conviction is better and greater than a ‘yes’ merely uttered to please, or what is worse, to avoid trouble.” As people who create stuff with the hope that other people will use it, it is outright cowardly for us to protect ourselves before defending the needs of our users.
When to no
When I’m incredibly passionate about something, I tend to be stubborn. And when I recognize a problem, I’m not one to keep it inside. As a result, I have had some situations with teammates and clients in which I have been rather abrasive with my delivery of a no. Fearful that I won’t be heard or understood, I have overemphasized my position to the point that people don’t hear what I said but how how I said it.
Having been made aware of this issue and given the opportunity to fix it, I can freely admit now that it was getting in the way of my ultimate goal—helping people. As practitioners in design and development, there are many common difficult situations in which we may find ourselves, and there are tactful ways to handle them. Perhaps you will recognize a few of the following.
CITING BEST PRACTICES
When you’re hired to serve a specific function on your team but are asked to do something you’re not comfortable with, often the best way to say no is to simply educate the other on best practices.
Kelly Andrews, owner of 1618design, recently received a client request to remove a quick e-mail-only mailing list signup from their site in favor of a full-page signup form.
Fearing that this would significantly decrease their number of subscribers, Andrews informed them that it is common practice for websites to include a quick subscribe since most people don’t want to spend the time filling out a form. A simple but powerful business case: The shorter option “would allow for immediate capture of interested people,” he explained. And they were sold. They hadn’t considered that before, but once they had that information, it armed them with the power to make a better choice. “The client was happy with the decision,” Andrews said. “She thanked me for being an expert and educating her instead of just doing what was asked.”
DATA REIGNS
When Samantha LeVan worked as a user experience designer at Corel, she was surrounded by a large team of engineers who were also accustomed to doing design. Most of the time, they had really interesting ideas that LeVan enjoyed riffing off of, but now and then they got stuck in the details and LeVan would have to make her case.
In one particular design, one of the engineers insisted that a drop-down component was necessary for the selection of three options. LeVan urged that three radio buttons would be more appropriate, but the engineer was unconvinced. The disagreement went on for a few days before LeVan realized that she needed data to support her case.
She turned to the CogTool—a UI prototyping tool that automatically evaluates the effectiveness of a design based on a “predictive human performance model”—developed at Carnegie Mellon University. The results showed that expert use task time was dramatically reduced with radio buttons over drop-downs. Seeing the facts, the engineer relented.
“Your opinion won’t matter,” says LeVan. “It’s important that you prove your point with numbers.”
PRICING YOURSELF OUT
Sometimes the best way to say no to bad design is not to take on the project in the first place. When Charlene Jaszewski, a freelance content strategist, was recently asked to help a friend’s brother with a website for his concrete company, she knew he had a limited budget but expected that she could help him limit the scope.
“Besides wanting ‘flying’ menus on each and every page, in a different style for each page,” Jaszewski recounts, “he wanted huge orange diamonds for the menus on the front page, and to top it off, he wanted a custom-made animation of a concrete truck on the front page and in the sidebar of every other page—the barrel rolling around with the logo of his company.” Now that just gives me shivers.
Jaszewski advised that his customers would be more interested in some relevant content, such as a portfolio of his previous work, but he was convinced that he needed lots of flashy extras to impress his visitors. And he wouldn’t give up.
Not wanting to overtly turn down the work, Jaszewski contacted animators and Flash designers, and came back with a price that was five times the business owner’s budget. He demanded a lower price, but Jaszewski just apologized and said that that’s what she would have to pay the appropriate people to do the work. Unsurprisingly, he took a pass, and Jaszewski later found out that he’d been trying to get his dream site built for the past eight years. Happily, she wouldn’t be the one to give it to him.
SHIFTING FOCUS FROM WHAT TO WHO
In April 2009, Lynne Polischuik, an independent user experience designer, was hired by an early stage startup—a private photo-sharing web app—to act as project manager to get them to launch. The product was intended to be an alternative to Facebook for parents who desired private groups of friends with whom to safely share photos of their young children.
Because the team envisioned the product as appealing to all members of the family, they wanted people of all ages to be able to use the app—including children and elderly grandparents without e-mail addresses. To allow for this, they developed a login system that relied extensively on cookies and technological trickery to provide secure access without requiring the user to enter credentials. Things were constantly breaking, and as a result, no one could log in.
Polischuik felt she had to step in. “I ended up making the argument that they needed to design not for extreme edge cases, but for the more probable, and revenue generating, ones,” she explains. “Would someone who doesn’t have an e-mail address be savvy enough to want to share images and photos on the web? Probably not.”
To sway the team, Polischuik took a step back and did some user research to develop personas to guide their decisions. Once the team was refocused on who they were really designing for, they were able to move forward more strategically. As disagreements in execution came up along the way, she would do a few quick usability tests of the proposed idea, and let the team see with their own eyes how their prospective customers struggled. By reframing the argument away from their opinions and demonstrating the negative impact on the user, the opposition was quickly defeated.
How to no
Last October while on the phone with Harry Max—a pioneer in the field of Information Architecture, co-founder of Virtual Vineyards/Wine.com, (the first secure shopping system on the web), and now an executive coach—I complained about having way too much on my plate and desperately needing someone to give me a break.
He made me realize that it was actually I who was to blame, taking on more than I could handle by not protecting my time, and recommended that I read The Power of a Positive No by William Ury.
The book changed my life.
Ury proposes a methodology for saying no “while getting to Yes.” He argues that our desire to say no is not to be contradictory, but rather to stand up for a deeper yes—what we believe to be true, right, virtuous, and necessary. And that instead of making our defense a negative one, we can frame it in a positive light that is more likely to lead to a favorable outcome.
The following may sound really corny, but bear with me. It has completely transformed how I handle conflict and decision-making.
The structure of a positive no is a “Yes! No. Yes? statement.” In Ury’s words: The first Yes! expresses your interest; the No asserts your power; and the second Yes? furthers your relationship. For example, you might say “I, too, want prospective customers to see our company as current and approachable, but I don’t feel that a dozen social media badges at the top of the page will help us achieve that. What if we came up with a few alternative approaches and chose the most effective one together?”
He advocates not for just delivering your no in that manner, but also preparing for it and following through on it in the same way. Without a plan and without continued action, your assertion is a lot less believable—and a lot less likely to work.
Some of the most powerful takeaways from the book just might help you when it comes time for you to fight the good fight.
Never say no immediately. Don’t react in the heat of the moment, or you might say something you don’t really mean. Things are rarely as urgent as we believe them to be, so take a step back, go to your quiet place, and really think through the issue at hand. Not only will your argument be clearer once you’ve had a chance to rehearse it, but it’s more likely the other will be ready to hear it.
Be specific in describing your interests. When saying no, it’s better to describe what you’re for rather than what you’re against. Instead of just maintaining a position, help the other person to understand why you are concerned and what you’re trying to protect. You may just find that you share the same goal, and can work together to find the right solution.
Have a plan B. There will be times that other people just won’t take your no for an answer. So you’re going to need a plan B as a last resort. Are you going to go over the person’s head? Are you going to prevent the project from moving forward? Are you going to quit? By exploring what you’re truly prepared to do ahead of time, you’ll have considerably more confidence to stand your ground and you won’t be afraid of what might come next.
Express your need without neediness. Desperation is never attractive and won’t get you anywhere. Present your case with conviction and matter-of-factness. Does your assertion cease to be true if the other person refuses to agree? No. So don’t act like it does. Needing the other to comply makes you look unsure and dependent, diminishing yourself and putting them in a position of power.
Present the facts and let the other draw their own conclusions. I’d venture to guess that most of the time you’re working with people who are pretty smart, pretty logical, and pretty well-intentioned. Perhaps they just don’t have all of the information that you do. Instead of telling them what to think, it is more useful to provide the necessary facts on which they can base their own judgment. Sometimes allowing the other person to feel like the decision was partially their own will help you get your way.
The shorter it is, the stronger it is. Pascal famously said, “I wrote you a long letter because I didn’t have time to make it shorter.” The longer the argument, the sloppier and less well-thought out it appears. You don’t need five reasons why something won’t work; just one good one will do.
As you close one door, open another. Don’t be a wet blanket. If you strongly believe that something shouldn’t be done, devise an alternative that the team can get behind. You aren’t helping anyone—let alone yourself—if you simply derail the project with your objections. Being a team player instead of a contrarian will help build trust and respect for your ideas.
Be polite. Ninety-nine times out of 100 we’re talking about issues of mild discomfort and dissatisfaction of our users, not life-or-death issues. There’s no reason to raise your voice, use inappropriate language, or cut anyone down. When you do, you prevent people from hearing the essence of what you’re trying to communicate. So keep your cool, be kind, and give your teammates and clients the respect they deserve. Just because you might understand something that they don’t doesn’t mean you’re a better person than they are.
Good to no
By taking pride in your work and upholding your role on a team, you will help to create a positive environment for all involved. No doubt other people will follow in your footsteps, and each person will become more responsible for themselves and for the greater good of the project. You’ll be seen as more professional, more authoritative, and more reliable.
Also consider the possibility that you may be steamrolling over other people’s ideas, and they’re too afraid to speak up. One of my favorite sayings is: “God gave us two ears and one mouth to use in proportion.” Let this be a reminder not only to say no, but to be willing to hear no, and to encourage others to do the same.