These are guidelines for language that supports positive culture. They make it easier for everyone to understand what we are doing.
For general style guidance, use the department style guide on the intranet.
Please suggest other terms that should go here: email@example.com. Also please reach out if we can make any of this material clearer.
# Plain language
We must make our service easy to understand and use so it is available to everyone who needs it.
People prefer language that is familiar and easy to understand, so they can get things done. This helps the people using the service we are building, as well as our team members working on it.
Try to use plain everyday words and terms, instead of complex jargon.
Take a look at examples of words to avoid and plain language alternatives:
- Australian Government Style Manual - Choose simple words, not complicated expressions
- GOV.UK Style Guide - words to avoid
# Inclusive language
The words we use reflect and reinforce what we believe about the world.
We aren't perfect. But if we can use a different word, it can promote a better work culture. This can help to make everyone's daily interactions easier.
# Guys - use 'people' or 'team' instead
Using 'guys' to refer to everyone in a room or on a call supports an expectation that male gender is the default.
Using 'guys' is so common, it's a hard habit to break. But technology, ICT, design and other industries continue to suffer from gender imbalance. It's important to help address this.
Even if everyone in a group looks male, it doesn't mean they all are.
# Resources - use 'staff' or 'people' instead
Resources are the things we use (for example, computers and stationery). Using the same word to talk about people can promote an expectation of treating them in the same way.
Using 'resources' to talk about employing staff doesn't mean we think people are objects. But by choosing a different word we can help show we value the people we work with.
# Delivery terms
Some words create confusion about how we work in teams. There are more precise terms that can be more helpful.
# Agile ceremonies and rituals - use 'events' instead
There is no one set of mandatory activities in agile. The words 'ceremony' and 'ritual' are not part of contemporary agile frameworks.
The words also have a religious connotation that support the myth that there is only one way to apply agile.
# Portals - we are building a service
Web portals are information sites, often focused on internal users. They compile information and content from different sources, and link to other places.
Taking Farmers to Markets is a transactional and informational service for agricultural exporters.
We are building this service to work with other government services the same people may need.
# Projects - use 'products' and 'services' to describe what we deliver for people
Many of the processes we follow and the tools we use in government talk about working on projects.
This is a problem only if we start thinking of the things we deliver for people as temporary projects. We are delivering and maintaining products and services for as long as they help.
Taking Farmers to Markets is a service that people interact with using products.
To deliver the service and its products, we use processes and tools that talk about project work.
# User testing - be precise about the approach you are using (for example, 'usability testing')
The term 'user testing' suggests we are testing how well people perform at using something. It can also imply we only test things after we completely finish building them.
This isn't our intention when we talk about user testing. But if we choose a different word it can help promote a process of building empathy with people. It also encourages us to maintain this approach throughout design, delivery and maintenance.
Being specific about our approach also helps other people to value our work.