skip to content

Brand & Voice

How brand shows up inside a product: visual identity in functional UI, a constant voice with shifting tone, a content style guide, logo rules, principles. Asked because engineers write most microcopy.

part ofDesign systems & UX foundationsoverview, primer and where to startread it →
on this pageshow

explore

questions

20

In a payroll product's content style guide, what structure should an error message follow, for example when a pay run fails validation?

level: middleimportance: must knowfreq 38%

answer

  1. three parts, in order
  2. specific to the item
  3. plain words, not system terms
  4. no blame, a way forward
  5. Error Identification, Error Suggestion

basics

~20 s

Say what happened in plain words, specific to the item; say why if it helps; and say how to fix it or what to do next. Avoid bare codes, blame and a vague 'Something went wrong'.

solid answer

~50 s

I use three parts. **What happened**, specific to the item: 'This pay run can't be approved.' **Why**, when it helps the user act: '3 employees have no bank details.' **How to fix it**, naming the items: 'Add bank details for Ana Silva, Tom Reed and Priya Nair, then approve again.' The words are the user's, not the system's - no 'validation failed' or 'null value' - and there is no blame: 'no bank details' rather than 'you failed to enter'. Codes can follow as a reference for support but never replace the message. For failures the user cannot fix, the message says whether their work is safe and what to do next. WCAG 2.2 backs this: 3.3.1 Error Identification (Level A) asks that the item in error be identified and the error described in text, and 3.3.3 Error Suggestion (Level AA) asks for known corrections to be offered.

go deeper

for a junior

Write errors in three parts - what happened, why if it helps, how to fix it - specific to the item, in plain words and without blame.

for a middle

Explain how the structure adapts to field errors, task errors and system failures, and how it meets WCAG 2.2 3.3.1 Error Identification and 3.3.3 Error Suggestion.

for a senior

Show how you would audit a product's error strings, give engineers templates and banned phrasings, and review errors in high-stakes flows such as approving a pay run.

for a principal

Weigh how much error wording to centralise in shared templates against letting teams write for their own domain, and how to fund ongoing review.

## The three parts An **error message** exists to get the user from a problem back to their task. Most content style guides give it a fixed structure: 1. **What happened** - the problem, specific to the item: 'This pay run can't be approved.' 2. **Why** - the cause, when knowing it helps the user act: '3 employees have no bank details.' 3. **How to fix it** - the next step, as concrete as possible: 'Add bank details for Ana Silva, Tom Reed and Priya Nair, then approve again.' Not every message needs all three at full length. A field-level message can merge them - 'Enter a tax code in the format 1257L' - while a failure at the level of the whole pay run needs each part spelled out. The order matters: what first, so the user knows whether this concerns them; the fix last, so it is what they remember. ## A worked payroll example | Weak message | What is wrong | Stronger message | |---|---|---| | Error 422: validation failed | System terms, no fix | This pay run can't be approved: 3 employees have no bank details. | | Something went wrong | Says nothing | We couldn't calculate tax for Tom Reed because his tax code is missing. Add a tax code to continue. | | You entered an invalid date | Blames, vague | The pay date must be a working day. Choose a date on or before 28 March. | | Invalid input | Which input? Why? | Enter a salary above 0. | The stronger versions are sometimes longer, but every extra word does work. ## Rules that make messages work - **Be specific.** Name the field, the employee or the pay run, not 'some items'. - **Use the user's words.** 'Bank details', not 'payment instrument'; 'tax code', not 'TC field'. Use the terms from the product glossary. - **No blame.** Describe the state, not the person: 'The pay date is a holiday', not 'You chose a holiday'. - **Offer the fix.** If the product knows the valid range or format, say it. - **Keep the user's work.** Say so when their input is kept: 'Your changes are saved.' - **Codes are secondary.** An error reference can follow the message for support staff, never replace it. - **One message, one problem.** When several things are wrong, list them rather than merging them into a vague summary. ## What WCAG 2.2 requires Two success criteria set a floor for error text: - **3.3.1 Error Identification (Level A):** if an input error is automatically detected, the item in error is identified and the error is described to the user in text. A red outline alone does not meet this. - **3.3.3 Error Suggestion (Level AA):** if an input error is detected and suggestions for correction are known, they are provided, unless doing so would jeopardise the security or purpose of the content. A password check, for example, may not reveal what the correct value is. The structure above meets both by design: the 'what' identifies the item, the 'how to fix it' carries the suggestion. ## When the user cannot fix it Some failures are the system's, not the user's: a service outage, a bank connection timing out. The structure adapts: - say what happened in plain words - 'We couldn't reach the bank to send payments'; - say what is safe - 'Your pay run is saved and nobody has been paid yet'; - say what to do - 'Try again in a few minutes. If it keeps happening, contact support with reference 7F3A'. The second point is often the most important sentence for a payroll manager, whose first fear is double or missing payments. ## Templates in the style guide Because engineers write most error strings, the style guide should give templates, not just principles: a pattern for field errors, one for whole-task errors and one for system failures, each with two or three real examples from the product. Pair them with a list of banned phrasings - 'invalid', 'illegal', 'fatal', 'Oops' - and a review step for errors in high-stakes flows such as approving and paying a pay run. Where the message appears on screen and how its tone shifts are decided by the form patterns and the tone guidelines; the style guide owns the words and their structure.

  • When several fields in a pay run are wrong at once, how should the messages be written?
    One message per problem, each naming its item and fix, plus a short summary that states how many problems there are - '3 employees need attention before approval' - with each listed. Merging them into one vague line forces users to hunt. The summary tells them the size of the job; the item messages tell them what to do.
  • Where do error codes belong, if anywhere?
    After the human message, as a reference for support - 'If this keeps happening, contact support with reference 7F3A.' A code helps support staff find the log entry; it helps the user only when paired with plain words. A message that is only a code falls short of the intent of WCAG 2.2 3.3.1, which asks for the error to be described to the user in text.
  • Why should error messages use the product glossary's terms?
    Because users match the words in the message to the words on the screen. If the form says 'bank details' and the error says 'payment instrument', users wonder whether they are different things and cannot find the field. Consistent terms turn the message into a direct pointer to what needs fixing.

