Action labels

The pattern: verb + object

Action labels should follow a verb + object structure. The verb says what happens; the object says what it happens to. Together they remove ambiguity and tell the person exactly what they’re about to do.

• Sentence case. “Save draft”, not “Save Draft” or “SAVE DRAFT”. Title case in buttons is a common UI pattern — avoid it. It makes labels harder to scan.
• 1–3 words is the target. 4–5 is acceptable when clarity genuinely requires it. More than 5 words is a sentence, not a label — rethink the UI.
• Specific over generic. “Save draft” tells someone more than “Save”. “Send invitation” tells someone more than “Submit”.
• Present tense, active voice. “Export report”, not “Report will be exported”.
• No periods. Button labels aren’t sentences.

Destructive actions

Don’t soften destructive labels. Euphemistic language on a destructive action is how someone deletes three months of consultation data they didn’t mean to. The label should name the consequence.

If the action is irreversible, the confirmation dialog should state that clearly — but the label itself still needs to be direct. “Remove” and “Archive” are not synonyms for “Delete” when what you mean is delete. If data is permanently destroyed, the label says “Delete”.

• ”Delete consultation” — not “Remove” or “Clear” when the action is permanent deletion
• ”Remove stakeholder” — correct when removing from a list without deleting the record
• ”Archive project” — correct when the project is being archived, not deleted
• ”Revoke access” — correct; names the consequence precisely

Icon-only buttons

An icon button without a visible label still needs an accessible label. Icons alone are not universally understood — a three-dot menu icon means different things to different people, and means nothing at all to a screen reader user without an accessible name.

The accessible label lives in code, not in a tooltip. A tooltip is better than nothing, but it requires hover and doesn’t work on touch. Use aria-label on the button element. Make the label specific — not just “More” but “More actions for Northside Highway consultation”.

<button aria-label=“More actions for Northside Highway consultation”>
<Icon name=“ellipsis” />
</button>

<button>
<Icon name=“ellipsis” />
</button>

<button aria-label=“Delete submission from Alex Johnson”>
<Icon name=“trash” />
</button>

<button aria-label=“Delete”>
<Icon name=“trash” />
</button>

Links vs. buttons

This is a writing question as much as a development one. The label should match what the element actually does.

• Buttons perform actions: “Save draft”, “Send invitation”, “Export responses”. They do something to data or application state.
• Links navigate: “View consultation”, “Go to project”, “Open report”. They take you somewhere.
• If a link looks like a button but navigates, its label still follows navigation conventions — “View responses”, not “View responses here”.
• Don’t use “Click here” as a link label. The label should describe the destination or action, not the mechanic of clicking.

Common Open Point labels

These are established patterns in the product. Use them consistently — diverging without reason introduces inconsistency across the suite.