Taking Farmers to Markets Service Delivery Handbook

Language guidelines

Our guidelines for language and content support a positive culture and user experience. They make it easier for everyone to understand what we are do and how to use the Export Service.

You can find guidance on how to create content in the Export Service in several places. Get started with the pages in the How to create guidance in the Export Service guide.

Use it together with the following resources that form our Digital guidance toolkit. They offer more detail on all aspects of creating content that meets users’ needs in the Export Service:

You can access the DAFF Style guide on DAFF’s SharePoint intranet site, The source. To find the guide, select About the department > Forms and templates > Department style guide. If content guidance differs between these sources, follow guidelines in the above order.

# Plain language

We must make our service easy to understand and use so it is available to everyone who needs it.

This is a requirement of the Disability Discrimination Act 1992.

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 our plain language guidance in our Content principles. You can also find examples of words to avoid and plain language alternatives:

# 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.