Build trust through language
Consistent, clear copy helps citizens trust that they are interacting with a reliable government service.
Guidelines
Content guidance
Standards for writing clear, consistent copy across government digital services built with SGDS.
Reduce ambiguity
Shared writing rules eliminate guesswork for writers, designers, and developers working on the same product.
Speed up delivery
Teams spend less time debating copy decisions when a shared standard already covers spelling, tone, and formatting.
1
Heading (sentence case, clear action)
2
Helper text (plain language, no contractions)
3
Button label (verb phrase)
4
Error message (what happened + what to do)
Success message
Confirm the action with past tense. Keep it short.
You will receive a confirmation email within 24 hours.
Error message
State what happened and what the user should do next. Do not blame the user.
The file is too large. Upload a file under 5 MB.
Empty state
Explain why the space is empty and offer a next step.
No applications yet
Start your first application to see it here.
Voice and tone
- Write as a trusted, competent partner. GovTech's voice is clear, direct, respectful, and purposeful.
- Address the reader as "you" and use active voice. Put the most relevant information in the first sentence.
- Keep sentences under 20 words. If a sentence needs a clause to clarify another clause, split it into two.
Language to avoid
- Do not use corporate jargon: "leverage", "synergise", "holistic approach", "innovative", "cutting-edge".
- Do not use subjective adjectives: "important", "easy", "simple", "quick". If it is simple, let the design demonstrate that.
- Do not use filler phrases: "please note that", "it should be noted", "in order to", "at this point in time".
- Do not use "please" in instructions. Write "Submit the form", not "Please submit the form".
Button label
Submit application
Lead with the action
Put the key point in the first sentence. Tell users what to do before explaining why.
Button label
Click here
Do not use vague labels
Avoid generic labels that do not tell the user what will happen.
Error message
The file is too large. Upload a file under 5 MB.
State what happened and what to do next
Error messages should explain the problem and give a clear next step.
Error message
You uploaded a file that is too large. Please upload a smaller file.
Do not blame the user
Avoid language that makes the user feel they did something wrong.
Writing for screen readers
Content decisions directly affect how screen-reader users experience a service. Clear, structured copy benefits all users.
- Do not rely on colour alone to convey meaning. Always pair colour with text.
- Write link text that makes sense out of context: "Download the annual report (PDF, 2 MB)", not "click here".
- Write alt text that describes function, not appearance: "GovTech logo", not "blue rectangular image with text".
- Avoid directional instructions that rely on visual layout: "see the section on the right" does not work for screen-reader users.
Content structure
Well-structured content helps assistive technology users navigate and understand pages.
- Use heading levels in order (H1, H2, H3). Do not skip levels for visual styling.
- Keep paragraphs short. One idea per paragraph helps screen-reader users scan content.
- Use lists for three or more related items. Lists are easier to navigate than inline comma-separated values.
- Write descriptive table headers. Screen readers announce headers to help users understand each cell.
Heading navigationLink contextHave suggestions or feedback?
Share them with us on Slack → #ask-sgds-v3
Found a bug or issue?
Report it on GitHub Issues → sgds/guidelines