Typical examples: Ladda UI for Bootstrap 3.

Crazier examples: Progress Button Styles.

Screenshot of various submit buttons from Ladda UI: with a green background, with a purple background, with an orange background, and five examples with a gray background and a progress spinner

This is for a desktop app, if it matters. Consider that the target view has about three different buttons. The advantage is that the user always knows which command of a few is executing.

Also note that a button can transition into a different state: Inactive (press to execute) -> In Progress (execution progress spinner) -> Finish (happy icon - click to close)

  • I would say yes, do so, as from a usability perspective, it is best to give feedback as close as possible to the input
    – Dennis
    Commented Jun 21, 2016 at 1:51

5 Answers 5


Your button should have 3 phases if you plan on using the Progress indicator inside.

  1. Static
  2. Progress
  3. Success or Failure

Floating Action Buttons in Material Design use a similar concept. You might be able to relate to this example on Material Up.

The Static phase indicates the action to be performed. The Progress phase has a Determinate or Indeterminate progress bar, depending on the data being returned to you. The Success or Failure phase specifies the result of the action. If Success, do something.

If Failure, show a message saying [Replace with your action] Failed and allow to click on the button to perform the action again.


Go for it. One of the added benefits of showing immediate feedback in the button being interacted with is a reduction in duplicate form submissions. This can be really helpful in ecommerce instances where a double submission might result in a double charge.

Best practice would be to limit the behavior to 'positive' additions/submissions, rather than negative/destructive actions such as 'delete'. If the primary action is necessarily destructive in nature - be sure to include a 'cancel' or other bail-out action to undo the progress after starting.


It's fine to have spinner / progress indicator in a button, but try to make the button big enough and put the indicator in the corner, so that the users don't feel distracted by the spinning indicator. A good example from Facebook iOS app login page: enter image description here

  • Not sure it's a good example. The spinner is likely to be obstructed by right hand thumb for some people.
    – Den
    Commented Jun 22, 2016 at 8:13
  • 1
    It might, but I would argue that it's clear and minimal and I think the benefit outweighs. Meanwhile you can update the copy to, say "Logging in" to empathize the change. Also, you mentioned it's a desktop app, so I wouldn't worry that much for the thumb
    – Stephenye
    Commented Jun 22, 2016 at 14:47
  • Yeah I'd actually suggest this goes against the core intent, which is to clearly communicate system status. if it's really subtle/hidden the value is lessened Commented Dec 29, 2020 at 21:02

I se no problem using such a solution, but keep in mind that:

When submitted, the button shall only use the progress bar (left to right). When submission is completed, the text "Submit" shall NOT be available again, instead use that check mark indication that the submission was completed.

And, of course, Use good contrast colors and remember to change the aria-label to "Submit", "sending" and "Submitted".


Your question should be Does it help my users to show a progress indicator inside my buttons?"I'll explain why.

There is no right answer to this but you highlight some context in your question This is for a desktop app, if it matters and The advantage is that the user always knows which command of a few is executing. Why are those two statements important?

  1. You say a desktop app and it sounds like you expect certain assumptions to be drawn from that (e.g. that operations aren't limited by network speed maybe?). The reason I call this out is that you should be asking yourself, why is it important that this is a desktop app? Is it that operations complete quickly? Depending on the operation, but you should be clear about whether that is an expectation or assumption. E.g. Indexing the whole disk on a desktop app may take a long time, but viewing your profile on a web app may be quick, so you should be explicit about the use case of the button, because the context does matter to the answers.

  2. You are right that the advantage is that the user knows which command is executing. But again you should be asking why. Is is that certain operations take time, and some others aren't possible when this is happening (so you're talking about disabling others)? Is it that several (potentially) concurrent operations are possible and it's important to know which is happening? (perhaps some aren't user initiated?).

In summary, you should be really clear about what is happening, and what the value is if providing the user feedback as to what is happening. Here's two examples:


  1. If the operation is login and it's generally quick, you may want to show a logging in indicator but be aware that many times it's shown for <1 second (say) and it's a substitute for disabling the login button (or maybe in addition to?). In this context it's largely presentational and the impact of clicking twice are low, it might restart the login process but that's not the end of the world.
  2. However, if you're making a £10,000 payment, the way you respond to a click, and how you show processing might be massively different, you may want/need to disable buttons, a spinner might not be enough to let the user know something is happening etc.

TL;DR You should be thinking about what the button does, not what platform the app is deployed upon, and understanding the specific impact of failure/success of the operation on the user and the business, to find the best solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.