Skip to the page

MCSS-Lite 0.4.1

GitHub

Read before you build

Words are parts too. These rules keep labels, messages and help text consistent across every screen, whether a person or an agent writes them. They follow the GOV.UK Design System, GitLab Pajamas and NN/g research.

Content rules

  1. Write in sentence case

    Capitalize only the first word and proper nouns in labels, titles, buttons and badges. Title Case is harder to scan and reads as shouting in long labels.

    Do: Create account

    Don't: Create Account

    Checked by mcss-lite validate [content-case]

  2. Buttons say what happens

    Start with a verb and name the thing it acts on. A person should know the result before they click.

    Do: Save changes

    Don't: OK

  3. No vague labels

    "Submit", "Click here", "Yes" and "More" say nothing out of context. Screen reader users often hear a list of every link or button on the page, with no surrounding text.

    Do: Download the invoice

    Don't: Click here

    Checked by mcss-lite validate [content-vague]

  4. Errors say what went wrong and how to fix it

    Name the problem in plain words and tell the person what to do. Don't blame, don't use codes, don't say "invalid".

    Do: Enter a date after 1 January 2020

    Don't: Invalid input

  5. Show errors at the right moment

    Check a field when the person leaves it or submits the form, not while they type its first value. Once a field shows an error, clear it as soon as the value is fixed. After a failed submit, list every error at the top of the form, each linked to its field.

    Do: There is a problem: Enter your email address

    Don't: Email is invalid (shown after the first keystroke)

  6. Mark optional fields, not required ones

    Ask only for what you need, then add "(optional)" to the few fields people may skip. Rows of asterisks add noise and need a legend.

    Do: Phone number (optional)

    Don't: Phone number *

  7. Write choices as positive statements

    A checkbox label is a statement the person agrees with by ticking it. Negatives make them untick to say yes, and people get it wrong.

    Do: Email me about new releases

    Don't: Don't email me about new releases

  8. Name the setting, not the action

    A toggle's label names what it controls and never changes; the switch itself says on or off. Labels like "Turn on" leave people guessing which state is current.

    Do: Dark mode

    Don't: Enable dark mode

  9. Keep punctuation light

    No full stops on buttons, titles, labels or badges. Use full stops in help text and messages that are sentences. Avoid exclamation marks.

    Do: Delete project

    Don't: Delete project!

  10. Write numbers and dates the same way everywhere

    Use numerals for numbers, the full month name in dates and a consistent time format. Avoid ambiguous dates like 03/04.

    Do: 1 March 2026, 12 of 20 seats

    Don't: 03/01/26, twelve of twenty seats

  11. Write for everyone

    Use plain words, active voice and "you". Avoid idioms, jargon and gendered defaults. Describe what something does, not how it looks ("select", not "click the blue button").

    Do: Choose a plan to continue

    Don't: Just hit the big blue button, guys