How I learned to say no to requests without becoming “the difficult designer”

Hi 👋

For a long time, I said yes to almost everything.

A new colour for the CEO’s favourite button. A last-minute change for a sales demo. “Can we just add one more field?” I’d say yes, do it that evening, and feel quietly annoyed about it for the rest of the week.

It wasn’t that I didn’t have opinions. I just didn’t know how to say no without sounding like I was protecting my design instead of helping the team. And nobody wants to be the designer who makes every request a debate.

Building something on my own this year made it worse before it made it better. When every email from a user feels like a request, and there’s nobody else to say no for you, you either learn to sort them or you build everything and finish nothing.

Here’s what I wish I’d known earlier. Five things that made saying no easier for me, and, I think, easier for other people to hear 👇

1. Sort requests by who they help, not who asked

This is the one that changed the most for me.

Most of us sort requests by how loud they are, without meaning to. The CEO’s comment gets done today. The sales demo gets done by Friday. The three support tickets about people getting stuck at checkout wait, because nobody’s chasing them.

When I started putting requests on a simple sketch like this (how loud is it, and how many people does it help?), the answer was usually obvious. And it was usually the quiet one.

What it means for your work: the requests that matter most often come from people who don’t know how to ask: users who give up and leave, or a support person who mentions it once in a channel.

Try this: list everything you’ve been asked to do this week and put each one on the sketch. You don’t need to show anyone. It just makes the next conversation easier.

2. “Not now” works better than “no”

A flat “no” ends the conversation, and people remember it. “Not now” keeps it open.

I keep a short list called “Later”. When someone asks for something that isn’t the priority, it goes on the list, and I tell them it’s there. Most people don’t actually need it done this week. They need to know they were heard and that it won’t disappear.

(Every few weeks I look at the list again. About half of it nobody mentions ever again, which tells you something.)

Try this: next time you’d normally say “we can’t do that”, try “that’s a good one, I’ve added it to the list for after X. Can it wait until then?”

3. Ask what happened before you answer

When someone asks for a feature, they’re usually describing their solution to a problem you haven’t heard yet.

“Can we add an export button?” sounds like a feature. “What happened that made you want to export it?” often turns it into “I needed to send the numbers to my accountant”, which might be a much smaller change, or something that already exists and just needs to be easier to find.

What it means for your work: half of saying no is finding out that you didn’t need to. Once you understand the problem, you can often say yes to a better version.

Try this: before you answer the next request, ask “What were you trying to do when you thought of this?”. Then listen for a while.

4. Say no with a reason that isn’t about you

“I don’t think it fits the design” is about you. “If we change the checkout this week, the fix for the people getting stuck slips to next month” is about everyone.

It’s the same no. But the second one gives the other person something to decide with, instead of something to argue with. Sometimes they’ll still want their thing first, and that’s OK. At least now it’s a real trade-off, and everyone can see it.

What it means for your work: people push back on opinions. They rarely push back on a clear trade-off.

5. Say yes to small things on purpose

This one surprised me.

Saying no gets much easier when people have seen you say yes. If a request is small, cheap and makes someone’s week better, I just do it, quickly and without a fuss. It’s not giving in. It’s earning the trust you need for the next “not now”.

The designers I’ve seen get away with the most “no”s were never the strictest ones. They were the ones people knew would help when it really mattered.

If I had to sum it up: saying no isn’t about protecting the design, it’s about protecting the time for the work that helps the most people. Most of it comes down to asking a few more questions and being honest about trade-offs. (And it helps to keep a list. It’s always the list.)

What’s the hardest request you’ve had to say no to? Hit reply and tell me how it went, even if it’s just one line. I read every one.

Things I liked this week

🛠️ A tool: A UI library your AI agents can build with.

P.S. Here’s what I’m building

A calmer way to run your freelance business.

Brisk helps you give clients a professional experience: from the first agreement to the final payment.

See what I’m building →

Thanks for reading Balint’s Newsletter! Subscribe for free to receive new posts and support my work.