On this page
Content basics
Plain language, voice and tone, terminology, grammar and punctuation for text in Nebula components.
These guidelines apply to all text written for Nebula components and the products built with them. Component-specific guidance lives with each component. For Kaluza Agent Experience specifically, agents use these products under pressure, often mid-call, content must be immediately scannable, unambiguous, and efficient.
Plain language
Write at a reading level appropriate for a fast-paced, high-pressure task. Use the simplest word that is accurate.
- Help not Assist
- About not Approximately
- Buy not Purchase
Keep sentences short. One idea per sentence. Front-load the most important information, put the key point first, then the supporting detail.
Do
Payment failed. Card declined by the bank.
Don't
The bank has declined the card, which means the payment failed.
Avoid double negatives. They force the reader to decode meaning under pressure.
Do
This account is eligible for support.
Don't
This account is not ineligible for support.
Write positively. Negative constructions force agents to mentally invert instructions before acting.
Do
To submit, complete all required fields.
Don't
You can't submit if you don't complete all required fields.
Cut weak sentence openers. Remove you can, there is, there are and replace with a direct verb.
Do
Add notes to this account.
Don't
You can add notes to this account.
Avoid adverbs and unnecessary adjectives, they are usually redundant. Delete simply, easily, just, and similar on review.
Do not use Latin abbreviations: e.g., i.e., etc. Spell it out or restructure the sentence.
Do
For example, a gas meter or electricity meter
Don't
E.g. a gas or electricity meter
Active voice
Use active voice in most cases. It is shorter, clearer, and more direct.
Do
We couldn't process this payment.
Don't
This payment could not be processed.
Passive voice is acceptable when active voice would sound accusatory, particularly when an error was caused by the user.
Do
Your payment has been declined. (softened, user action)
Don't
We declined your payment. (too blunt)
Use simple verb tenses, past, present, future. Avoid perfect tenses (has/have done) and progressive tenses (is/was doing).
| Avoid | Prefer |
|---|---|
| You've entered an incorrect password. | You entered an incorrect password. |
| Your changes will be being saved. | Your changes will be saved. |
Write about what actions and controls do, not how to physically interact with them.
| Avoid | Prefer |
|---|---|
| Click the button | Select |
| Type the address | Enter the address |
| Tap the icon | Open or Select |
Labels and calls to action
Interactive elements should use verb-first labels that describe the action.
Do
Submit payment
Don't
Submission
Be specific. Every call to action on a page should be unique so screen readers can distinguish between them.
Omit articles (a, an, the) in labels and action-based headings.
Do
Add note
Don't
Add a note
Avoid personal possessive pronouns in labels.
Do
Update address
Don't
Update your address
Voice and tone
Tone should be neutral, direct, and helpful. This is a professional tool, not a consumer app.
Contractions are appropriate and improve readability, use them naturally (can't, we couldn't, you'll). Avoid contractions in legal notices, payment processing, and account security contexts where casual language reduces trust.
Do not use politeness padding (please, thank you) in UI labels. It adds length without value.
Do not inflate ease of use. Avoid easy, simple, just, these make assumptions about the agent's experience.
Do
Set up your payment plan in 3 steps.
Don't
It's easy, just set up your payment plan.
Avoid urgency language (warning, immediately, danger) unless the situation genuinely warrants it. Reserve strong signals for genuinely critical moments.
Consistency and terminology
Use the same word for the same concept throughout. Synonyms create confusion in a data-dense tool, agents may assume different words mean different things.
Pick one term and use it everywhere: if it is account credit, it is always account credit, never balance credit or credit balance.
When an acronym appears for the first time in a context, spell it out once with the acronym in parentheses: Meter Point Administration Number (MPAN). Do not spell out platform-wide acronyms on every occurrence.
Avoid creating new acronyms. Only use an acronym if your audience is already familiar with it, or if it is an internationally recognised abbreviation (SMS, PDF, CSV).
Feature and function naming
Most features do not need a branded or capitalised name. Refer to them descriptively.
Do
bulk upload, payment plan
Don't
Bulk Upload, Payment Plan
Describe what a feature does rather than just naming it.
Do
Set up a payment plan to spread this balance over time.
Don't
Payment Plan
Every new name is a new concept an agent must learn. Only introduce a named concept when it is necessary.
Grammar and punctuation
Sentence case. Use sentence case for all UI text, headings, labels, buttons, notifications. Only capitalise proper nouns and product names.
Full stops. Do not use a full stop at the end of standalone labels, headings, or button text. Use full stops in body content and multi-sentence messages.
Exclamation marks. Avoid. Never use in error messages, failure states, or alerts.
Ampersands. Use and in content. & is not localisation-friendly and screen readers announce it as "ampersand".
Em dashes. Do not use em dashes (—) in product content. Use a comma, colon, or full stop instead.
Oxford comma. Use it in lists of three or more to avoid ambiguity: Name, address, and date of birth.
Semicolons. Avoid entirely. Use a full stop or comma instead.
Ellipsis. Use only to indicate truncated content or a loading state (Loading...). Do not use for effect or in button labels.
Emoji. Never use in product content.
See formatting guidelines for dates, numbers, and currency.