Tone of Voice
For product and development teams building digital products at DEHN — UI copy, error messages, help text, onboarding, notifications, and everything else that involves words in software and web development. Promotional copy and editorial web content are owned by Marketing and are not covered here.
What DEHN stands for
DEHN protects people, infrastructure, and investments — for over 100 years. That is not a slogan; it is a commitment. Everything we write reflects that responsibility.
We are a technical partner, not a lifestyle brand. Our readers are planners, installers, and operators making decisions with real consequences. They do not need enthusiasm — they need clarity.
Voice and tone
How we sound
Matter-of-fact, direct, competent. We explain exactly what needs explaining — nothing more, nothing less. Our texts read like an experienced colleague who knows the subject and does not waste your time.
Short sentences. Active verbs. The most important point comes first.
Tone
Default for all digital products: formal and neutral. Onboarding text for new users may sound slightly more approachable — but never casual. Safety-critical text is always formal and neutral, without exception.
Language and style
Sentence structure
Subject → verb → object. No detours.
Long sentences are acceptable when they express a logical relationship — a condition or a causal chain. Padding is not acceptable.
✓ “The separation distance must be calculated before commissioning.”
✗ “Before you begin the commissioning process, you should make sure that the separation distance has already been calculated in advance.”
Numbers and units
Always SI units, always with a space between number and unit:
12 kA·0.1 m·1000 V
Always cite standards in full:
IEC 62305-3·EN 62305-3— never “per the applicable standard” or “in accordance with relevant norms”
Verbs
Concrete. Action-oriented.
✓ select, connect, verify, replace, calculate
✗ leverage, utilize, ensure (when a more precise verb exists)
Safety-critical copy
Warnings, safety-relevant error messages, and legally significant UI text always follow this structure — no exceptions, no variations:
1. What happened — state the condition clearly and specifically
2. Impact — include only if it adds necessary context (risk to people, equipment, or compliance)
3. Required action — specific, unambiguous next step or link
Tone: Formal + Neutral. No friendly framing, no softening language. The severity of the situation determines the urgency of the language — not the audience.
Example:
Earth-termination system resistance exceeds the maximum permissible value per IEC 62305-3.
Equipment connected to this system is not adequately protected against lightning currents.
Have the earth-termination system inspected and repaired by a qualified electrician before resuming operation.
Error messages (non-safety)
Three parts — in this order:
- What happened
- Why / impact (only if useful)
- What to do next — specific fix or link
Never blame the user. Never be vague.
✓ “The file could not be uploaded. Accepted formats are PDF and DXF, up to 20 MB. Select a compatible file and try again.”
✗ “Upload failed. Please try again.”
Copy by text type
Buttons and labels
Format: Verb + object. No period. No punctuation.
Start risk assessment·Save configuration·Download report
Not: Click here · Submit · OK (without context)
Tooltips and help text
One sentence. State the purpose, not the mechanism.
“Separation distance prevents dangerous side flashes between the external lightning protection system and internal metal parts.”
Empty states
State what is missing, then prompt the next action.
“No projects yet. Create your first project to start the risk assessment.”
Toasts and notifications
Outcome first. One line where possible.
Project saved.·Risk assessment complete. View results.
Dialogs
Title: specific noun phrase or consequence statement. Never “Are you sure?”
Primary action: specific verb. Secondary: “Cancel”.
Title:
Permanently delete project· Primary:Delete· Secondary:Cancel
Onboarding and instructions
Numbered steps, one action per step. State prerequisites before the action.
- Select the structure type.
- Enter the dimensions.
- Start the risk assessment.
Terminology
The rule
Always use the preferred term from the DEHN Glossary — even when a synonym is technically correct. No synonyms. No paraphrases.
If a term is missing: do not invent one. Look it up in the DEHN Glossary — that is where all approved terms are maintained.
Critical term pairs
| Use | Never use |
|---|---|
| lightning protection system | lightning rod (for the whole system) |
| surge protective device (SPD) | arrester (alone, without type designation) |
| qualified electrician | electrician (too generic in safety notices) |
| competent person | expert (too vague in legal notices) |
| operator | owner, user (in maintenance/legal context) |
| risk assessment | risk estimation — ⚠ note: the standard uses “risk analysis”; prefer “risk assessment” in UI copy |
| Lightning Protection Level I–IV | LPS class (UI copy); use “class of LPS” only when citing the standard directly |
| Type 1 / Type 2 / Type 3 | Coarse / Medium / Fine protection (obsolete) |
| separation distance | clearance distance |
| earth-termination system | earthing (alone, too vague) |
| equipotential bonding | potential equalization |
What to avoid
Marketing language in product UI:
powerful, innovative, seamless, cutting-edge, future-oriented — not in product copy or instructions.
Vague severity:
“may cause issues” → state the actual risk.
Implied blame:
“You forgot to…” · “Please make sure you…” → rephrase as neutral, action-oriented statements.
Hedging chains:
“might possibly be able to” → can, or state the condition directly.
Humour or emojis in safety-critical or instructional contexts.
Localisation
- Decimal separator: EN
.· DE,— apply consistently within each language version. - Terminology must be consistent across EN and DE — the glossary is binding for both languages.
Tone of voice skill
Load the Markdown file as knowledge into your projects and prompts, whenever you create customer facing text.