I shipped a “Save draft” button that didn’t save drafts.

For three months.

The button looked active. It had hover states. It showed a success toast: “Draft saved!” It did everything except the one thing it promised – actually save anything.

The backend wasn’t ready. The feature was planned. Marketing needed screenshots. So I left the button in with a note: “Wire this up before launch.”

Launch came. The note got buried. The button stayed.

Support tickets started rolling in week 4: “I lost 2 hours of work.” Week 8: “Your product is broken.” Week 12: A one-star review that just said “Lies.”

That fake button cost us 14 support tickets, 3 churned accounts, and one very uncomfortable client meeting where I had to explain why I’d shipped a lie.

Every designer ships buttons that don’t work. Not because we’re bad at UX design. But because we’re building fast, under pressure, with roadmaps bigger than our sprint capacity.

This is about why we ship them, when it’s actually okay, and what every fake button quietly costs you.

Why Designers Ship Buttons That Don’t Actually Work

Sometimes the UI gets ahead of functionality. Frontend finishes before backend is ready. Marketing needs demo screenshots. The investor deck demands polished product.

So you leave the button in: “It’s not wired up yet, but it shows intent.”

I’ve shipped fake buttons for:

• Features planned for next sprint (seemed harmless)
• Functionality the client insisted we show in the demo
• Placeholder UI to validate interest before building
• Empty states where the real feature was “coming soon”

None of these felt wrong at the time. They all felt like reasonable compromises.

The problem? A button is a promise.

Every affordance you show tells the user: “This is available to you.” Even if it’s a placeholder, you’re training an expectation. You’re inviting trust.

And trust has a countdown timer.

The Real Cost of Fake Buttons (It’s Trust, Not Code)

LinkedIn has a “Save” button on every post. For years, it saved posts to a list you couldn’t organize, search, or export. It worked – technically – but not in any useful way.

That’s not quite a fake button. But it’s the same trust violation: promising functionality that doesn’t deliver value.

What actually happens when users click fake buttons:

First click: Curiosity “What does this do?”

Second click: Confusion “Wait, nothing happened. Should I click again?”

Third click: Frustration “Is this broken? Is my connection bad? Is this product garbage?”

Fourth click: They stop clicking everything “If this doesn’t work, what else doesn’t work?”

That last one is the killer. Button design that lies doesn’t just break one interaction – it trains users to distrust your entire interface.

Real costs I’ve tracked:

• 14 support tickets for one fake “Save draft” button (3 months)
• 27% increase in “is this broken?” tickets after shipping non-functional export
• 3 churned accounts directly citing “features don’t work as advertised”
• 8-hour engineering sprint to fix what should have been disabled from the start

The code to remove the button? 10 minutes. The trust repair? Still ongoing.

When It’s Actually Okay to Ship Non-Functional Features

I’m not saying never ship placeholder UI. I’m saying be deliberate about it.

It’s reasonable when:

1. You’re validating interest before building

“We’re considering adding [feature]. Would you use this?” with a clear “Coming soon” label. Not deceptive – educational.

A SaaS product I worked with added “Export to CSV” buttons (greyed out, with tooltip: “Interested? Let us know”). They tracked hover rate: 41%. They built it. Adoption: 38%. Good bet.

2. The timeline is clear and short

“Available next week” with a countdown. Not “Coming soon” with no date. Clear expectations = trust maintained.

3. The placeholder gives honest feedback

Greyed out states, “Coming soon” badges, tooltips explaining why it’s disabled. Politeness plus honesty.

4. It’s better to show the incomplete pathway than hide it entirely

Sometimes showing where a feature will live helps users understand the product structure. Just make the incomplete state obvious.

In those cases? The button isn’t lying. It’s a disclosed placeholder.

When Fake Buttons Become Broken Promises (And How to Avoid It)

Fake buttons become dark patterns when:

They look fully functional but do nothing

No message. No feedback. No clue it’s broken. User clicks, nothing happens, user assumes product is garbage.

Slack had this with “Set status expiration” for months. The option existed. The dropdown worked. The time you selected? Ignored. Status never expired. No error message. Just silent failure.

They stay fake for months while users keep trying

A client I worked with left “Invite teammates” disabled for 8 months. Support got the same question 200+ times: “Why can’t I invite my team?”

Because you’re on the free plan and we haven’t built team features yet? Say that. Don’t show a button that teases functionality you’re not delivering.

They mask critical missing functionality

“Export data” that doesn’t export. “Save progress” that doesn’t save. “Undo” that doesn’t undo. These aren’t placeholders – they’re lies about core functionality.

They erode trust in everything else

Once users learn your buttons lie, they stop trusting your entire product design. Every interaction becomes suspect.

Real Examples: Buttons I’ve Shipped That Did Nothing (And What Happened)

The “Save draft” disaster (mentioned above):

• Button active for 3 months
• 14 support tickets, 3 churned accounts
• Cost: 8 engineer hours + trust damage
• Fix: Removed button, added proper autosave 2 weeks later

The “Share with team” placeholder:

• Client wanted it in screenshots for launch
• Greyed out, but tooltip said “Available now – upgrade to Team plan”
• Problem: Team plan didn’t exist yet
• Result: 23 upgrade attempts, confused users, support nightmare
• Fix: Changed tooltip to honest “Coming Q2” timeline

The “Export to PDF” button that opened a modal saying “Coming soon”:

• Seemed harmless – at least it gave feedback
• Problem: Users clicked it every time they needed export, got frustrated every time
• 40% of users tried it, 40% of those contacted support to complain
• Fix: Removed the button entirely, added export when feature actually shipped

The checkout “Apply discount” field that did nothing:

• Affiliate promo codes weren’t implemented yet
• Field accepted input, showed no error, just didn’t apply discount
• 12 support tickets: “Why isn’t my code working?”
• Fix: Removed field until discount system was ready

Pattern: Every fake button I shipped cost more in support time than it would have cost to just remove it.

How to Handle Placeholder Features Without Destroying User Trust

If you need to ship UI before functionality is ready:

1. Make incomplete state obvious

Greyed out buttons, “Coming soon” badges, disabled states with tooltips explaining why.

2. Set clear expectations

“Available January 2026” not “Coming soon.” Dates create accountability.

3. Provide alternative path

“Not ready yet, but you can [workaround]” gives users agency instead of dead ends.

4. Remove it if timeline slips

If “coming soon” becomes “coming maybe never,” remove the button. Don’t teach users to ignore your UI.

5. Track fake button interactions

If 40% of users are clicking a disabled feature, that’s validation. Build it. If 2% click? Maybe skip it.

6. Default to removing, not disabling

Better to have no button than a button that lies. Users forgive missing features. They don’t forgive lying features.

Every affordance is a tiny contract. Show it, and you owe it.

I’ve shipped buttons that didn’t work. Not because I’m bad at UX/UI design. But because design happens under pressure, deadlines, dependencies, and dreams bigger than roadmaps.

That’s okay. But every fake button starts a countdown. You’ve promised something. Now deliver it. Or remove it.

Because that button isn’t decorative. It’s a trust leak. And trust doesn’t refresh with a page reload.