Design is hard enough. But the stark reality is that coming up with a strong design is not the same as getting it built. To turn a design into reality, we need buy-in. Getting buy-in may only involve communicating directly with an engineering team. However, often buy-in must be achieved between several other parties before anything goes to development, such as product management, program management, senior management, and stakeholders or sponsors.
Moreover, gaining buy-in is not a one-time process. It’s true some organizations might have a formal approval process for design work. However, there are also the more mundane tactics of getting your team to agree to build out the details of your design on a day-to-day basis. This means that a considerable aspect of buy-in will almost always fall to you, the UX designer, as you work with your team during the product realization journey.
It turns out that the skills you need for design work are totally different from the skills necessary to influence others for the purpose of implementing your work. Most of the latter skills are soft skills or so-called “people” skills, rather than analytical or creative abilities. This article looks at these soft skills in detail.
One quick word about the role of the UCD process: While I stress the importance of soft skills here, this should not diminish in any way the role of usability testing or other quantifiable research that supports the design iteration cycle. You can use empirical methods to supplement any specific design, but without a good team relationship between UX and other stakeholders, no design will be properly implemented.
Personal Rapport
Designers, this might be very hard to swallow. In my opinion, the single most important dimension that affects how your design gets built is not the quality of your design, but the quality of the relationship you have with your team. The centerpiece of that relationship is personal rapport.
By personal rapport I am not talking about forging a deep psychic connection with all of your coworkers. Rather, it means finding something that you have in common, that you agree on, and that you can discuss amicably. For some people, it can be as simple as talking about the weather; other good topics are spouses, children, pets, and how your company’s stock is doing. The topic doesn’t really matter. What matters is that you find an area of common ground with your coworkers that will help tremendously if you have disagreements in the future.
Very briefly, most people in the world are extroverts. Extroverts enjoy speaking with others and they typically feel energized by interacting with their fellow human beings. Although there are less of them, there are still plenty of introverts. Introverts tend to have their energy depleted by engaging with others. I don’t know whether designers tend to be more introverted than the population at large. It is certainly possible. Regardless, building rapport with others is harder for some people than it is for others, and for some it is downright painful.
You may be reading this with a sinking feeling because you are an introvert. And you might want to discount what I’m saying because being social with others is hard. Let me tell you that most likely, I am more of an introvert than you are. And to be clear: I am not making the mistake of recommending that you build rapport because it is easy or natural. For me, building rapport is tremendously taxing. But it is a core part of my job, and I accept that.
The importance of rapport explains why employers have a love/hate relationship with alcohol. Employers hate alcohol because sponsoring its use can lead to many negative outcomes. However, alcohol is also a great lubricant for building personal relationships. Going out for drinks is a great way to get to know your fellow employees at the level needed to have decent rapport.
It is also well known that the best way to build rapport for remote teams is to meet face to face. If you can’t meet face to face, then using Skype or any other videoconferencing tool can make a huge difference.
If you want to improve yourself as an effective employee, you must make a conscious effort to get to know your coworkers, whether they are in the cube next to you or on the phone at the other end of the world. You need to deliberately engage in conversation on topics in which you can find common ground, and often these topics will not be work-related.
Trust
Ideally, all your colleagues and coworkers will love your design work on its merit, or on the support that comes from the UCD process. Sometimes they will have no opinion whatsoever, and they will defer to you because it’s your job and not theirs. Then, there is the rest of the time. Your coworkers have to trust you, and by proxy, your design decisions.
Trust is something that is built over time through repeated interactions. Trust is so important because it reduces the amount of resistance to any specific design decision that someone might object to. Even in the face of active resistance, a designer who has gained the trust of others might be able to fend off objections by saying, “Please trust me on this one.” The trusted designer will also find her or himself being questioned much less often.
The most natural type of trust between a designer and his or her teams is established as the designer proves that the work stands for itself. That is, the team and its members need to see that the designer has definitively improved the quality of the user interface the team created (See Figure 1).
Producing great quality work day after day is insufficient. The team must feel that the designer is listening to them and that he or she took into account all of the team’s feedback. However, taking into account does not mean constantly capitulating to demanding team members. Being able to articulate very clearly why one solution is better than another is a crucial skill for the designer. Showing examples of existing products using the designer’s proposed UI can be decisive. The key idea is the team must feel that you are listening to them. Inevitably, if the designer does not occasionally make changes based on the feedback of the team, the team will not feel very included.
The designer, having met many uncompromising developers with several UX ideas— most of them bad—will at this point probably object that not all ideas are actually worth exploring or responding to. There is no question that this is true. However, trust is something that occurs over time. Therefore, when a team is first forming, or the UX designer is new to the team, the amount of time spent explaining and considering multiple options should be much greater than once the team finds its rhythm. Like it or not, being a designer is about building relationships with others over time.
So far I have said that the main qualities of trust are that the designer must produce quality work, excel at explaining why certain aspects of the design are preferable, and listen to the needs of the team. The designer also must exhibit other basic professional qualities that establish trust: You must be timely in delivering work and be seen as responsive to the needs of the team in terms of producing designs when required.
These expectations can be explicit, as in, “I will have this work to you by Thursday COB,” or unstated, meaning without reasonable delay. In other words, the team must believe that if you say you are going to do something, you will do it. This probably involves going the extra mile on occasion.
Related to timeliness is thoroughness. Testers and developers in particular love to find holes in things, including UX designs. They need to understand more than the golden path: They need to understand what happens when there are zero elements, what happens when there is only one, and what happens where there are a huge number. They must understand errors, and they like to understand weird combinations of events. The golden path means the primary or “normal” ways that a user might access a product. For example, if I were designing an email application, the golden paths would be reading emails and composing an email. Paths that would not be golden paths would be more obscure behaviors, such as mobile settings or Boolean searches. Golden paths are the bulk of the functionality or the primary use cases. In design work, designing for the golden path is also called designing “hero shots.”
Clearly, in the early stages of design work, considering every possible pathway of a design is not desirable and is probably not viable either. Your implementation team needs to trust that you can think in this kind of detail when necessary. Each designer needs to learn what his or her team is looking for when it comes to detailed work. In my experience developers appreciate someone who can think comprehensively about combinations and edge cases. In my career, when I showed that I could keep in mind all the details, I gained a lot of respect as someone who understood what it took to build robust, commercial-grade software.
To explain, edge cases are use cases that rarely surface and that involve an unusual confluence of events. An example might be what happens when you try to create a folder that has 146 characters and your maximum is 132 characters. Or what happens when you want to show an error message involving the date of the email, but the date that it was sent differs from the received date because of time zone differences, or worse, because of international date line crossing.
Another way to build trust is listening to everything that has been said. When designers are showing off work, there is often a deluge of comments. Accurately capturing the comments and responding to all of them helps a tremendous amount in terms of building trust. Many designers fail to do this and omit certain details or revisions important to their team. As a consequence of this breach of trust, the designer loses respect in the eyes of their team.
A final aspect of trust, and one that has nothing whatsoever to do with your design capabilities, is that the team believes that you have their back. This can be as simple as buying donuts for people one day or greasing the wheels of the corporate bureaucracy through a connection that you have. In my own work, I very commonly get trust points by showing people how to do something they didn’t know how to do, like order a new battery for their computer, or buy a book through the corporate procurement machine. (Sometimes I will order the book myself through the machine and just hand it to my team member.) This ultimately boils down to quid pro quo: you scratch my back, I’ll scratch yours.
This it is not an oily, unsavory quid pro quo. Instead, it’s the simple things that you do when you are looking out for your peers. If your team members truly believe that you have their best interests in mind, they are less likely to question your design suggestions because they believe—emotionally, not intellectually—that you are trying to do the best for the team. In this type of scenario, developers will actually begin to volunteer to implement harder designs. They will do this not just because they truly believe that the design is better, but also because they are going all out for you, just as you have truly supported them.
To summarize, your design ideas will have a much easier path to fruition when the team believes that you are a trusted individual. They must trust you intellectually—because there is concrete evidence that you are improving the quality of their work—and also emotionally, because they believe that you are on their side. Trust also comes from the blend of many qualities, spanning emotional intelligence, good project management skills, thorough thinking, and excellent communication.
Negotiation Skills
Here is the punch line to this article: Negotiation skills trade on rapport and trust. Your ability to come to an equitable position with your team is based upon the relationship you build with that team.
If you have built a lot of goodwill and trust, your team will generally let you do your work in peace because they believe that you can deliver the goods.
Certainly, this is not always going to be the case. You may have a particularly tough team to crack, or you may have one or two personalities that are in constant conflict. Here are a few strategies to keep in mind when it comes to ongoing negotiations.
Isolation strategy
I genuinely hate conducting long, drawn-out UX reviews with a team composed of extremely opinionated people. It is excruciating to spend two hours listening to people tear your work apart, often including suggestions that do not merit even cursory examination. One way to make these meetings go more smoothly is to meet with the most vociferous members individually ahead of time.
This same tactic can be applied when you have a situation where one or more people are digging in their heels on certain issues; try to build consensus by meeting with people individually. The idea is to give each person a voice, one that is not immediately followed by multiple other voices and that spirals feverishly out of control. One-on-one meetings allow you to explain your design directly and show that you are taking the concerns of your stakeholders seriously.
If one party believes strongly against one point, you can use the individual meetings to build consensus in favor of that point. When the reviewers regroup, the dissenter will be isolated and may be persuaded to change his or her view.
Compromise
I still have a vivid, painful memory of sticking stubbornly to my guns when I insisted on a certain, high-quality design over the current incumbent. My mistake was not to insist that the existing design be scrapped; my mistake was that I would not let go of the design I had in mind. In retrospect, it is so clear to me that there were other options that I could have explored, but instead I chose to frame it as an either/or situation. This left me and a product manager very much at odds with each other, polarized in our view, and wedded to our respective viewpoints. It damaged our relationship because I was so unwilling to compromise even though I got what I wanted in the end.
The next time you are in a heated battle trying to preserve your design over an unsuitable contender, keep in mind that design and negotiation is not a zero-sum game. This is not a battle; you are not trying to win and have your opponent lose. Try to work on a design that meets some criteria your opposing colleague wants. Perhaps it is agreeing to reduce scope in some place to make the level of effort lower, agreeing to keep a certain design element and integrating it into what you already have, or coming up with a totally different option that satisfies everybody involved.
The key point is not to get locked into a specific design that you defend at all costs. If someone is suggesting a design that you think is poor, you do not need to accept it, but you should be willing to come to the table with other potential options. Coming up with a creative compromise can be just as satisfying and rewarding as having your beautiful baby implemented as is. And frequently, the compromise will actually be better in an important dimension, such as the cost to the business, complexity of implementation, or even a considerably better design.
Losing the battle to win the war
For the previous strategy, maybe you are thinking to yourself that there have been times that you really didn’t want to concede on a particular design or set of ideas that you had. And that is okay as long as you are not constantly doing this to your team. If you have been working with a coworker or a team for some time, think that you’ve built a reasonable amount of trust and respect yet are constantly getting in arguments about all sorts of things—and even the most basic use case appears to get bogged down in endless discussion—you may need to resort to conceding in low-priority outcomes.
While this is by no means the most desirable outcome, sometimes it is the only way for you to preserve the more important aspects of the design. In general, if you are constantly getting into arguments about minor details, then you will be perceived as difficult, hard to get along with, and possibly someone with an inflated ego. You need to find a way to work with your team so that every interaction with you is not painful for them. Your designs might well be superior, but the team will begin to deliberately avoid you. No one wants a situation like this; you need to find a way to be flexible enough so that work can proceed without you shooting down every single thing that comes along. This will also allow you to build up the political capital to stand your ground when something really important is on the line.
Using Your Soft Skills
I have summarized some of the soft skills that can greatly benefit any designer when it comes to influencing a team to create and implement design work. This is not an exhaustive list of ways to convince stakeholders. Using a rigorous UCD process can help influence any organization to move toward more human-centric decisions. The UCD process is, in aggregate, a specific method of persuading others; it uses data to make its case.
It is tempting to think that getting your UX work implemented as a designer is just a matter of rational argument. All you should need to do is present clean, thoughtful rationale to your peers and they will accept your work and implement it as specified. Unfortunately, anyone who has worked in a company of any size knows that decisions by fallible human beings are not made solely on the merits of design reasoning or empirical data. Much of being successful in an organization is about the relationships you take time to nurture.
In this article we have focused on three primary skills: building rapport, building trust, and negotiation. What we see is that the key to negotiation is not to master a set of devious tactics, but rather to have your coworkers on your side so that they are willing to make concessions when they don’t agree with your explanations or data. Building relationships is also an ongoing process, not a one-time effort. As your relationships mature, they will require less active maintenance. The flip side of this is that if your team changes, more work will be required on your part to build up a surplus of goodwill. The key is to identify that you need more than just raw designs skills to be successful in a world full of people. The more you can learn to use these soft-skill tools successfully, the more effective you will ultimately be.
