Why should a button not exist if it cannot work?
A button should not exist if it cannot work because a dead control reports only that something is blocked, not which condition is missing. The action may be impossible for the product, the account may not be connected, or the feature may not be selected for this project. When those states collapse into one greyed-out control, the reader gets a dead end. An honest refusal names the missing condition and leaves a next step.
What reasons sit behind an unavailable action?
An action can be unavailable for several separate reasons. One is that the product cannot perform it at all. No configuration, connection or selection will change that, so the control should not appear where the capability does not exist.
Another is that the product can perform the action, but the required account has not been connected. A calendar invite cannot be sent until a calendar account is linked. A further reason is that the account is connected, but the current project has not chosen the action. Each reason needs a different instruction.
- The product cannot do it
- The action is outside the product's capability; no connection or setting will enable it, so the control should not be shown.
- The account is not connected
- The capability exists, but the external account required has not been linked; the instruction is to connect it.
- The project has not selected it
- The account is ready, but the current project has not enabled the feature; the instruction is to change project settings.
Why does one greyed-out control fail all of these cases?
A greyed-out button gives the same visual answer to different problems. The reader cannot tell whether the next step is to connect an account, change a setting, or accept that the product cannot help. The control consumes space while providing no diagnostic value.
It also encourages bad advice. A helper seeing the same disabled state may suggest connecting an account even when the product has no such capability. The disabled button turns a missing condition into an unexplained obstruction.
| Reason | What the dead button says | What an honest refusal says |
|---|---|---|
| The product cannot do it | Nothing, the control is greyed out | This workspace cannot run that action. |
| The account is not connected | Nothing, the control is greyed out | Connect a calendar account first. |
| The project has not selected it | Nothing, the control is greyed out | Enable deployments for this project before publishing. |
What does an honest refusal say instead?
An honest refusal names the missing condition and the next action. If the product cannot do the thing, the sentence should say so plainly: 'This workspace does not support sending faxes.' That removes the need to search.
If the account is missing, the refusal says what to connect. If the project has not chosen the feature, the refusal says where to enable it. A simpler tool with only one possible reason can keep a disabled button; a tool with several conditions needs a sentence.
- Capability absence: 'This workspace cannot run live trades.'
- Account missing: 'Connect a calendar account to send invites.'
- Project selection: 'Enable deployments for this project before publishing.'
Why does the order of the checks decide whether the advice is useful?
The order matters because each missing condition can mask another. If you check project selection before capability, you may tell a user to enable a feature the product cannot perform. If you check account connection before capability, you may ask someone to connect a service that will never be used.
The useful order is capability, then account connection, then project selection. This sequence means the failing condition a user sees is one they can act on. A simpler product can skip this because only one condition exists; a product with multiple connectors and project states cannot.
Common questions
Should I hide an unavailable action or show a disabled button?
Hide it when the reason is permanent, such as the product not supporting the action at all. Show an explanation when the action is possible but a condition is missing, such as an unconnected account. A disabled button without text should be the last resort, because it gives no next step.
What is the difference between an action the product cannot do and an account that is not connected?
The first means no setting, connection or choice will make the action work, so the control should not be shown. The second means the capability exists but the external account needed to act has not been linked. The interface should say which account to connect, not just grey out the button.
Why does the order of checking reasons matter?
Checking the wrong order can send a user to connect an account or enable a setting for something the product cannot do at all. Capability should be checked first, then account connection, then project selection. That way the first message a user sees is the condition they can actually change.
When is a greyed-out button acceptable?
A disabled button can be acceptable when there is only one possible reason for unavailability, or when the next step is obvious from context. In a tool with multiple connectors, plans and project states, a greyed-out control hides which condition is missing. In that case, replace it with a short sentence.
Read how these states are handled across the platform at the help centre.