Content

Browse Get started

Get started

Write clear, consistent copy for government digital services using SGDS content standards.

Why content standards matter

Every label, error message, and heading is part of the user experience. Inconsistent or unclear copy erodes trust and slows users down.

SGDS content standards give writers, designers, and developers a shared set of rules. When everyone follows the same conventions, government services feel like one organisation.

Writing principles

Four principles guide all content across SGDS products.

Clear

Say exactly what you mean in as few words as needed. Remove filler phrases and unnecessary qualifiers.

Direct

Address the reader as "you" and use active voice. Put the most relevant information first.

Respectful

Treat readers as capable adults. Do not over-explain or use patronising language.

Purposeful

Every sentence earns its place. If a word does not help the reader act, remove it.

Rules to apply first

These six rules have the highest impact on readability and consistency across government services.

Use UK English spelling:Write "colour", "organisation", and "recognise". Set your spell checker to en-GB.
Use sentence case for all headings:Capitalise the first word and proper nouns only. Write "Submit your application", not "Submit Your Application".
Do not use contractions:Write "do not" instead of "don't" and "you will" instead of "you'll". This applies to all UI copy.
Write in active voice:The subject performs the action. Write "The system sends a confirmation" instead of "A confirmation is sent".
Use plain language:Choose short, common words. Write "use" instead of "utilise", "help" instead of "facilitate", and "start" instead of "commence".
Do not use em dashes:Use a colon, comma pair, or a new sentence instead. Em dashes add visual noise and can be missed by screen readers.

Voice and tone

Write as a trusted, competent partner. SGDS content should be clear, direct, respectful, and purposeful.

Lead with the action: Put the key point in the first sentence. Tell users what to do before explaining why.
Address the reader as you: Write directly to the person using the service. Use active voice so the subject performs the action.
Keep sentences short: Aim for sentences under 20 words. If a sentence needs a clarifying clause, split it into two.
Keep one idea per paragraph: Short paragraphs help users scan and help screen-reader users move through content.

Language to avoid

Remove words that slow users down or make government services sound vague.

Corporate jargon: Avoid words such as "leverage", "synergise", "holistic approach", "innovative", and "cutting-edge".
Subjective adjectives: Avoid words such as "important", "easy", "simple", and "quick". Let the service prove those qualities.
Filler phrases: Remove phrases such as "please note that", "it should be noted", "in order to", and "at this point in time".
Please in instructions: Write "Submit the form" instead of "Please submit the form". Instructions should be clear without softening.
Contrastive negation: Avoid the pattern "not X, but Y". Write the positive statement directly instead.

Spelling and capitalisation

Use consistent spelling and casing across headings, labels, buttons, and body copy.

Use UK English: Write "colour", "centre", "programme", "organisation", "recognise", "analyse", "catalogue", "licence", and "fulfil".
Use sentence case: Capitalise the first word and proper nouns only. This applies to headings, labels, buttons, navigation items, and error messages.
Capitalise proper nouns and acronyms: Use established casing for names such as GovTech, Singpass, CorpPass, MyInfo, API, ICT, UI, UX, PDF, and URL.
Do not capitalise descriptive job titles: Write "the director approved the request" unless the title appears directly before a name.

Grammar and punctuation

Use grammar and punctuation rules that make copy easier to scan and read aloud.

Use active voice: Write "The system sends a confirmation email" instead of "A confirmation email is sent by the system".
Use the Oxford comma: Use a comma before the final item in lists of three or more items: "NRIC, passport, and proof of address".
Do not use em dashes: Use a colon, comma pair, or a new sentence instead. Do not use an en dash as a substitute.
Use hyphens and en dashes correctly: Use hyphens for compound modifiers such as "user-friendly". Use en dashes only for ranges such as "pages 10–15".
Do not use apostrophes for plurals: Write "APIs" and "PDFs", not "API's" or "PDF's".

Write quantities, dates, times, and obligation words consistently.

Numbers: Spell out numbers one to nine. Use numerals for 10 and above.
Measurements and amounts: Always use numerals for percentages, currency, measurements, and version numbers, such as 5%, $10, 3 MB, and version 2.
Dates and times: Write dates as "1 January 2025" and times as "9am" or "3:30pm". Do not use ordinal suffixes.
Must: Use "must" only for legal obligations. Example: "You must submit the form by 31 January."
Need to: Use "need to" for administrative steps. Example: "You need to verify your email before signing in."
Should and may: Use "should" for recommendations and "may" for optional actions.

UI copy patterns

Apply these patterns when writing copy for SGDS components.

Buttons

Use verb phrases: "Submit form", "Download report". Do not use vague labels such as "Click here" or "OK".

Submit application

Specific button label

Use a verb phrase that tells users what happens next.

Click here

Vague button label

Avoid generic labels that do not explain the result of the action.

Error messages

State what happened and what the user should do next. Write "The file is too large. Upload a file under 5 MB." Do not blame the user.

The file is too large. Upload a file under 5 MB.

Helpful error text

Give the user a clear next step instead of repeating that something failed.

You uploaded a file that is too large. Try again.

Blaming error text

Avoid language that makes the user feel they did something wrong.

Empty states

Explain why the space is empty and offer a next step. Write "No applications yet. Start your first application."

No applications yet

Start your first application to see it here.

Start application

Actionable empty state

Explain the empty space and offer a useful next step.

Nothing to show

There is no data.

Dead-end empty state

Avoid empty states that do not explain what happened or what users can do.

Tooltips and helper text

Keep tooltips to one sentence. Helper text explains the format or constraint, not a restatement of the label.

Helper text

Use the email address linked to your Singpass account.

Useful helper text

Explain the required format or constraint.

Helper text

Enter your email address here.

Repeated helper text

Avoid restating the label or adding filler.

Loading and status messages

Use present progressive for loading: "Saving changes…". Confirm success with past tense: "Changes saved."

Your updates were saved successfully.

Clear status message

Use present progressive for loading and past tense for completed actions.

Your request has been processed.

Unclear status message

Avoid vague messages that do not tell users what happened.

Accessibility and structure

Content decisions affect how screen-reader users navigate and understand a service.

Use descriptive link text: Write link text that makes sense out of context, such as "Download the annual report (PDF, 2 MB)".
Do not rely on colour alone: Pair colour with text so users can understand status, errors, and warnings without relying on colour perception.
Write functional alt text: Describe the function of an image, such as "GovTech logo", instead of describing only its appearance.
Use heading levels in order: Use H1, H2, and H3 in sequence. Do not skip levels for visual styling.
Use lists for related items: Use lists for three or more related items. Lists are easier to scan than comma-separated text.
Avoid directional instructions: Do not write instructions that depend on visual position, such as "see the section on the right".

Use the SGDS writing skill

When working with an AI assistant, ask it to read the SGDS writing skill before drafting or reviewing interface copy. The skill gives the assistant SGDS tone, UK spelling, sentence case, punctuation, plain language, UI copy patterns, and accessibility rules so generated content stays consistent.

Set up SGDS agent skills