New words (and dreaded acronyms) are all too common in government. Sometimes they’re words you’ve never heard before, sometimes they’re words you know but which are used in a different way, and sometimes - the worst times - people use words without explaining them or agreeing what they mean.
When I joined the data group at the Government Digital Service (GDS) six weeks ago, it was clear that product teams within the group were using different words to describe similar things. Although each team is responsible for a different data-related product, their terminology is often very similar. In many meetings we found teams had to define certain words to make sure everyone understood what exactly they meant.
If it was confusing for us, we knew it would be confusing for our users when the products were released. So we decided we should agree the terminology we use for each data product in a bid to clear up confusion internally. That way, we would have consistent terminology that we could eventually test with users and make our communications as clear as possible.
We started with open registers and, in true GDS style, we began with sticky notes.
Our team, including developers, a content designer and a technical architect collected over 120 words relating to registers. We pulled them out of old emails, blog posts, conversations at stand-ups, and even our API specification. We wrote them on sticky notes and began to consolidate and define them.
No one wants a three hour meeting about terminology, so we put all the words into a shared document that the team could read and comment on at any time. We also held a few short sessions where two team members could talk through the document and start to define the terms they were comfortable with. Our list shrank as we deleted unnecessary words and grew as we thought of yet more words that needed a definition.
A long list of words wasn’t particularly user-friendly for our team, so we alphabetised the list and grouped terminology by topic, such as general terminology and technical words that relate specifically to register integrity.
We now have a shared language with agreed definitions. We’ve also agreed styles, for example when certain words should be capitalised, and we have a list of what we’re calling ‘preferred terms’. These are phrases that we like and encourage each other to use when talking about registers.
Having a shared language means that when we create content for people unfamiliar with registers, we can include the agreed definitions and check everyone understands what we’re talking about.
Agreeing a shared language is just the start. How we use a word might change over time and there will always be new words to add.
It’s also important to remember that every user and team member has different experiences, knowledge and skills. That means they will have a different history and understanding of terminology when they read something. So the next step will be to test our language with our users to make sure the words we use make sense to others.
Your own words
If you want to try a similar process with your team, we’ve learnt that it’s useful to include:
- preferred terms
- terms in dispute
- terms that need to be defined later
And, once you have a list:
- make it visible (at least for your team)
- test your words with your users
- never stop updating it
Agreeing a shared language showed us that not everyone in our team had the same understanding about different topics and technology. You might be surprised what you find out and what you can learn from others in the process.
This is the point where’d we usually ‘show the thing’ - in this case, share a link to a document with all our terminology. There are a couple of reasons why we’ve chosen not to at this stage. The first is that it’s designed for our internal teams and hasn’t yet been tested with users. Secondly, and more importantly, if we need to publish a glossary alongside our content to help users understand what we’re talking about, our content isn’t clear enough. Instead, the data team will weave the definitions into content where the extra description might help our users.