What to Do When Your Button does nothing

Every UX designer has faced this moment: the button is there, but it doesn’t work yet.

Maybe the backend isn’t ready. Maybe the feature hasn’t been scoped. Maybe it’s just... too late to remove it before launch.

Whatever the reason, you now have a live UI element that goes nowhere.

This guide is your lifehack. Not to justify shipping broken interactions, but to help you design around them intentionally — and preserve user trust in the process.

TL;DR

If your button does nothing, don’t pretend it does. Use it to:

• Signal intent
• Collect feedback
• Prep for upcoming features

But always:

• Label it clearly
• Manage expectations
• Design with honesty

A button can say "Coming soon." But it should never say "Oops, nothing here."

Think of it this way: your UI is part of an ongoing conversation with your user. Even placeholders have a tone. Even absent functionality makes an impression. The clearer you are about that temporary state, the stronger your user's trust stays intact.

1. Understand the Real Risk

A non-functional button isn’t just annoying. It’s misleading.

When users see a clickable element, they assume it will do something. If it doesn’t, their emotional progression is predictable:

Click 1: Curiosity

Click 2: Confusion

Click 3: Frustration

If they try a fourth time? You’ve already lost credibility.

And it's rarely just the button. That one interaction casts a shadow. If a user hits a dead-end once, they start doubting everything else. "Will this screen work? Can I trust the rest of this journey?" Suddenly, even functioning parts of your product feel shaky.

We spend so much time optimising flows and polishing UI — and one misleading affordance can quietly unravel it all.

2. Ask This Question First

Is this button buying you time, or burning trust?

That single question will help you decide what to do next.

It’s a useful gut check. Are you including the button as a placeholder to manage expectations and signal intent — or are you hoping no one notices it doesn’t work?

If you're honest with yourself, the answer will often be clear.

Try asking this question with your team, too. It tends to cut through vague justifications. Everyone knows the feature isn’t ready. The question is whether the button helps or hurts while you’re getting there.

3. When It’s (Sometimes) Okay

There are valid reasons to ship a button that doesn’t fully work yet, if you follow a few ground rules:

1. You're collecting interest or intent. Like a feature waitlist.
2. The functionality is coming soon. Weeks, not quarters.
3. You've clearly labelled the limitation. Text like "Coming soon" or a tooltip.
4. It's better than hiding the path entirely. Users need to know this will exist.

In these cases, your button is a placeholder — not a deception.

4. When It’s Definitely Not Okay

Avoid fake buttons if:

1. They look functional but offer no feedback (no tooltip, message, or greyed-out state)
2. They remain broken for weeks or months
3. They replace or block critical functionality
4. They make users question the reliability of your whole UI

These aren’t placeholders. They’re trust leaks.

5. Better Alternatives to Fake Buttons

If the feature isn't ready, consider:

• Greying out the button with a clear label: "Coming soon"
• Using a tooltip or modal to explain what's happening
• Routing to a waitlist or interest form
• Removing the button entirely until it works

Just don’t leave users guessing.

6. What to Say If You Must Ship It

Sometimes the button has to go live. Here’s how to keep user trust:

1. Add microcopy like: "Feature in development"
2. Include a hover state or tooltip: "Launching in October"
3. Use a subtle visual cue: dashed border, secondary colour, clock icon

The goal is to acknowledge the gap so users don’t feel fooled.

7. Internal Rule of Thumb

Every affordance is a promise.

If you show a button, you’re telling users: “This is available to you.”

If it’s not? Own that gap. Or remove the promise.