Button clicks that feel satisfying

Most product teams obsess over features. Ship more. Ship faster. The roadmap fills with functionality nobody asked for while the buttons - the things users actually click hundreds of times per day - feel like clicking on wet cardboard.

I have been thinking about button satisfaction since 2017, when our product designer Thomas Palumbo and I started a thread that turned into a months-long exploration. The original question seemed simple: could all buttons have a slight rounded edge to them?

That question opened a rabbit hole.

The real problem we were solving

The UI piece is really just about shininess for buttons. Rounded corners, consistent spacing, no longer all caps. Standard stuff.

But as I wrote in that original thread:

The UI piece is really just about shininess for buttons while the UX piece is about making it feel like you are being reacted to a lot more than the minimal work you are doing, amplifying satisfaction.

Read that again. Users do minimal work - they click a button. But the feedback should feel substantial. Not because it adds functionality. Because uncertainty is psychologically uncomfortable. When we tap on a button, we instinctively expect a response. The tiny flash of animation or color change reassures us: “you have been heard.”

Without that confirmation, doubt creeps in. Did it work? Should I click again? Is this thing broken?

Pre-click versus post-click

We identified two distinct moments that needed attention:

Pre-click hover (desktop): A spreading-shadow thing may be possible pre-click on hovering on a button with a mouse on desktop. Something that says “yes, this is clickable, and I am ready to respond.”

Post-click animated movements: For a click to feel satisfying, there should be some animated movement after the click. A shadow spreading away. A color state change. Something that makes you feel like you did more work than you really did.

Thomas got excited about this immediately. He posted a video demo and wrote:

I had something similar I have been meaning to post. In regards to actual styles I will update this thread this week with some ideas.

I asked whether this could apply beyond just buttons:

Could this sort of post-click splash apply to any field, not just buttons? I am wondering that AFTER a capture box is filled out and saved (not just clicked on) - the splash might sort of “confirm save”?

Thomas saw the bigger picture:

In addition to buttons there are tons of areas I am looking to add delight with smoother animations, how things popup, close etc.

This is where Material Design got it right with the ripple effect. Users touch a specific spot, and the visual feedback originates from that exact point. The expanding circle creates anticipation and confirms the action was registered.

Thomas referenced Material Design’s button implementation as inspiration: “Something like material designs click? Maybe faster though.”

Though as we debated internally, the ripple that always starts from the center of the button, instead of the point of contact - that is not the most natural feedback.

Watch how clicking on any given field glows quickly and then fades out.

I added this observation in a later comment:

I also think that every click in the app could do a micro-ding so that it feels super-fun to use. Watch how clicking on any given field above glows quickly and then out.

The satisfaction is in these tiny things - on every click.

The micro-ding concept

This became a running thread in our discussions. Beyond visual feedback, could we add audio confirmation?

As I wrote in one of the threads:

I also think that every click in the app could do a micro-ding so that it feels super-fun to use.

The idea was simple: imagine this one tiny micro-explosion on every click or touch you do. Not overwhelming. Not annoying. Just a small confirmation that the system heard you.

Thomas agreed: “These micro-interactions are what make the app feel polished.”

We ultimately decided this was a separate concern from button styling. I clarified:

Although note that I think there are two separate things here: 1. The buttons having polish and animation pre-click and post-click. 2. Any click at all having a little ding.

The debate about button hierarchy

Thomas proposed something that sparked debate: primary buttons in solid color, secondary buttons as ghost outlines. His goals for the task were clear:

Decide on a new button style for V2. Rounded with more space, no longer all caps, a few different styles. You will always need a primary and secondary style. A third, more generic style is good to have for actions that are less important but still need button style affordance.

Thomas’s initial proposal: rounded, more space, no longer all caps, with distinct styles for primary, secondary, and general actions.

Pravina Pindoria, our product manager, pushed back immediately:

I am not sure about the use of grey for secondary and general buttons. Imo, grey really stands out against white, and is a pretty glum color, it makes me feel serious.

She suggested using brighter colors from our palette - perhaps green or orange for secondary buttons.

Thomas had a thoughtful response that shaped our final approach:

I think the goal of the non-primary buttons is to make the primary action stand out more. We do not want it to feel too serious but we also do not want any confusion as to what you should probably click.

Look at the top example: it is obvious what path we are suggesting you should take by coupling the green button with a less in-your-face gray ghost button. The bottom example shows what happens when both options compete for attention - the decision becomes less obvious.

The psychology here is real. Research on micro-interactions confirms that when users see clear visual hierarchy, they complete tasks faster and with less cognitive load. When everything demands attention, nothing gets it.

Pravina eventually came around:

I now see and agree with this. I think the goal of the non-primary buttons is to make the primary action stand out more.

The ripple effect reversal

Here is where things got interesting. We implemented something, shipped it, and then un-shipped it.

In GitHub issue #7489, someone requested “Feedback loop (ripple) on clicking any button.” We built it. A CSS-based solution that created ripple effects on button clicks. The implementation seemed elegant. As the PR noted:

This is purely a CSS based solution, and does not affect the code/functionality in any way.

Then came issue #12466: Mouse ripple on any click. We expanded the ripple to trigger on any mouse click anywhere in the app. It seemed like the logical extension of our “micro-explosion on every click” philosophy.