saying these in an interview costs you the question

  • 'Something went wrong' is fine because users do not need details.
  • An error code alone is enough, since support can look it up.
  • Error messages should state what the user did wrong.
  • Outlining the field in red is enough to identify the error.
  • Every error message must explain the technical cause in full.
open as a page

In a hospital patient portal, why should the lab-results screen carry less brand expression than the public marketing homepage?

level: juniorimportance: should knowfreq 30%

basics

~20 s

Marketing pages exist to make an impression; task screens exist to get a job done. On a results screen, flourishes compete with the content and brand color can be misread as meaning, so the brand shows through a few consistent touches.

open as a page

For a logo in a restaurant point-of-sale tablet app, what do clear-space and minimum-size rules require, and what if the header bar is too small?

level: juniorimportance: should knowfreq 30%

basics

~20 s

Clear space is a protected margin around the logo, measured in a unit from the logo so it scales; minimum size is its smallest legible rendering. When a header cannot honour both, use a compact approved lockup, never a squeezed one.

open as a page

In product design, how does a vision statement differ from a set of design principles, and when does a team reach for each?

level: juniorimportance: should knowfreq 28%

basics

~20 s

A vision statement describes the future the product aims to create for its users; design principles are short, product-specific rules for choosing between options. The vision sets direction and priorities; principles settle everyday design decisions and review debates.

open as a page

On a hotel booking site, why should a payment-failed message drop the playful tone used in the booking-confirmed message?

level: juniorimportance: should knowfreq 32%

basics

~20 s

A failed payment leaves the guest stressed and at risk of losing the room. Humour there reads as not taking the problem seriously and slows them down; a calm, plain tone that helps them recover respects their state.

open as a page

In a payroll product, why should a button say 'Approve pay run' rather than 'OK' or 'Submit'?

level: juniorimportance: should knowfreq 34%

basics

~20 s

A verb-plus-object label tells people exactly what will happen before they act, still makes sense when read on its own, as in a screen reader's list of controls, and removes the need to reread the surrounding text to decide.

open as a page

In a design system, how do you turn brand attributes such as 'calm' and 'trustworthy' into concrete interface decisions for a hospital patient portal?

level: middleimportance: should knowfreq 32%

basics

~20 s

Describe each attribute as traits a user could observe, map each trait to a lever - color, type, shape, imagery, motion, density - and record each choice with its reason and what it rules out.

open as a page

For a patient portal on the web and two native mobile platforms, which parts of visual identity stay constant and which follow platform conventions?

level: middleimportance: should knowfreq 28%

basics

~20 s

Keep constant what makes the product recognisable - color roles, illustration and photography style, voice, shape language. Follow each platform for navigation, standard controls, gestures and system dialogs, and always honour the user's text-size and motion settings.

open as a page

