One of the best things you can do for yourself as a manager is become convincing. Higher-ups, team members, other departments, customers—you name it, you’re going to be spending a lot of your time either pitching ideas, defending them, or trying to demonstrate the value of a decision.
Ironically, this is just the kind of thing they don’t teach you in school. So I thought I’d offer a little assistance.
First, a quick story I told in Experience Required that demonstrates why this matters:
In 2005, I was running a UX team and in need of another designer or two. I wrote up a job description, handed it off to HR to post to the company website, and waited for the fantastic candidates to come running, résumés in hand. The first one I got was from a guy on one of the product development teams—a programmer who had recently become enthralled by design and wanted a chance to dig in. Seemed he’d been hovering around the Jobs section of the company site waiting for just such an occasion. As soon as it showed up, he clicked the button.
I’m the type who hires from all directions. The way I see it, a person can be better at the more readily learnable aspects of UX as long as that person has the intense curiosity and other qualities so crucial for a good designer. That same year, for example, I hired someone with fairly poor design chops, but who was hooked on it like a drug and who had a cognitive psychology degree—a combination that’s pretty hard to find. I’m not afraid, in other words, to teach someone who has the built-in gusto and smarts. A designer can always get better. They can’t always grow more brain cells or become more naturally ambitious.
Besides that, I was a programmer once (a three-year case of designer, interrupted). I could identify with a guy who wanted to break out and challenge himself.
So I scheduled the interview.
He got through some of the questions well enough, albeit a bit nervously. He clearly had no design experience, but he’d been reading books and had become somewhat awestruck by the complexities of form design and the notion of making everything simpler. He was at that point where we all start—the one where he would see bad things and point them out to other people and complain about them. When you don’t know what happens next, that’s what you do—complain. It was fine. I could work with that as long as he cared.
After a while, I said to him that a lot of design was about being able to demonstrate that your recommendations are worth considering, and I asked how he approached convincing people of the merits of his ideas. He was a programmer, after all—surely he’d had to do this before.
Part of his response was a sentence that’s stuck in my memory ever since:
“Well, I’m usually pretty good at waving my arms around and screaming until I get people listen to me.”
He waved his arms around while saying it as if to prove he could. And indeed, he seemed capable of some perfectly suitable arm-waving.
I didn’t hire him, though. The arm-waving just wasn’t as compelling as I wanted it to be. It wasn’t the fluidity or style so much. It was the sheer lack of rhetoric in his response that his arm-waving was trying to keep me from noticing. If his rhetoric was a total non-starter in an interview—where he was supposed to be presenting an argument for why I should hire him—it’s unlikely he’d be able to help me convince the massive engineering team at this company that design mattered.
Why has this story been stuck in my head for so long?
Because for all the ridiculousness of this story, I haven’t met many managers who could’ve answered the question any better.
Each of the following sections discusses a piece of what I consider effective tools for persuading others of your recommendations. They lack any hint of deception. To the contrary, they’re pretty straightforward and honest, and simply need to be remembered and considered and practiced.
Before we move on, I should mention there’s a pretty great resource on the subject of rhetoric that goes well beyond what I can do here. It’s the book Thank You for Arguing, by Jay Heinrich (Three Rivers Press, 2007). It’s a quick read that introduces all the basics, and in it, the author references conversations with his kids a few times as real-life examples of rhetoric, which makes the whole thing personable, too. Highly recommended.
I worked with a design agency once that had a client who sold fencing. The client wanted the agency to design a new website that would basically serve as a brochure for the fencing company. About Us, Contact—the usual.
When I spoke to the client directly, however, I asked for a general rundown of what it was they wanted—to make sure we all agreed on what was going to happen. I asked about the client’s goals for the site. That’s when the person on the other end of the call said something a little incongruent with the agency’s assessment of the situation:
“We want to use the site to replace the brochures we use now when we’re walking around the yard with customers.”
My next question was something like, “I’m sorry, what?”
The client didn’t want a simple website. They wanted to replace the paper brochures their salespeople used with customers. They wanted salespeople to be able to walk around the yard with iPads and going over all the options a customer could ever dream about, and have the option to order things right away.
I called the account manager at the design agency.
“Did you know the client wants to put its entire brochure online and enable its salespeople to use iPads to put together estimates and submit orders?”
“Um, no, ” he said. “That would be a much bigger project than what they told us before.”
Actually, no. It wasn’t a bigger project. It was the same project the client had wanted all along. The agency just hadn’t heard it before. The guy at the fencing company hadn’t known how to communicate what he needed, and the account manager at the agency hadn’t really heard what the fencing company was after.
It was a major lesson for the agency in the value of listening. In this case, it was actual, quantifiable value. The agency had won a much bigger, far more lucrative project than they’d thought. It was thousands of dollars more valuable.
Before you can make a case for any kind of solution on a project, you need to know what the problem is. And that means listening.
Listening helps you to determine what the constraints of a project really are. What the client’s concerns and goals really are. It helps you see whether or not you already have the right argument in hand or if it needs revising.
Part of listening requires drawing out the right information. And that means asking questions. One of the key ways, in fact, to spot the most curious person in the room—the one most likely to subsequently do great work on a project—is to look for the person asking all the best questions, whether in interviews, conference rooms, or by email and phone.
Why?
First, because people who ask questions get the most information, and they get the best information. People rarely know which details of an idea or situation are going to be most relevant when trying to pass it along to someone else. A computer programmer, for example, who is intimately familiar with the programming languages used within a company can easily forget what it’s like to not know how they work. In a discussion about “technical debt” (old problems that need attention), the programmer can end up making all kinds of assumptions, leaving the other person in the dust. Asking questions means drawing out more and more of the facts that will lead to a complete, knowledgeable, useful, meaningful understanding of what’s really being discussed.
Second, asking questions helps the person being questioned think through all the details. Let’s say, for example, that a marketing person is debriefing a designer about a new campaign concept. The marketing person has one understanding, the design another. The marketing person knows the purpose of the campaign, and some basic details, but not necessarily where it will be targeted, what precisely it will try to communicate to potential customers, or when it needs to be done in order to get all the necessary approvals before launching it. A designer who asks questions can determine that all this pretty important information is missing. One who goes without asking questions will just run off and start designing, potentially creating work that completely misses the point of the campaign and shows up a week late.
Finally, asking questions is key to being persuasive because it demonstrates to the other person that you’re focused on the details. And because when there are gaps in those details, you can suggest your own solutions and help push the idea along. And once you have skin in the game, you have more opportunity to influence the outcome.
Some quick advice to take full advantage of the answers you get:
Restate them. As in, out loud. For several reasons.
Whether you’re recommending a project to your boss, a change to your team’s structure, or something else, taking the time to educate people around you on the rationale for the recommendation can make all the difference in how it’s received.
Yes, it takes time to explain things like this. It can take even more time to educate yourself well enough to know what recommendation to make. But it’s always worth it. It buys you respect, and it shows the people around you that you respect them, because what they hear is that you care enough to explain your rationale. It also demonstrates that you have a rationale —a deep, considered rationale—for everything you do. It builds trust.
In all, educating your clients and coworkers and stakeholders with every recommendation you make has several major effects.
Sometimes, your best arguments don’t mean a thing. Your clients, coworkers, and other stakeholders want to do what they want to do no matter how potent your case is for doing it another way. Your research goes wasted. Your evidence goes limp in the face of whim and obstinacy.
This is usually a timing problem (see the section “Not Just What, but When” later in this chapter). Generally, though, taking the time to explain your rationale will settle any nerves a stakeholder might have.
The benefits of education are far more valuable than the time it takes to do the educating.
In your career, you’ll get plenty of chances to explain your work—to present it—whether to your team or to other managers or departments. You might be in a conference room full of stakeholders who need to hear your proposed solutions. You might be on stage at a web conference. You might be in a meeting with a lone design manager who just wants to see how a project is developing. No matter. You should seize every one of these chances. If you’re not presenting your work, you’re throwing it over the proverbial wall where other people get to misinterpret it and decide on their own that it’s terrible. Be proactive; present it so that it is communicated on your terms.
If you can present your case well and do it up front, you don’t need to argue about it or defend it later on. Your narrative will address every concern before it even comes up.
First, remember what I said in the chapter “Saying It With Purpose”: It helps to apply an essay-like structure to your communication. When you’re presenting work or ideas to someone, that college essay structure can be pure gold. Besides giving you a template to follow, it’s a template that works well. It’s time-tested. Its structure of thesis–support–conclusion tells a story to the recipient.
To learn more about a timeless storytelling technique that can help you structure all kinds of presentations, check out Christina Wodtke’s blog post, “The Shape of Story”.
A lot of times, your audience—likely a small group in a conference room—will want to ask questions along the way. This is fine if it’s a minor question with a quick answer. But there’s always the risk they’ll nail you with something you need to think about or that a bunch of other people have an opinion about. When that happens, you can find yourself in the weeds in no time. There is no quicker way to derail a coherent argument than to let something like this throw you off.
The tip is pretty simple:
Ask people to hold their questions until the end.
Tell them to write their questions down so they can remember to ask them later, and that you’ll get to them at the end. Tell them you’ve planned for that. Then stick to your promise; leave plenty of time for them to ask.
In many cases, especially if you’ve done your job well of anticipating what questions they’ll have, you’ll end up answering most of the obvious questions as part of your presentation, making their questions a moot point. Even then, it’s practically a guarantee that someone will ask you something you haven’t yet considered. This is what Q&A is for.
If your meeting is an hour, leave 10 minutes at the end for questions. If you’re running more of a feedback or review session, leave more time.
Whatever the case, leave time. Questions are the only way you’ll know what you’ve missed.
One of the most convincing things you can bring to a conversation is evidence.
It can come from a lot of places. It can be a study you read. It can be personal observation (which becomes more credible the more experienced you get). It can be the results of a study. It can be data you recalled from a previous project that involved a similar situation as the one you’re facing now. It doesn’t really matter where it came from as long as it’s credible, its conclusions are relevant, and you can connect the dots between the evidence and your current project.
Evidence has, of course, several major benefits. For starters, it means you can make a case to yourself.
More from Experience Required:
It can become really easy over time to accept your previously learned lessons as standing truths. Not only that, but universal truths. You think that thing you leaned five years ago is not only still true, it’s true in every situation. Let’s say, for example, you once witnessed five people in a row ignore a line of instructions on a form. It’s easy to believe it will keep happening. But as you work through more and more projects, you’ll need to test this notion many times. A line of instructive text isn’t just a line of instructive text. It’ s a font. It ’s a color. It’s something a user can skip past, stuffed between two fields in light gray and a 6pt font.
It’s a visual element as much as it is text. A user’s bypassing of it is no sign of universal truth. Moved to a different spot, given a different color, its font size bumped up a notch or two, it could be just what the user needs. Displayed inside a big purple box right next to the form as the user clicks the field it relates to, it could be impossible to ignore. In a different application—one where the information the form asks for is complicated and needs to be looked up—it could be consistently sought out. Every standard has exceptions. Designers tend to think users avoid reading while they’re performing tasks. But it’s certainly not always true. And if you’re working on such a project, ignoring this fact could be a major detriment. Gathering some data on your assumptions early on can mean big differences in your design’s effectiveness.
No matter how much you believe something, data can prove you wrong. Every suspicion, every assumption, every guess can be validated or debunked with a little research. And the last thing you want is to recommend a false truth. When you feel like you know you’re right, take some time to make sure. See if the studies covered in articles online still back you up. See if the data you have access to can verify your belief.
I can’t tell you how many times—especially early on in my career—I learned something only to unlearn it later. The older I’ve gotten, the more I’ve recognized that there are no hard and fast answers. Every decision you make is a guess. Your job is to mitigate the risk of that guess as much as you can. If you’re unsure about something—if you are sure about something—find evidence to prove it out, one way or another. This will give you a great deal of confidence about your recommendations. All you have to do to convince someone after that is relay the facts.
Hence, my second point:
Data helps you make the case for your recommendation to everyone else, especially after you’ve vetted it yourself. Remember: This book is about how to lead as a UX professional. If you’re out front with all the facts in your hand, and you’ve considered your recommendations, and you can demonstrate their validity, people will believe you. They’ll believe in you.
Finally, putting evidence up for examination with every recommendation you make will build your reputation over time. It’ll become easier and easier to get past whatever obstacles you face now. The objections. The politics. People will learn they have a trustworthy source of reliable, accurate information in their midst, and they’ll come to rely on it rather than their guesses.
This will take a long time. But if you stick to it, it will work.
Always point to evidence. Always have evidence to point to.
Communication is always incomplete. Short of climbing inside a person’s brain, you’ll never get all of what they mean to say, nor will you ever be able to fully predict all of what you need to say to be 100 percent understood. But holding yourself accountable for as much of it as you can will certainly change the nature of your conversations. If you walk into every interaction with the idea that it is your job to be complete, your job to understand the recipient’s needs as well as your own, and your job to receive information as well as you deliver it, you will put yourself in a position to lead.
Don’t take this lightly. Every business depends on communication. To be good at anything, you’ll need to be good at this.
If you can think clearly, you can communicate clearly. And if you can communicate clearly, you can lead. Because communicating well buys you something you can’t get in any other design deliverable:
Trust.