Choose against the task constraints
A fictional schedule editor has three real actions: save an internal draft, request manager review and publish an approved schedule. The requester has draft and review rights but no publishing right. Labels should express the operation, while permissions remain enforced by the system.
| Condition | Generic submit/continue labels | Task-specific action labels |
|---|---|---|
| Different state transitions | Similar labels may conceal the distinction | Name the draft, review or publish transition |
| No extra decision required | A second acknowledgement may repeat the action | The primary action can communicate the choice |
| Restricted publishing | Wording alone cannot enforce access | Label clearly and still validate authorisation |
Use Save draft and Request review for the requester’s available actions. Publishing remains a separately authorised operation. Avoid an extra generic confirmation that only restates the button; give specific result feedback after the actual action completes.
A label must match its transition
| Action | Resulting state | Available to requester |
|---|---|---|
| Save draft | Draft retained internally | Yes |
| Request review | Pending manager decision | Yes |
| Publish approved schedule | Visible approved version | No |
Does requesting review make the schedule public?
Show the worked answer
No. It creates a pending decision in this example. Publication is a different authorised action, and a saved draft is different again.
Check the chosen interaction
- Each button names the actual operation it performs.
- An unavailable privilege cannot be gained by changing button text.
- Success text names the resulting draft, request or published version.