Why does a logo system ship full-color, monochrome and single-color versions, and how do you choose one for light, dark and photographic backgrounds?

level: middleimportance: should knowfreq 25%

basics

~20 s

Versions keep the logo recognisable on every surface and reproduction method: full color on light, calm backgrounds, reversed white on dark ones, monochrome or single-color where only one ink exists or the background fights the brand colors.

open as a page

What separates a useful product design principle from a platitude, and how would you test a draft principle before a team adopts it?

level: middleimportance: should knowfreq 32%

basics

~20 s

A useful principle settles a real disagreement: its opposite is something a reasonable team might choose, and it points to a specific decision. A platitude like 'easy to use' has no sensible opposite, so everyone agrees with it and it decides nothing.

open as a page

On a hotel booking site, what tone should the warning take when a guest is about to cancel a non-refundable booking?

level: middleimportance: should knowfreq 26%

basics

~10 s

Serious, neutral and direct: say plainly what will happen and what the guest loses, and present both choices evenly. Avoid guilt-tripping wording, alarmist language, cheerful softening and euphemisms that hide the consequence.

open as a page

In a product's content guidelines, what is the difference between voice and tone, and why does tone change by context while voice stays constant?

level: middleimportance: should knowfreq 34%

basics

~20 s

Voice is the product's consistent personality, the same on every screen. Tone is how that voice adjusts to the moment and the reader's state: brief in success, calm and plain in errors, encouraging in onboarding, serious before irreversible actions.

open as a page

In an HR product's content style guide, what does inclusive language cover, and how would you apply it to interface text?

level: middleimportance: should knowfreq 26%

basics

~10 s

Inclusive language is wording that does not exclude or stereotype people by gender, age, disability, culture or family: gender-neutral defaults, no loaded metaphors, no assumptions about names or families, and plain words.

open as a page

A patient portal's cheerful cartoon illustrations have spread onto error screens and serious diagnosis results; what illustration and imagery rules would you set in the design system?

level: seniorimportance: should knowfreq 24%

basics

~20 s

Set placement rules by emotional context - imagery in onboarding, empty states and marketing, never beside results or errors - plus one style spec, inclusive and accurate subjects, no information baked into images, and each asset marked informative or decorative.

open as a page

A pharmacy refill app holds two principles, 'refill in seconds' and 'never guess about medication', that clash over a new confirmation step; how should ranked principles resolve it?

level: seniorimportance: should knowfreq 25%

basics

~20 s

Principles should carry an explicit ranking agreed in advance, so the higher one wins a conflict: medication safety keeps the confirmation step. The lower principle still applies, shaping the step to be as fast as safety allows.

open as a page

A hotel booking site's thirty writers across product teams produce messages ranging from stiff to jokey; how would you write tone guidelines that keep them aligned?

level: seniorimportance: should knowfreq 24%

basics

~20 s

Define the voice once as a few attributes with limits, then publish a tone map: per context - error, warning, success, onboarding, destructive action - the reader's state, the tone and a do/don't pair. Back it with review and audits.

open as a page

A payroll product's screens call the same thing 'pay run', 'payroll batch' and 'pay cycle', and users file tickets about it; how would you fix terminology across teams?

level: seniorimportance: should knowfreq 24%

basics

~20 s

Audit the terms in use, choose one term per concept from the words users and the law actually use, publish a glossary with definitions and rejected synonyms, update every surface, and add checks so new copy stays consistent.

open as a page

In a product's content style guide, why do many teams choose sentence case over title case for interface text?

level: juniorimportance: nice to knowfreq 22%

basics

~20 s

Sentence case has one simple rule, so it does not drift between writers; it reads like natural speech and lets proper nouns stand out. Title case is a valid choice too - what matters most is applying one convention everywhere.

open as a page

A restaurant point-of-sale app's logo looks blurry on high-density tablets and slightly off-color between screens, because teams copied cropped screenshots; how would you fix the logo supply in the design system?

level: seniorimportance: nice to knowfreq 18%

basics

~20 s

Make one vector master per lockup and color version the single source, generate every raster export from it at each size and screen density, distribute that set from the design system, and replace the screenshot copies teams made.

open as a page

A product team's design principles sit on a wiki page, yet design reviews still end in opinion battles; how would you make the principles actually decide things?

level: seniorimportance: nice to knowfreq 18%

basics

~20 s

Build the principles into the review process: proposals state which principle they serve or trade off, reviewers cite principles rather than preferences, decisions are recorded as examples, and principles that never get cited are rewritten or retired.

open as a page