How to say NO as a UX designer

Saying No is not about being difficult or not being seen as a team player.

Believe me, I am not the best at saying no, in fact, I am a bit of a people pleaser because I prefer to avoid conflict. And I found that this two-letter word is like an instant conflict starter. Over time I realised that saying no is not going to lead me to disappointing my team members or stakeholders, but quite the opposite. By saying no I am setting up healthy boundaries and therefore setting myself up for success. Overcommitting, burning out, half-done work; are the things that come from only saying yes and these are the things that lead to disappointing team members and stakeholders. That’s why I believe learning to say no is a sign of seniority. It’s a skill that can be learnt.

But even still, No can be such a harsh word. Stakeholders and team members might not respond well to being told no directly. Here are a few other phrases that might help you stand up for yourself and put some healthy boundaries in place:

That’s not our current focus, but let’s make a note of it and discuss it later.

Often meetings and discussions with team members and stakeholders can go down a rabbit hole or just round and round in circles. It’s our job as designers to bring direction to the conversation. Sometimes these discussions do result in great suggestions, but more often they can just derail everyone’s focus.

We can change our focus to include abc but then we can’t deliver xyz within the same timeline we originally agreed on.

or

Ok, I hear that you think this is important. Which item takes higher priority?

There are scientific studies that prove multitasking makes us less effective. So rather than say no to another item added to your ever-growing to-do list. Raise the fact that you are more efficient if your focus isn’t split over 20 items and rather have a discussion about timelines or priorities. As UX designers we all have our process that we follow with specific deliverables that aid our UX journey and understanding. When these types of situations come up it’s important to verbalise where we are in our process and what deliverables they can expect and how this will bring value and clarity to the project.

Let’s think about it from the user’s perspective

Often as designers, we are fielding suggestions that are very narrow and only consider the business requirements or development restrictions. Instead of just saying no that’s a dumb idea and upsetting everyone. Turn it around and ask a question, help your team and stakeholders consider how the user fits into this. How can the business requirements be adapted to provide value to the user and the business? When it comes to development restrictions what other ways could we approach the problem to still give the user a good experience despite the obstacles you might be faced with.

I hope this helps give you some ideas on how you can stand up for yourself, your project or your team without sounding too harsh and uncompromising. Just remember there are times to say no and then there are other times where you should rather try and reach a compromise, knowing the difference is another skill that can be learnt and perfected.