Guidelines - Tone of voice

Contents

Introduction

This guide is designed to provide guidance on how copy should be written in the absence of a specifically provided message. On this tab, you will find the outlines for our products' voice and tone – a consistent style of messaging across our product suite. Use it as a playbook when you're writing copy in the products, and let it serve as inspiration to keep things consistent.

This is not a guide on how to write an e-mail to a customer - this guide should purely be used for messaging within one of our products. Our “brand” identity is similar to the identity we have within the products, but they are not identical.

What's the difference between voice and tone?

Voice and Tone are two very similar concepts, and are intrinsically linked. There are some subtle differences, though.

The Voice of a products are what it says. Much like you have your own way of putting things, Mosaic also has its own way of putting things. It's the difference between saying "Hi", and saying "Salutations". "Indeed" or "Agreed". "Woke" or "Socially conscious".

The Tone of our product is similar to the Voice, but there are some key differences. You have your own personal voice, and your voice doesn't change – but, depending on the situation, your tone will change. Speaking to a close family member will definitely be different to speaking to a colleague (I hope). It also changes depending on the situation at hand – your tone will immediately change in an emergency. The same goes for a product. Reminding a user than they need to fill a mandatory field when submitting a form will have a vastly different tone to telling them that the system has encountered a critical error and they need to phone support immediately.

The Voice of Mosaic

Our voice is human but professional. We don’t want to treat our users like unfamiliar strangers and bark orders at them, but being too casual is just as bad. Our products saying: “Ah, saved that for you mate, no problem!” comes across as far too casual, but equally, “You must save this form.” is incredibly unfriendly. Users of Mosaic products should enjoy the experience, feel welcome, and have a human interaction – and also feel confident that their business needs are being treated with care and due diligence. Our products are expert solutions from a trusted source. We aren't just professionals: we are the professionals.

But… What does this actually mean? When writing copy, you should strive to make it…

Focused

We play an important role in our users' work. The user has come to us to solve a problem, and we chose our words carefully to do that quickly, and efficiently. We simplify things as much as possible, and don't waste time over-complicating things that simply don't need it.

Genuine

Our users are people with a need, not clients. We don't have to keep them at arm's length, or maintain a business-like persona, or treat every interaction as a transaction. We're not looking for validation or seeking to impress. Our products have a collaborative relationship with our users – do away with pretence and get on with the job at hand. We don't worry about looking smart or keeping up appearances – we get to the point and say what we mean.

Insightful

Our users are the experts, but so are we. Our products should inspire confidence in our users – we know what we're doing. Language should be appropriate for the task at hand, especially when it comes to sector-specific knowledge, and it should show the users that they can trust us to do the job right. Be confident. Be assertive. Make it clear we know what we're doing. But never be aggressive or smug.

The Tone of Mosaic

Mosaic's tone is largely friendly and encouraging. We know that our products are used in hectic and important work environments, so we strive to put the user at ease. We use an everyday conversational tone in our products to achieve this. We are helpful, encouraging, and are there to support the user in every step of the way.

Encouraging

Not all of our users are confident with tech. Nor will they always be 100% certain about how to complete a job. Some might even have no idea what they're looking for. That's fine – we're here to show them, and reassure them they're on the right track. Our tone reassures the user, and encourages them to make decisions with confidence. We might even occasionally pat them on the back for a job well done.

Approachable

Users should never feel alienated by our products. The language should be simple to understand, and everything should always be clear. We shouldn't worry them, or admonish them for doing something a wrong. Our products should guide them down the right path with a gentle hand, and encourage them to feel relaxed and at ease.

Personable

Finally, our voice is friendly. Our products are a collaborator, not a service. Our relationship is not business-to-business, it's person-to-person. A user should never feel like they are interacting with a machine, they should instead feel like they're working on a project with a co-worker.

Contents

Finding Our Voice

Okay, now you know what our voice is. It's friendly, but it's professional. Our voice inspires confidence, but feels like a member of a team. How can you be both professional and provide a genuine connection? Read on to find a few pointers to help you achieve our tone of voice. If you ever aren't sure, you are encouraged to contact the UX Copywriter: samuel.bright@oneadvanced.com Achieving a professional, approachable, and friendly tone of voice can be done in a few different ways:

Be efficient, but don't cut corners

Use full sentences
Do not use slang
Treat the user's time with respect

Avoid the usage of “lazy” language in all instances. This includes things like slang and turns of phrase. Slang and idioms may shorten the message you need to deliver, but it will come across as sloppy and lacking in professionalism. Copy in our products should always be complete sentences, where possible, and use proper English.

This is a difficult habit to break, and I am sure you will smile once or twice while reading this document when you notice I have not followed my own advice - but that is because it is hard to avoid. We naturally write in our own tone of voice, even when being professional, and the vast majority of people use slang all the time and "don't speak proper English". The most annoying part? It's normally grammatically correct, and most word processors will not pick it up reliably. The easiest way of making sure you do not do this is getting somebody else to look over your copy before publishing it.

