Content
This guide will talk you through the different way text content should be formatted and presented throughout our products. Reading through these guidelines is essential to making sure that our products are consistent across the whole suite.
This document won't tell you what to write – you can find that in Tone of voice – but instead how to write something, i.e. what to capitalise, how to format a table, etc.
Consistent voice, tone, and style will create an environment where our users are put at ease, and become familiar with the products and know what to expect. It's like them learning 'our' language – they will quickly begin to understand us, and cross-product usage will become quick and easy.
This guide is broken down into several tabs, which each cover a major area of styling your copy:
Conventions details the standard way we use the rarer parts of copy, like acronyms, currencies, dates, et cetera. Visit this tab to learn about things that are a bit more complicated than writing a simple instruction.
Formatting covers how to style your text. Things like when to underline and when to use colour are covered here.
Punctuation will instruct you on how to use punctuation properly. This is more in-depth than when to use a full-stop, it details where we stand on things like the usage of ampersands (&) and whether or not to use an oxford comma.
Quality describes the impact of good-quality copy and how to achieve that.
Structure deals with how to lay out copy on a page. Go here for guidance on things like when to use a subtitle, and dealing with white space.
Contents
Abbreviations
An abbreviation is when you shorten a word, i.e. using Hr. instead of hour. In general, the usage of abbreviations should be avoided – they can often get confusing. As an example, using Hr. for hour might be confusing in OneAdvanced HR!
If an abbreviation is absolutely necessary for a page to work (for example, when space is limited), they are allowed – this should be avoided as best as possible, however.
Ampersands
Ampersands (&) should only ever be used when referring to an entity with an ampersand in the name (e.g. Jonathan Strange & Mr Norrell).
In rare cases, they may be used in places like tables where space is limited. If you do choose to use ampersands in this way, make sure it is consistent on the same page - it's very confusing to have a table that uses both 'and' & an ampersand and seems to use it interchangeably and without warning & logic. That sentence read really weirdly, didn't it?
Initialisms and Acronyms
Did you know there’s a difference between an initialism and an acronym?
An Initialism is where a phrase or name is shortened into the first letter of each word, but spoken still spoken as letters (i.e. European Union becomes the EU).
An Acronym is similar in that it takes the first letter of each word in a name or phrase and forms a shortened version of the word, but it is spoken as a new word (Self-contained underwater breathing apparatus becomes ‘SCUBA’).
Initialisms
Whenever you use an Initialism, it should be formatted as a series of uninterrupted capital letters, i.e. PDF not P.D.F.
An initialism should be qualified the first time you use it in a user journey if it is not ubiquitous to remove ambiguity (you can find a list of ubiquitous terminology in our reference section). To qualify an initialism, you should write out the full phrase and then provide the initialism in brackets afterwards. For example, if you were setting up Statutory Maternity Pay (SMP), the first time a user sees it they should see it as Statutory Maternity Pay (SMP), and then SMP can be safely used throughout the rest of the journey.
Acronyms
Similar to abbreviations, acronyms should be used sparingly. However, they can be very effective to shorten a long term that is repeated often. An example of this is a "Keep In Touch day" in payroll – it can be very useful to shorten this to "KIT day" on the KIT day management screen.
Whenever an abbreviation is used, the first time it is used on a page or workflow should include the phrase in full, followed by the abbreviation in brackets, i.e.:
"To book a Keep In Touch day (KIT day), open the…"
Additionally, you do not need to use full stops after each letter of an acronym – it is NATO, not N.A.T.O.
You are free to use acronyms if they are very common, i.e. things like i.e. and e.g., without qualifying them.
Capital letters
PLEASE DON'T SHOUT AT THE USERS. Writing copy in all-caps makes text very difficult to read, and is not necessary. If something requires urgent attention, you can use other methods to call attention to it (such as modals, highlights, disabling buttons, etc.)
Currencies
When writing a currency, always use numbers to display the value, and currency symbols always go before the number, not after.
You should also use a comma to separate large values (e.g. £1,500) and smaller denominations (such as pence) follow the integer value with a decimal point, and do not require a currency symbol (e.g. £1.50, not £1.50p)
Ranges only require a single currency symbol, e.g. £100-200.
Time
We use 24-hour times across our products in general. There are exceptions to this when it comes to denoting time periods - for example in OneAdvanced HR you can book annual leave “Starting in the AM” and “Finishing in the PM”.
Unless there is a strong reason not to, you should use 24-hour time as a default. 24-hour time is the 'default' because of the slight implication that 24-hour time appears more accurate. In reality, this isn’t true, however it appears more professional and eliminates absolutely any ambiguity (is 12PM midnight or midday?).
However: if possible, you should give your users the choice. Some users will strongly prefer one over the other, and there isn't really a reason we shouldn't give them the choice. This should also be done at the user level, not organisation level. Some forms of dyslexia mean 24-hour time is difficult to read, and some users from different backgrounds will have grown up using different forms of time. If the product can be tailored to the user’s personal preferences, it should be.
24-hour Time
HOUR:MINUTE - we separate the hour and the minute with a colon, e.g. 13:30 would be half past one in the afternoon.
Midnight is the start - midnight should always be 00:00, not 24:00 (Seems obvious, but I have seen some people write it as 12:00 AM which is frankly baffling).
Always at least four numbers - 1am to 9am still need to include the minutes, i.e. 01:00 or 23:59. You can add a 5th and 6th digit to include seconds: 10:00:52 if required.
12-hour Time
12-hour is formatted with colons between each value – i.e. "hour:minute:seconds AM/PM".
Also note that "AM" and "PM" are always capitalised and are separated from the time value with a space.
Time ranges
When you need to write a time range, the start and finish should always be separated by a hyphen and spaces. Including the space shows a visual distinction between the two times and reduces confusion, i.e.
13:00 – 15:00
9AM – 3PM
Dates
Below is a table outlining how and when to use different date formats across the products, and how to include time in them. An easy rule to remember when writing the date is the hierarchy, going from most specific (time) to least specific (year).
Type | Usage | Single date | Date range | Date range with time | Notes |
Date hierarchy | Everywhere | Time, day, date, month, year | Hyphen with spaces either side | Time and then date | English standard, not American |
Long format | System messaging, appointments, dates displayed as plain text | 1st January, 2021 | 1st January, 2021 - 5th January, 2021 | 09:00 1st January, 2021 - 13:30 2nd January 2021 | Use full month, with day with appropriate suffix and make sure you include the comma |
Long format day included | System messaging, appointments, dates displayed as plain text when a day is desired, and space is available | Monday, 1st January 2021 | Monday, 1st January - Friday, 5th January | 09:00 Monday, 1st January 2021 - 16:30 Friday, 5th January | Day - comma - date with suffix - full month name |
Shorthand plain text | Elements with limited space | 01 Oct 2021 | 01 Oct 2021 - 05 Nov 2021 | 09:00 01 Oct 2021 - 16:00 05 Nov 2021 | Including the 0 is important on the date, as it makes things more readable and leaves no room for ambiguity |
Shorthand within tables, menus, etc | A date in a table, drop-down menus, date picker. | 01/01/2021 | 31/12/2021 - 01/01/2022 | 09:00 01/01/2021 - 18:50 02/01/2021 | We use a / rather than a – to reduce confusion around date ranges |
Shorthand day included | Toast messages, tables with sufficient space | Mon 1st Jan 2021 | Mon 1st Jan - Fri 5th Jan | 09:00 Mon 1st Jan - 14:30 Fri 5th Jan | Shorthand day - date with suffix - shorthand month |
Condensed Range | Elements with very limited space that need a date range | - | 01-05 Jan 2021 31 Jan - 03 Feb 2021 | - | Note the different formatting when the range spans two months. Including times when space is this limited will be difficult - we would suggest allowing the element to be expanded to see the time. |
Industry Terms
Industry terms must be used consistently across your product, and you need to be mindful of the users in question when including them. You can read more in the Tone of Voice guidelines.
Labels
Text labels should be used throughout your product any time you have an element that can be interacted with (i.e. a Button or form field). Ideally, they should be no more than one or two words long, and they should provide the context for their purpose.
Labels should stick to familiar and meaningful phrases, such as ‘Save’ and ‘Contact us’.
Labels should also be in sentence case.
You should try and remain consistent when labelling throughout, and avoid using different terminology for the same action on different pages. If you use ‘Cancel’ on one modal, it should stay as ‘Cancel’ on other ones and not change to ‘Discard’.
If you have many similar labels on a page, consider eliminating the redundancies. For example, if a user is on a tab labelled ‘Client’ and they are filling out form fields that describe the client’s details, you do not need to name each field ‘Client forename’, ‘Client surname’, and ‘Client address’. You could simply put ‘Forename’, ‘Surname’ and ‘Address’.
Links
Links are a really useful way of helping your user on their journey through the process. If you are talking about another area of the product, consider linking to that area within the text.
Links should also be readable by screen-readers and should not be an instruction. The copy making up the display text of the link should be descriptive of where it leads, and shouldn’t say things like “click here to book an absence”. Instead, that should simply say “book an absence” and visually look like a link. Links shouldn’t be ambiguous as to where they lead, and you should take care to make them succinct and informative.
Numbers
If a number is on its own in a body of text, there are a few things you need to consider:
- Zero to nine should be written out in full, (one, two, three etc.), but 10+ should be written out as digits. Three hundred and two thousand six hundred and twenty nine is really difficult to read, 302,629 is much easier.
- Ranges should be separated by a hyphen (1,000-2,000), and ranges that include a suffix (such as those with a unit of measurement or a percentage sign) only need to include the suffix at the end of the upper-range digit (i.e. 5-10 minutes, 65-82%).
- When you get to numbers with four or more digits, every 3rd digit from the right should be preceded by a comma (i.e. 1,532,301). This promotes readability and helps users who struggle to read large numbers separate the separate parts of the number out. In the previous example, they can see the millions, thousands and hundreds of the number.
- Numbers that precede units of measurement should always be written out in digits, even when <10 (i.e. 3KB or 5m).
- Percentages always use digits, and are followed immediately by the percentage symbol with no space (i.e. 3%).
Contents
Bold text
Bolded text is allowed within products as long as you are emphasising a small amount of the text. Bolding should be reserved for small pieces of key information. This can include things like dates or names.
Ensure you do not overuse bolded text, as it can be jarring for the user if there are multiple bolded words across a single paragraph.
Outside of a product, such as in supporting documentation and customer communications, bolding should be used for the names of products and their features. This is to indicate to the reader that you are referring to something specific within the product, and not something generic. For example, in OneAdvanced HR, an Absence (as in a booked period of time off work within the OneAdvanced HR system) should be bolded to differentiate it from an absence in general.
Headings and subheadings should always be bolded, and bolding can be used in bullet points to promote a visual hierarchy in your copy.
Italics
Italicised text should be used sparingly. Research suggests that large blocks of italics are very difficult to read for dyslexic users. In addition, italicising large blocks of text defeats the point of italics, which is to draw attention to something that is different from its surrounding parts.
Small pieces of copy (10 words or less) can be italicised to differentiate them from other blocks of text on the page. This might be appropriate for small notes highlighting something on a page, like a note matched with some text by an asterisk (*) that is qualified further down the page.
Italics should also be used to refer to entities not related to OneAdvanced, such as government bodies (HMRC) or the name of a book or journal (The Sunday Times). Quotes should also be written in italics.
Underline
Do not underline text for emphasis. It may confuse users who are expecting a hyperlink. Headers shouldn’t be underlined either, they should use a larger font and be bolded.
Bullet points
Bullet points can be used within your products to create lists of information or options. However, you must ensure the underlying code meets accessibility guidelines for screen readers.
Whenever you use bullet points, ensure they are introduced with a colon (:) that immediately follows the last letter of the last word in the preceding copy:
- This list is introduced with a colon
Seriously, don’t forget the colon!
- This list was not introduced with a colon, whoops
Each list item in a bullet point list should also begin with a capital letter, and should not end in a full stop:
- List item 1 is correct
- list item 2 is incorrect.
However, longer list items that require intermediary punctuation should be finished with a full stop:
- Longer list items break the rules. If it contains a full stop, then it should end with one as well so you don’t have a trailing sentence that don’t seem to end.
Contents
Apostrophes
Apostrophes are used to denote several things:
- ownership, i.e. the cat's pyjamas
- remember that ownership with plurals comes after the s, i.e. the Johnsons' house
- contractions, i.e. I can't be bothered to write the full word
- time, i.e. four o' clock (although remember to read the guidance for time in the [conventions](guidelines/style-guide/#conventions section)
- apostrophes can also be used to delineate something a bit 'weird' in a sentence, where you're alluding to something that is unclear, rather than quotation marks (which should only be used for direct quotes). These are normally referred to as "single quotes".
Brackets
Brackets should be used when you want to give information that may be useful but isn't important to a sentence. However, brackets should be brief and should not be a sentence in and of themselves.
When using brackets, ensure that the full stop is outside of the bracket (this is really important).
Similarly, ensure that there is a space before the bracket(starting a bracketed phrase right next to the sentence is very incorrect). If you're putting a bracket in the middle of the sentence (like this) ensure that there is also a space after the closing bracket.
Please do not go down the rabbit hole of brackets-within-brackets (it looks really unprofessional (promise)).
Square brackets shouldn't be used in copy, unless you are directly quoting from something, or are clarifying a pronoun, i.e. they [the client] didn't understand why we used a square bracket.
Colons
A colon (:) is a really useful tool to introduce something that follows it. In fact, it's a requirement! You can use a colon to introduce a list, or to mark out something you have introduced. For example, visit the OneAdvanced website: www.oneadvanced.com.
Here's a few ways to use colons effectively:
- Only use a single space after a colon, i.e. UX Copywriting: a useful tool to making consistent and beautiful copy!
- Words following a colon that introduces something should not be capitalised unless they are proper nouns (unless it's the first entry in a bulleted list!)
- Sentences should only use one colon: this is because of a few reasons: it looks really weird, and you get caught in an endless colon spiral: I now have no effective way of getting back to my original statement and continue listing the reasons.
- Field labels on screens and forms should always use a colon (i.e. "Name:" not "name")
Commas
Generally, commas are used to separate sub-clauses in a sentence to 'construct' a good-looking sentence that is easy to read. A sub-clause is a part of a sentence which is slightly separate to the rest, but not worthy of an entirely new sentence as it does not make sense on its own. See what I did there? An easy way to gauge if something is a new clause is to say the sentence out loud. Quite often commas match up almost exactly to the natural pause you put in a sentence while speaking, but this is not always the case. You will need to use your best judgement for putting a stylistic comma in a sentence. Double check with somebody else if you aren't sure.
However, there are a few places where commas are absolutely required:
- List items must be separated in a sentence, i.e. one apple, two pears, three oranges and a dog
- After an introductory phrase like "for example" or "however"
- Separating adjectives that could be switched around or have "and" put between them, i.e. the beautiful and easy-to-read copy becomes the easy-to-read, beautiful copy
Comma splices
In addition, you should avoid the dreaded "comma splice"! A comma splice is used is when you use a comma to separate to independent clauses from each other. An independent clause differs from a sub-clause – independent clauses are related but expand upon the previous clause. Independent clauses can form complete sentences on their own. Normally, you should use a connecting word like "and" or "but, or use some introductory punctuation like a colon (:), an em dash (—) or a semi-colon (;). For example:
The UX Copywriter loves talking about words, it's his favourite thing to do. – this has a comma splice.
The UX Copywriter loves talking about words — it's his favourite thing to do. – this uses an em dash instead of a comma.
Dashes
Dashes are really similar to hyphens but vary in their appearance and use. You will largely either use an en dash (¬¬¬¬–) or an em dash (—). To write an en dash on a QWERTY keyboard, hold ctrl and press the hyphen on your number pad (ensure you have numlock turned on). For an em dash, hold ctrl and alt and press the hyphen on your number pad (again, ensure numlock is turned on).
En dash
En dashes are used to indicate a range between to values, i.e. 50-100 words to explain a complicated concept is super unrealistic. Typically, this will be used for values, dates and times in your product.
Generally an en dash should not have a space either side of it, but please refer to the relevant sections in the date, time and number range sections of the conventions tab for information around spacing with an en dash.
An em dash is much more stylistic, and is used within copy to separate clauses for emphasis — like this!
Usage of en dashes and em dashes are falling out of fashion, though. They're normally considered 'professional' and used very often in official publications like newspapers and journals. Grammar is constantly evolving, however, and we may see their usage fall away entirely — using a hyphen is way easier and barely anyone knows the difference between the three anymore. For now, we follow the conventions, but watch this space!
Exclamation marks
Exclamation marks (!) are used to express excitement, emphatic statements or indicate importance. They fit into our tone of voice and aren't banned, but use them sparingly. When a paragraph contains loads of sentences with exclamation marks, it can get really annoying! Seriously, I'm not joking! I'm coming across way too overexcited right now!
Exclamation marks can be used (again, sparingly!) to emphasise phrases in the more informal parts of your software. For example, a "Congratulations! You have new feedback." would not go amiss, but "You successfully entered the employee's details!" would come across as a little sarcastic.
They shouldn't be used when you need to be forceful, such as in an error message. Instead, contextual colours and symbols should be used instead.
If you do use an exclamation mark, only ever use a single one. They should also always finish a sentence, replacing a full stop.
Full Stops
Full stops (.) mark the end of a sentence. Use them when you finish a sentence, please (unless you are writing something into a table or a list).
Some abbreviations use full stops, but you should double check beforehand. For example, "Mr" and "Dr" do not have full stops, even though many people use this incorrectly. If an abbreviation with a full stop ends a sentence, you do not need to add a second full stop.
Initialisms should never have a full stop in them, for example it is the "EU" not the "E.U.".
Hyphens
Hyphens (-) are often confused with dashes. They are used to join certain words together to make a compound word. Some examples of this are up-to-date. Correct application of using a hyphen often comes with simply knowing whether-or-not a phrase uses them, much like spelling something correctly. If in doubt, you should double check or err on the side of caution – you will often find it is a stylistic choice. Feel free to hyphenate in your products, but don't fret about missing out hyphens in phrases that require them. However, do be careful of using them incorrectly to avoid confusion.
Question marks
Question marks (?) mark the end of a question. Only a single question mark should ever be used – similarly, remember that they finish a sentence and don't require a full stop.
Quotation marks
Quotation marks (") are used when you are directly quoting speech or written words. They are also used to delimitate the name of something in a sentence when you want to draw attention to it.
They differ to single quotes, which you can read about under apostrophes. Ensure you learn the difference between the two. Single quotes are used for emphasis, quotation marks are used for direct quotations.
When quoting something, ensure that the closing punctuation (i.e. full stops, exclamation marks and question marks) comes after the final quotation mark. If a quotation includes multiple sentences, it is okay to include the punctuation within the quotation marks.
Semicolons
Semicolons (;) are the most confusing piece of grammar, but sometimes the most powerful. They can be used to connect independent clauses to add a natural break in the reader's mind, e.g. "The UX Copywriter really likes to use semi-colons; other people are really hesitant".
You can also use a semi-colon to create really nice looking lists. If you want to qualify each item in a list with an explanation, you can use a semi-colon instead of a comma. For example: "He needs some oranges, for the fruit salad; a packet of ham, for the sandwiches; a few beers; and some crisps."
They are also useful in lists that contain multiple items that are paired together, for example: "Mystery Inc. often splits up into three groups, listed in order of efficiency: Shaggy and Scooby; Fred and Daphne; and Velma".
You do not need to capitalise words after a semi-colon, and you can use multiple semi-colons in a single sentence.
Slashes
Slashes (/) are rarely used, and are mostly just used when there is a choice between two things or listing just two related items. Some phrases use them, like "and / or".
Normally, we encourage avoiding the use of slashes. They can be ambiguous, and often can be worded more clearly. However, if you do need to use one to save space, ensure that there is a space either side of the slash.
Contents
Consistency
Consistency is really important across your product, and the wider suite of products. It really helps to build a consistent identity and won't surprise your users with sudden shifts in tone and word choice.
Ensure that anybody writing copy in your products adheres to the (Tone of Voice)[/guidelines/tone-of-voice] guidance, and this style guide.
You should also decide on terms you use for 'common' interactions. For example, consistently use either "Cancel" or "Close" on modals, etc. If you're writing something, see if you can find another example of something similar elsewhere in the product, or even elsewhere in the product suite.
Spelling
Hopefully this one is quite obvious, but you should never spell a word incorrectly in your product. An easy way to avoid this is writing out your copy in a word processor beforehand and use the built-in spellchecker. Always make sure you check any copy with someone else before publishing it – the more eyes see it, the better!
If you ever use industry-specific jargon, ensure you fully understand the context and spelling of it. It will be super embarrassing if a user comes back and complains that you don't know what you're doing.
Building product familiarity
A really effective way of clearing out confusion in your copy is being clear when something you're referring to is a concept unique to the product. When referring to something like this, ensure that you use a capital letter to indicate that This Is Something You Will Find In The Product. Examples of this includes things like Desks and Applets in MyWorkplace.
This serves another purpose: when words like this stick out of a sentence, it really helps the user with on-boarding! If someone sees a capitalised word and have 'learned' that this means it's something specific to the product, it will encourage them to find out what that is.
Contents
Headings
Headings are big, bold pieces of text that draw the eye of the user. They need to be meaningful and appropriate — if a heading isn't indicative of what's underneath it, then it's a pointless heading.
Headings should only ever be a few words long, anything more than three will be pushing it.
They also go a long way to breaking up the page into logical parts, helping the user locate exactly what it is on the page that they're looking for. If there are distinct areas of a page, make good use of headings to clearly signpost these different areas of functionality.
Subheadings
Don't forget subheadings! They can even further break up areas of functionality into logical pieces.
They also make the page easier to read for a user. Effective uses of subheadings will make parsing the different areas of the page.
Subheadings should always be at least somewhat related to the heading they fall under. If something is entirely unrelated to the heading above it, it should be a new heading.
Paragraphs
Avoid super long paragraphs in your product. Nobody wants to read massive walls of text. You will also find that a properly paragraphed piece of copy will aid in the user absorbing the information.
A new paragraph should be used when you move onto a similar but related topic or idea.
Readability
Break up content or pages into logical chunks. Ensure you use headings, subheadings and paragraphs to leave plenty of white space to give the user's eyes a break. A clustered and cluttered page will make absorbing the information really difficult, and users will often find it difficult to find what they are looking for.
White space is really important when reading large chunks of text. Imagine reading a book without page borders, and white space in the headers and footers. Really hard.
Similarly, your copy should be easy to understand and unambiguous. Refer to the Tone of Voice guidance for more information on this.
Cases
Cases are super weird! What's title case? What the hell is camel case? When should I capitalise a title? When shouldn't I?
Easy! Use sentence case everywhere in your product! Sentence case is like writing a sentence in a book: the first word is capitalised, then the only other capitals are proper nouns and the names of your features.
Sentence case is much easier to read. The advantage of sentence case is that pretty much every letter is the same height, and the odd height of Capitalised Words separates them from the pack. It makes reading really easy for all our users. Sentence case is also just the right level of formality that we want to achieve in our software. Our software wants to appear conversational, and sentence case achieves exactly that.
White Space
The term "white space" refers to the portions of a page that are left blank. This includes things between the breaks between lines in a paragraph, paragraphs, headings, graphics, margins, columns, tables, and a whole host of other things.
White space is not blank space. It isn't wasted. It is a key part of the design of Mosaic. Products that use mosaic are sleek, easy to parse, and approachable. Without white space, the page would appear cramped, busy and cluttered.
Conversely, too much white space makes pages feel empty and incomplete. Use the space available to you, but ensure you tread a fine line between efficiency and visual attractiveness.