UI labels - Invoca

What counts as a UI label

Short, standalone text that names a control, an option, or a section — as distinct from a sentence a reader reads fluently (Voice and tone, Error messages) or a formatted value (Numbers, Dates and times). A button’s text, a field’s label, a checkbox’s option text, a tab’s name, and a table’s column header are all UI labels in this sense, even though they live on very different components.

The one decision every label makes: verb, or noun

Every component page written so far lands on one of exactly two grammatical shapes for a label, and which one applies follows directly from what the control does:

The control…	Label is a…	Example	Established on
Performs an action	Verb-first imperative phrase	”Save Changes,” “Delete Campaign”	Button
Represents a persistent thing, state, or setting	Noun phrase — never a question, never an instruction to act	”Email notifications,” “Dark mode,” “Routing”	Checkbox, Switch, Radio, Tabs

This table is a synthesis, citable in one place because six different component pages independently converged on this split — see Open issues for its sign-off status.

Rules that already apply everywhere

These were each established on a specific component page and restated here as the general form, cited back to where they were established rather than re-argued:

Rule	Established on
Prefer the specific word over a generic one (“Delete campaign,” not “OK”)	Button
Use the reader’s word for the thing, never the underlying library’s internal name	the naming divergence
No terminal punctuation on any label	Capitalization and punctuation
Casing follows the per-content-type model — it is not one global rule	Capitalization and punctuation
Plain language over jargon or internal acronyms	Voice and tone

Constraints

ID	Constraint	Rationale
TITAN-UILABEL-01	A label naming an action is a verb-first imperative phrase.	Established directly on Button; restated here as the general form.
TITAN-UILABEL-02	A label naming a persistent thing, state, or setting is a noun phrase — never a question, never an instruction to act.	Synthesized from independently-arrived-at rules on Checkbox, Radio, Switch, and Tabs — see the table above.
TITAN-UILABEL-03	A label uses the reader’s word for the thing it names, never the underlying library’s or framework’s internal name.	The naming divergence — “Table,” not `DataGrid`.
TITAN-UILABEL-04	The specific word is preferred over a generic placeholder (“OK,” “Submit,” “Item”) wherever the specific one is knowable at authoring time.	A generic label forces the reader to look elsewhere on the screen to learn what pressing it actually does.

Gaps in the current rules

UI labels: open issues

Divergences, open decisions, and undocumented gaps for UI labels.

Why it works this way

The verb/noun split mirrors what the reader needs to predict. A control that performs an action needs its label to answer “what happens if I press this” — a verb answers that directly. A control that represents a state needs its label to answer “what is this,” so the reader can recognize it — a noun answers that instead. Labeling an action with a noun (“Save” becomes “Confirmation”) or a state with a question (“Dark mode” becomes “Enable dark mode?”) answers the wrong question for what the reader is actually trying to do at that control.

Status

No source exists for this page, and none has been offered. Unlike Voice and tone and Error messages, this is not a transcription. It is a synthesis of labeling rules that were authored independently, per component, on Button, FieldLabel, Checkbox, Radio, Switch, and Select — stated once here as shared principles instead of staying duplicated six times. Treat every constraint below as Proposed.

​What counts as a UI label

​The one decision every label makes: verb, or noun

​Rules that already apply everywhere

​Constraints

​Gaps in the current rules