Obviously I'm not going to use slang! ...Right?

Some slang is really obvious. I, a Devonian, do not blink twice when I hear someone call a woodlouse a “chickypig”. But, I am fully aware that me using that word in the company of someone not from the fertile south would be met with confusion. This is the kind of confusion we want to avoid in our products - using a term for something that is not universally applicable. It also adds to the professional tone of voice - we would not call an invalid URL a “dead link” for example.

However, some slang is sneaky. Sometimes, we go our whole lives knowing a word, without realising that it is actually a slang word. This is really difficult to “learn” how to avoid: if you do not know something is slang, you are not going to question it. Here are a couple of applicable examples:

Phone support - this is slang. “Phone” is not a verb. Well, it is. Sort of. It is in the dictionary and most people would know what you mean, but it is a widely-used informal word. This is an example where we are less worried about the loss of meaning, and are more worried about the impression its usage gives. The “correct” words are “telephone” or “call”. It would be much better to say “Call support” for this example.
Click the button - another sneaky slang word. “Click” comes from the sound the mouse button makes when you press it - also, it is not a very inclusive term, what if someone is using a tablet, or keyboard controls? Really, this should be “select/press the button”.

There is not an easy answer for this one, and mostly this will come down to other people spotting your mistakes and correcting them. Most people have a gauge of what language is informal and formal, and this generally comes from an innate sense of what is slang and what is not - so, in best practice, if something feels “too informal”, double check it and ask someone else to take a look.

I'm not great at grammar - can you help me out?

In short, no. This style guide is not going to be an A-Z of how to write proper English. Language is expressive, nuanced, and not standardised. Hence, why we have a **style guide**, not a ruleset. What I think of as ‘correct’, others will disagree with. There are basics, sure, but the scope is far too huge for me to cover here. Throughout, I will be giving some common misconceptions and easy mistakes, but in all likelihood your grammar is not going to be perfect…

and that is fine! Anyone that tells you they have perfect grammar is lying or trying far harder than they need to be. I definitely make mistakes. Sure, perfect grammar makes us look super fancy and really professional… But, the English language evolves. Perfect grammar is not a requirement in the 21st century, and it can be quite easily argued that what people think of as “good grammar” is outdated. A lot of the time, “good grammar” makes reading more difficult, unless you know grammar really well. We have a diverse range of users who respond differently to levels of reading complexity, and honestly: I prefer something being understandable to it being correct. Semi-colons are confusing, they stick out. Oxford commas are technically correct, but people look at them and smile to themselves because they think they have spotted a mistake. Nobody really knows (or cares) if you should use “whom” instead of “who”. We want the meaning to be clear - “good grammar” comes second to that. In addition, being overly formal and having perfect grammar is going to make the products feel unapproachable and inhuman.

Controversial opinion, I know, especially from a copywriter, but our goal here is to make language accessible, understandable, consistent, and readable. For the most part you do not need to worry about grammar beyond the basics. And, get ready for a phrase you will hear a lot: you should get somebody to double-check your copy. Any huge grammar mistakes can and will be easily rectified.

However – keep in mind the user's time is their most valuable asset. Writing wonderfully beautiful prose with nary a mistake in our products is all well and good – but don't overdo it. Be clear, straightforward, and don't waffle. Write your system message, then see if you can cut the word count in half without losing meaning or sentence structure. It's a hard skill to master, but definitely possible.

Mind your P’s and Q’s

Our products should be polite to the users - a simple “please” or “thank you” adds a personality to the products, and will go a long way to helping the user feel their time is valued. It is a small thing that adds a lot of value to copy.

Be polite
Appreciate the user
Be careful of structure

Whenever a user is asked to perform an action in a long-form message, something that is longer than 3 or 4 words, then we should include “Please” in the sentence. This is appropriate for things that are outside a user’s normal workflow and not immediately obvious - “press submit” doesn't require a please, but “Your changes haven't been saved yet. Please press the save button before leaving the page.” should. This can lead to some dodgy sentence structures, so refer to the expandable note below for guidance.

Similarly - we should thank a user for their time! When appropriate. Thanking them for every single step they take within our products will get very stale very quickly. A “thank you” should be reserved for actions outside of a common workflow, or when the product has been “given” something by the user. For example, after a user sends a bug report or submits a form, they should be thanked.

Can you tell me how to ask someone to do something, please?

Instructions that the user is given should include a “Please” at the start of the sentence in the vast majority of cases, to avoid grammatical errors. Ending a sentence with please requires a comma, and it takes up valuable screen space and sometimes requires an entirely separate clause in the sentence. Take the two following examples:

Please press submit
Press submit please

Example 2 should actually read “Press submit, please”. But - imagine that in a modal? Imagine it without a full-stop. Example 1 works fine as a message without a full-stop, but “Press submit, please” looks very strange without a full-stop.

This is a problem that is extremely context-sensitive, and the answer to most of the problems that arise is “it works fine with the please at the beginning”. It will not work in all sentence structures, ask somebody to double check when in doubt.

