Not all content on the GlobalScot platform is long-form articles, web pages and news stories. Sometimes, a piece of content will be as short as a button, notification or error message.
When it comes to writing microcopy, these are our key principles:
- Concise – get to the point quickly by cutting out unnecessary words and messaging. This takes less time for the user to read, and fits better into the UI.
- Simple – use plain English and simple language to make sure users understand what we’re telling them.
- Helpful – where possible, microcopy should help the users resolve a problem or move onto the next step. Instead of just telling a user what’s gone wrong, offer them a solution.
Getting the information you need
Before you write microcopy, it’s important you understand the context of what you’re writing. To do this, you’ll need to ask questions, and probably lots of them. Work with designers, product teams and developers to get a clearer understanding of the message you need to give to users.
Here are a few things you might want to consider for different types of microcopy.
Buttons
- Where exactly will the button take them?
- What information will be on the next page, and what wording is used?
- How could users interpret the wording we’ve used?
- Are users ready for this CTA? For example, we might want to use strong wording like ‘Apply’, but a user might avoid clicking it if they want more information first.
Form fields
- What exact information do we need from users? Get in touch with internal product teams to find out what they need
- What format do we need this information in? How will it be used?
- Could help text make this field clearer?
Validation text
- What errors could be made in the field that would trigger a validation error? For example, in an email address field, there could be multiple errors – a user doesn’t enter anything, a user enters an email address but misses a crucial part like the ‘@’ symbol a user enters an email address but it doesn’t match any we have in our system.
- Can separate messages be created for different validation errors, or can we only have one message per field?
Tooltips
- What information do users need to know to be able to complete a field?
- Have we considered all scenarios? For example, it’s useful to tell a user where to find their Companies House number, but could there be a scenario where a user doesn’t have a Companies House number for some reason?
Error messages
- What exactly has gone wrong?
- Has the user done something wrong or is it a system error? Could it be either, or both?
- How much difficulty will this cause users? For example, if they’re halfway through the form, will they lose all progress or can it be recovered?
- What can a user do to fix the problem?
Some of the most useful questions you can ask when writing microcopy is ‘What happens if…’ and ‘Could there be a scenario where…’. Try to think of every possibility for the user, and write copy that will help them.