And then we removed it. The feedback was decisive:

A bit unexpected and distracting.

What worked beautifully for buttons became annoying when applied universally. Users clicking on text, clicking to select fields, clicking to dismiss modals - they did not want a ripple following their every move. The feedback felt more like being watched than being heard.

This was a crucial lesson. The goal was never “ripples everywhere.” The goal was making users feel like the software was responding to them. For buttons - yes. For every surface in the app - no.

Stateful versus stateless

Thomas introduced another distinction I had not considered:

Buttons which save, complete a task, skip etc. can contain loading indicators and change states. This will make the app feel a bit quicker as well. Other buttons may be stateless and have different animations.

He elaborated on the loading approach:

The idea is that keeping the loading animation contained within the UI the user is interacting with will be less jarring and seem smoother/faster.

Think about a “Save” button. It should:

1. Respond to hover (pre-click)
2. Show a loading state while saving
3. Transform to “Saved” with a satisfying animation
4. Watch if anything else has changed so that the green “Save” button comes back to save your little changes again

That last point came from our internal discussion. As I noted:

I should also mention that technically speaking, when you go into “Saved” state, we need to watch if anything else has changed so that the green “Save” button comes back to save your little changes again - i.e. it cannot just stay in gray “Saved” state if you subsequently make changes.

The button needs to wake back up.

The sound question

We even explored audio feedback. Basecamp uses a super-mario sound when you click on “Clap.” Is this something we can or should do? If so, after which precise user events would we emit a sound?

Thomas experimented with sounds for completing a task: “Goal is to create a satisfying connection with clicking Complete. If a user clicked RE-OPEN it might play backwards or something.”

We ultimately decided: “A nice MVP would be just one sound in one area of the app, accompanied maybe with a toggle in settings for anyone who does not want it.”

This is important. Not everyone wants audio feedback. But for those who do, sound and animation feedback raises reported satisfaction by 30%, according to UX research.

Progress bars and motivation

Related to this work, we also explored progress bar philosophy in issue #10754. The question: do progress bars motivate people to continue, or frustrate them?

And in issue #12490, someone raised that completed tasks look “dull” - lacking the celebration and achievement feeling they deserved. This connected directly to our button work. Every completed action deserved acknowledgment.

The connection to workflow design

Why does this matter for workflow software specifically?

People complete tasks all day. Click. Click. Click. If each click feels dead, the software becomes a chore. If each click provides satisfying feedback, the software becomes something users want to engage with.

When you complete a task in Asana, a small checkmark slides across the screen - sometimes with a unicorn that flies by. It is not random. It is behavioral psychology. That moment of joy is what psychologists call positive reinforcement - a cue that rewards behavior and encourages repeating that action.

For Tallyfy, we wanted the same thing. Every task completion should feel like a small victory. Every process launched should feel like momentum. The micro-interactions are real psychological tools that satisfy user needs for feedback, emotion, and predictability.

You can see how we approach these details in our tutorials.

What we learned

After months of iteration, we landed on these principles:

1. Every clickable element needs three states: default, hover, and active. Most teams nail default and forget the rest.

2. Post-click feedback should be proportional to action importance. A task completion gets more celebration than a settings toggle.

3. Primary actions should be visually obvious. Use color, contrast, and animation to guide users toward the intended path without forcing them.

4. Stateful buttons require careful attention to state transitions. Save to Saved to Save-again is a common pattern that most implementations botch.

5. Audio is powerful but optional. Always provide a way to turn it off.

6. Universal effects can backfire. Just because something works for buttons does not mean it works everywhere.

What we left out

We did not ship everything we discussed. Some ideas stayed on the cutting room floor:

• Confetti on process completion: Thomas suggested “confetti after a process is completed, or a gif of someone celebrating.” We decided confetti seems overdone. Though I later said “Second thoughts - confetti sounds fine!” - we still have not added it.

• Raptorize: I found an old jQuery plugin called Raptorize that makes a raptor run across the screen with a sound effect. Tempting. Unprofessional. Still tempting.

• Sound on every action: We scoped down to just task completion because sound everywhere would be overwhelming.

• Universal ripple effects: As mentioned, we tried it and removed it based on user feedback.

• The micro-ding: Despite my enthusiasm for audio feedback on every click, we never shipped it. The concern about overwhelming users proved valid.

The hardest part of interaction design is knowing when to stop. Not every click needs a celebration. Not every action needs a sound. The skill is in choosing which moments deserve emphasis.

How this applies to your products

If you are building anything users interact with repeatedly:

1. Audit your button states. Load your app, hover over every button, click every button. Does anything feel dead?

2. Time your feedback. Research suggests feedback should begin within 100ms of interaction. Longer delays break the illusion of direct manipulation.

3. Watch real users. Do they click buttons twice? That is a sign your feedback is not confirming their action registered.

4. Respect reduced motion preferences. Some users have vestibular disorders or simply prefer calmer interfaces. Modern CSS lets you detect this preference and adjust accordingly.

5. Test universal effects carefully. What feels delightful for one interaction may feel annoying when repeated hundreds of times.

The goal is not to make software flashy. The goal is to make software that feels alive - that responds to users like a conversation rather than a monologue.

Every click is a question. Your interface should answer it.