How to handle a button when a user can't yet take action

[dsnair]

Hello team 👋🏽 ,

I am building the UI page attached below.

Our usecase is that the customer can only cancel an active plan. For other status values, the customer can't take action via the button. What is your best UX recommendation for the button in this scenario? (Eg: should it not be displayed? should it be disabled, etc.?)

Also, we would like to display a helpful message on when that button would be enabled. Where do you suggest we put that text on the page? (eg: as a help text under the status? show an enabled button but it renders an error message when clicked like it says in the docs?)

Thanks for both your recommendations!

cc: @jsheppard-twilio

[TwilioPasteBot]

Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary.

---

Hello! Based on the guidance from the Paste documentation, here are the recommendations for your scenario:

1. Button Visibility and Interaction:

   • It's recommended not to disable the button because a disabled button doesn't communicate why it is disabled or how to enable it. This can be particularly confusing and not very accessible, especially for users relying on assistive technologies.
   • Instead, you should keep the button enabled and show an error message if the user clicks it when they're not supposed to. This approach provides immediate feedback and explains why the action can't be completed, which is more informative than simply disabling the button.

2. Displaying a Helpful Message:

   • For conveying when the button would be enabled (i.e., under what conditions the user can cancel their plan), it's advisable to use help text or an error message upon button click. This aligns with the guidance to avoid disabling buttons and instead inform users about why an action can't be taken or what conditions are not met.
   • Placing help text directly under the status or near the button could be effective. This text should clearly state the conditions under which the button will be enabled (e.g., "This option is only available for active plans.").

3. Code Snippet for an Enabled Button with Error Message:

   • While the exact implementation would depend on your application's structure, here's a conceptual approach based on Paste's guidelines:

     <Button variant="primary" onClick={handleClick}>
       Cancel Plan
     </Button>

   • And in your handleClick function, you could check the plan's status and display an error message if the action is not allowed:

     const handleClick = () => {
       if (planStatus !== 'Active') {
         // Show an error message to the user
         alert('This option is only available for active plans.');
       } else {
         // Proceed with the cancellation
       }
     };

   • For displaying the message, consider using the Toast or Alert components from Paste for a more integrated and accessible user feedback experience.

Remember, the key is to provide clear, immediate feedback to users about why an action is not available and guide them on how to proceed. This approach enhances the overall user experience and accessibility of your application.

For more detailed guidance and components usage, you can refer to the Paste documentation:

• Buttons: https://paste.twilio.design/components/button
• Toast: https://paste.twilio.design/components/toast
• Alert: https://paste.twilio.design/components/alert

I also did a search, and I managed to find these other Discussions that might be similar or related to your question. Give them a read to see if they answer your question. If they do, head back here and update this discussion and mark it as answered, pointing others to the related discussion:

• Guidance on using the disabled state for buttons (updated: 06/14/2022, similarity score: 88%)
• Badge colors for status (updated: 05/07/2025, similarity score: 86%)
• Button positioning for Conversations UI kit (updated: 05/15/2024, similarity score: 86%)

[dosubot[bot]]

For your scenario, the Paste design system recommends that if a button is not actionable (for example, "Cancel Plan" when the plan is not active), it should be immediately clear to the user why the button is disabled. If the reason isn't obvious, it's better to show the button in its default (enabled) state and provide a helpful error message after it's pressed, rather than disabling it without explanation. However, if you do disable the button, you should clearly explain what needs to happen for it to become enabled, ideally right next to or below the button itself. This approach helps with accessibility and user understanding [source].

A common and effective pattern is to display the disabled button with a help text directly beneath it, explaining when or how it will become enabled (for example: "You can only cancel an active plan. This action will be available when your plan is active.") [source]. This keeps the context clear and ensures users know what to expect.

Avoid hiding the button entirely, as this can confuse users about whether the action is possible at all. If you choose to keep the button enabled and show an error on click, make sure the error message is clear and appears close to the button.

In summary: show the button in a disabled state with a clear, concise help text directly below it explaining when it will be enabled. This aligns with Paste's accessibility and UX guidelines.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[serifluous]

@waijeeho Do you have any thoughts here since you might understand the customer scenario better?

[dsnair]

Hi @waijeeho,

Thinking ahead, we have our next feature work lined up where the "Cancel" button would change to a Menu with certain actions available in the dropdown.

The original question still stands as to how can we inform the customers that they can only "Cancel subscription" when certain conditions are met and what can we do with the sub-menu item in that case? I found an example in the Paste doc here where a sub-item can be disabled. If this is recommended, where/how do we render the info text?

Thanks!

cc: @jsheppard-twilio

[waijeeho]

Hey @dsnair - thanks for raising the question. Makes sense to think about an approach that will work for the menu button stage in the future.

Couple of follow up questions for you Divya:

Our use case is that the customer can only cancel an active plan. For other status values, the customer can't take action via the button. What is your best UX recommendation for the button in this scenario?

• How long do we expect a user to be in the Activating and Cancelation scheduled states?
• If a subscription is in the Activating and Cancelation scheduled states - we are not allowing the cancel action, are we similarly not allowing upgrade?

Here were the general options that we have, right:

A. Change the Cancel subscription / Change subscription button to the loading state,

• If the Activating and Cancelation scheduled states are relatively short-lived - thinking in N seconds long, but this doesn't work if the states are several minutes - days long.
• Seems like Cancelation scheduled might be a multi-day state.state, but not sure if Activating is shorter.

B. Enable the buttons and add error message after click.

• This seems releatively straightforward option we can easily do. Probably could use a toast as the feedback triggered by the button click?

C. Disable the buttons and add a helper text under the button describing why it is disabled.

• Works for the longer-lived states.
• Compared to option B where we show an error response after clicking the button, the advantage is that user doesn't have to attempt to do the thing before being told they can't do it.
• Was suggested by the Pastebots. @serifluous - I've used this pattern in other parts of the console before, but I don't actually know that this is a good pattern to be following. Could you weigh in here?

D. / E. Disable or hide the buttons in Activating and Cancelation scheduled states (no additional changes)

• Let's see if the previous three above might be solutions before opting to disable/hide. Disabling or hiding UI doesn't reveal to users the reason it is hidden, or how to get to a state where they can use it, so would like to push this to last resort territory.

[waijeeho]

Linking design file with the various options and some notes. If its easier, feel free to comment in the file: https://www.figma.com/design/WvGXGstXC5TAKy5VSnGgOC/%F0%9F%9A%A7-Orders?node-id=3995-54236&t=15nyI5dqgWXyJRJT-1

[serifluous]

I think Option B is the most straightforward and scalable option, especially considering this Button placement will eventually become a Menu.

imo for the "Cancellation scheduled" state, I DO think it's appropriate to hide the Button—though, yeah, it depends on how long the state would last. By "scheduled", is it trying to say that the plan will end after the current billing period? Or is it saying that the system needs some time before it can even put the account in a cancelled state?

Option C is fine, but not the most elegant and gets a little tricky when the Button eventually becomes a Menu.

[dsnair]

Thank you both for enumerating all possible options! Some of the trade-offs lines up with what I too was thinking. Now that I know that @waijeeho is the new UX resource on this project, I have setup a meeting with her to go over the different "status" in detail and finalize the behavior of the menu button. Thanks again!