Content & Writing

Why writing is a design decision

A button label that says "Submit" instead of "Send your response" isn't just a style preference. It shapes whether someone feels confident about what's about to happen. An error message that says "Something went wrong" instead of "We couldn't save your draft — try again" leaves a project manager stranded. An onboarding heading that says "Leverage stakeholder insights" instead of "See who's engaged" makes someone feel like they're reading someone else's software.

In community and stakeholder engagement, the stakes are real. A confusing label can stop a resident from completing a consultation about a development that affects their street. An alienating tone can signal to a community member that the process isn't really for them. A vague confirmation message can leave a government project manager unsure whether their work was saved.

Writing decisions — every label, heading, message, and empty state — are design decisions. They belong in the same system as colour, spacing, and component behaviour. This section is that system.

Who this section is for

Everyone on the product team. Content guidelines aren't just for content designers.

Product designers — you write error messages, tooltips, empty states, and placeholder text as part of your daily work. This section gives you a framework so those decisions are consistent and intentional, not improvised.
Engineers — you write validation messages, hardcoded strings, and in-code copy. This section tells you what good looks like so you don't have to guess or default to a technical message.
Product managers — you write feature specs, acceptance criteria, and sometimes UI copy in Jira. Understanding the voice helps you write specs that produce the right output.
Content designers — this is your primary reference. Use it to orient new team members, resolve debates about specific copy decisions, and build on it as the product evolves.

You don't need to read every page to contribute well. But knowing the fundamentals — particularly voice and tone, and the patterns for UI text — will meaningfully raise the quality of your work.

How to use this section

There are two ways to use these guidelines:

As a quick reference — jump to the specific page you need. If you're writing a button label, go to Action labels. If you're writing an error message, go to Error messages. Each page is self-contained and has real examples from the Open Point product context.
As a full read — if you're new to the team, or if you want to understand the reasoning behind the guidance rather than just the rules, start with Voice & tone and read forward. The structure is intentional: voice and tone sets the foundation, then the UI text pages apply it to specific surfaces.

When in doubt: write something, then check it against the voice attributes on the Voice & tone page. If it passes those four tests — clear, direct, empowering, human — it's probably right.

The two audiences

Open Point writes for two distinct audiences, and the distinction matters when you're making copy decisions.

Professional users

Government staff, engagement coordinators, project managers, and organisation administrators using Open Point or the professional interface of Social Point. These users are doing work. They're managing consultations, inviting stakeholders, reviewing submissions, and building reports.

They value efficiency and clarity. They know the domain — they understand what a consultation is, what a stakeholder is, what a project status means. They don't need everything explained from scratch, but they do need the interface to be unambiguous and fast to scan.

Plain language, but not over-simplified
Efficient phrasing — no unnecessary words
Domain terms are fine when they're genuinely universal (e.g. "consultation", "submission")
Confirmations and feedback should be precise

Community participants

Members of the public completing surveys, attending virtual engagements, or submitting feedback through Social Point. These users may have no prior experience with engagement software. They may be completing a consultation because they care deeply about a specific local issue — not because they use this kind of tool regularly.

They need more warmth and more hand-holding. Jargon can make them feel excluded. Confusing instructions can make them give up. Empty states that say nothing useful can leave them unsure whether their submission registered.

Maximum plain language — test against WCAG reading level guidance where possible
Warm but not patronising
Avoid domain jargon unless it's the formal name of the thing they're doing
Confirmations should be explicit: "Your response has been submitted"

When these audiences are in tension, default to the most accessible version. A message that's slightly more explicit than a professional user needs is never harmful. A message that a community participant can't understand is a failure. Accessibility isn't a community-facing concern — it benefits everyone.