August 24, 2017 by SDesign
When to Say No
People in your company, no matter what it does, have all sorts of strange ideas about what UX is. Many do not appreciate that UX is deep, not skin level. If you happen to be involved in a project led by people who don’t understand the nature of good UX design, a key instrument in your toolbox has to be the ability to say no.
Let me be clear from the outset, saying no is not for beginners and probably not even for individual contributors. This tool requires strong soft skills and knowledge of internal politics. If you say no inexpertly, you’ll just come off as having a tantrum and it could have a very negative outcome for you. There are also places and situations where saying no is not a politically viable option, although usually some compromise is possible.
The reason you might want to reduce your involvement on a project is if you are convinced that the UX goals of the project will fail. Here are three common situations that you might recognize:
- The team is refusing to take UX’s advice
- A powerful stakeholder is unduly affecting the direction of the UX in a very negative direction
- Nobody can implement UX’s ideas because of time constraints, technological constraints, or incompetence.
Why does it matter whether a team you are working on produces a shoddy outcome? It’s because you (both you, individually, and you, the UX team) must be known for being on teams that produce superior work. If you routinely involved in producing finished results that are sub-par, then the reasons don’t matter, it will stick to you. You must be known for being on teams that have good outcomes, and the reputation of UX will grow.
You and your team will have failures, and that’s ok. They may be your fault, they may not be. What important is that it not become a pattern. Therefore, as a UX leader, if you find yourself in a situation where the UX of a product is going to fail, then for the sake of your reputation inside or outside the company, you need to know how and when to reduce your involvement or withdraw altogether.
What it Really Means to Say No
Talking about saying no sounds really harsh. It conjures images of a Don Draper-like Creative Director huffing into the room, getting into a dramatic confrontation with the Man, and storming out. But the essence of the process is that you broker a compromise with the project leaders to reduce UX’s involvement. ‘Saying no’ means to push back on the premise that UX is having an useful impact, and to either focus on how to increase the impact, or to focus on reducing UX’s involvement to an area where they can have an impact. It’s possible that everybody will, through discussion, come to mutually agree that there are no such areas. To say no means to take the initiative to have a discussion with stakeholders about issues that are preventing UX from being successful, and to have the courage to openly discuss the prospect of withdrawing.
When you identify that things are going wrong, your first gambit would not typically be to withdraw your services wholesale. You will usually begin to get clues before your conclude unequivocally that UX has no useful role to play. In my opinion you probably have not been doing your job if you haven’t picked up clues early.
The key is that you want to take constructive steps to remediate the situation by directly talking with the head or heads of the project. This conversation will be a frank discussion of your assessment of the team and the impact that UX is having.
Frequently a topic of the conversation will be regarding the ability and\or inclination of the team to take the advice of the designer. I have commonly pursued the following line of reasoning: “Why do you want the involvement of the UX team if their advice is going to be ignored? If you hired a programmer, would you ignore the advice of the programmer on how to code?” This will lead to a discussion of what the goals are of the project and how you and the team can move forward together on them. The discussion’s goal is to come to a mutual understanding about where UX can realistically fit. This can lead to identifying specific areas that the UX team can contribute. For example, you might agree to withdraw from active design but to perform a heuristic review on an interim deliverable. Or you might agree to become engaged for usability testing.
You may have to have this conversation more than once. You should be on the look-out for signals of success or failure, and engage the stakeholders to update them on what you are seeing. At some point, if they are reasonable people, the stakeholders may actually realize that they don’t really want UX’s help, or that the business reality is that they cannot properly leverage UX’s advice. In this scenario, you might be able to slip away quietly without any damage.
Sometimes the stakeholders may not be reasonable people, or they may be pursuing an agenda that is destructive to your team. Another common problem might be that the leadership for the project is so murky and convoluted that there are no centralized set of stakeholders to engage. At this point you may make the decision to walk away.
You may be able to quit the project without fear of reprisal from some higher power. But even if that’s the case, it’s probably not a good idea. More acceptable in the corporate world would be to finesse your withdrawal by claiming that the resources are needed on a project with higher priority. (Once I had an employee leave the company, and I simply never replaced him).
I think you can see that ‘Saying no’ is actually a quick way to describe a relatively complex negotiation. It evokes a dramatic outcome, but if done properly the conclusion will seem unexciting, even inevitable. You need to help your colleagues come to same conclusion that you have reached. In the end, you’ll be out of the project, and there will be no hurt feelings or political fallout.