Naming
What we call things — features, objects, statuses, and actions. A name is a promise the rest of the product has to keep, so naming is a one-way door: easy to ship, expensive to change once it's in the UI, the API, the docs, and people's heads.
Principles
Good names are predictable. A reader should be able to guess what something does from its name, and find it again by the same name everywhere.
Describe, don't brand
Inside the product, name things for what they do. Save the aspirational language for marketing. “Recovery plan” beats “ResilienceHub”.
One concept, one name
The same thing gets the same word in the dashboard, the report, the dialog, and the API. Synonyms make a careful product feel careless.
Plain over precise-but-opaque
Prefer the word a non-specialist understands. “Plan”, not “BCP”. Reserve acronyms for dense UI with obvious context.
Borrow the user's word
When customers already have a term (“Activity” vs “Process”), match their domain settings rather than imposing ours.
Naming objects
The nouns of the product — the things people create, view, and manage. Keep them short, singular, and concrete.
Naming actions
The verbs. One clear verb per action, matched to the object — and matched to the confirmation that follows it.
| Verb | Use for |
|---|---|
Add | Put an existing or new item into a collection. |
Create | Make a new top-level object (a plan, an analysis). |
Edit | Change an existing object's details. |
Remove | Take an item out of a collection (reversible). |
Delete | Destroy an object permanently (confirm first). |
Archive | Retire an object but keep it for the record. |
Naming statuses
Status names must read at a glance and survive greyscale. Use a small, fixed vocabulary; don't invent a new status word per feature.
Introducing a new term
Sometimes a new concept genuinely needs a new name. Before you coin one, make it earn its place.
Check the terminology table first — there may already be a word for this.
Don't invent a new acronym for a Fortiv-specific concept; name it in plain words.
Define it once, plainly, at first use — then use it consistently everywhere.
Don't ship two names for the same thing while you decide; pick one before it reaches the UI.