Elegance in Simplicity

There is a tendency to overcomplicate a matter when you know the inner nuts and bolts of a product. “Booking an absence” may well technically be “submitting an absence request”, but the user does not care what is happening under the hood of the product. Complex concepts need to be broken down into their simplest parts.

The copy in our products needs to be clear and concise. Users use our product to cut down on time so they can do their job more efficiently. We are helping them solve a business need - we should strive to make that as easy as possible. If a user reads something in our products and needs to think for a moment to work out what that means, we are doing our job badly. Often this comes about from us (as the creators of a product) becoming supremely familiar with workflows and steps taken to achieving a process - the user does not care how it happens, they just care about the result.

Unnecessary detail needs to be stripped out of messaging. Take the above example: if a user wants to book an absence, they want to book an absence. They don't want to submit an absence request. Call a spade a spade, not a utensil for moving soil.

Context also plays a role in this. Sometimes, we provide much more detail than is necessary. Surprisingly, we can give our users some credit when it comes to reading between the lines. If the context of piece of copy does some of the heavy-lifting, we do not need to reiterate that message. For example, if we were submitting a timesheet for a user, we may be tempted to write a message saying: “[Person X]'s timesheet for [Week Y] has been successfully submitted”. A simple “Timesheet has been successfully submitted.” will suffice - the user knows that they have just been filling out a timesheet for Person X in Week Y, they do not need to be reminded.

However, accuracy is also important. Do not skip over important elements of a message because it is quicker to not mention them. But, be wary that it is possible to be too accurate. General beats specific, unless specificity is important.

Target Audience

Prioritise clarity over style
Identify and understand your expected users
Use jargon where appropriate

When writing copy within products, your end-user should always be at the forefront of your mind. Useful copy is more important than beautiful copy. When you are creating your system messages, you must consider who will be reading them.

Professionals in different industries will have different expectations of the software they are using, in particular around things like formality and complexity. Copy should be catered to these individuals - users that using our products aimed at the legal sector would expect a a lot of industry-specific terminology and common parlance, for example. This will be vastly different to a product aimed at a wider range of users like one of our HCM products. The ‘feel’ of these products should remain largely the same - to preserve the OneAdvanced product identity - which will be achieved through the tone of voice guidelines above; however, while writing copy you should be aware that different users have different needs. This will be mostly achieved by how you approach Jargon within the products.

Jargon is a series of words that are associated with a niche community of people - for example, those interested in a particular hobby will know the ins-and-outs of their hobby and either use short-hand or specialised terms that will only make sense to them. For example, within the tech community, most developers would know that ‘rubber-ducking’ is explaining to a rubber duck how their code works, in order to go through a process one step at a time and hopefully spot a problem. This is the same within the industries we aim our products at. You should hopefully be aware of the kind of jargon used within the industry you are currently working with, and there are a few guidelines below on how best to use these.

Industry Jargon

Not all users speak the same language

Users of our HCM products are not always guaranteed to be particularly familiar with HR processes, so it needs to be approachable for someone who is not aware of those. On the other hand, we can be confident that somebody using our financial solutions will know what a pay period is. Jargon is encouraged when it is industry-specific terminology that a professional in that sector can be expected to know - as long as that professional is the expected user of the product. If this is ambiguous, then we need to take care in how we use jargon.

Take, for example, a fictional product that allows an employee of a company to record their worked hours into a timesheet, and gives them an expected payslip. That timesheet is then submitted to the payroll administrator for their company, who works their financial magic on it to pay them. We have two users here - the employee, and the payroll administrator. The payroll administrator will probably use things like the employee’s full-time equivalent salary and their tax code, and also worry about additions and deductions to the employee’s pay, and enter values for their holiday pay and statutory sick pay… stuff that sounds like accounting wizardry to a layman. In this instance, the target audience for the two separate parts of the product are vastly different. Jargon must be applied differently in these two scenarios, catering for the end user. If it is not reasonable to assume that a user knows an industry-specific term, then either it should not be used, or an explanation should be provided.

Technical Jargon

Have an awareness that you are a tech expert, but your user is not

One thing we cannot be sure about, however, is the computer-literacy of the end user. We, as employees of a tech company working in the software industry, know far more than the layman about how our products work. We are comfortable using specialised terms for areas of our products, as it is ubiquitous language among our colleagues - but, our users (probably) are not well-versed in this kind of terminology.

It is absolutely best to avoid technical jargon wherever possible. A message that says something like ‘the function was unsuccessful due to this technical error’ will mean little to a regular user, but ‘We could not do that because your X is not Y' tells them exactly what they need to know. It may be reasonable to surmise that most in the 21st century are familiar with topics like that, but we cannot assume. Technical problems within our products need to be explained simply to the user to avoid alienating them. The worst outcome would be our user being presented with an incomprehensible mess of technical detail, and having no idea what they are looking at - this would discourage them from using the product.