Not every product team has someone dedicated to crafting every word on the interface. But unfortunately that means you have to pick up the slack.
Whatever role you play in your multi-disciplinary team (be it a product owner, developer, visual designer, tester or anything else), you own the experience. That means you own the words that help users navigate, use and enjoy the product.
Half-arsed microcopy is half-arsed design and that means a half-arsed product.
So you should give interface writing a go yourself if no one else is giving it any thought. And you shouldn’t feel unqualified to do so.
I’ve prepared a checklist that will hopefully help. Pass this around your team, add it to your exit criteria or definition of done and be sure to shout loud if you’ve noticed the words aren’t working as hard as they could be.
The microcopy checklist (in short)
- Is the copy useful?
- Is it succinct?
- Is it transparent?
- Is it human?
- Is the copy in the design?
- But is it actually useful?
1. Is the copy useful?
Every piece of microcopy should help a user complete a task — it’s there to educate, explain and simplify processes. If it doesn’t help, you should question why it’s there.
Take an error message, for example. This tells a user that there’s an obstacle to completing their task. So it needs to explain how to navigate that obstacle and reach their goal. This could be as simple as providing a “Forgotten password” link on a failed login screen — not just stating that their input is incorrect.
If it’s not useful, it’s not needed. UX writing is as much about ruthless editing as it is about writing.
2. Is it succinct?
99% of the time your first attempt at copy will use too many words. So sneer at everything you jot down and edit like there’s no tomorrow.
Tools like the Hemingway app help keep your copy clear and to the point. Sure, it might put a dampener on your creativity, but it’ll help you cut the fluff in no time.
Long words and complex sentences will only ever make you cool in school (with your teachers). The real world will find you confusing or pretentious.
Be sure to use an active voice instead of a passive one. It’s not only punchier, but is far more likely to encourage action and aid comprehension. Hemingway can help with that too.
Brevity not only helps users complete tasks quicker, it keeps your interfaces compact yet valuable across devices.
3. Is it transparent?
Is it clear why?
Remember when you were a kid and you’d question everything…
“Eat your vegetables”
“Because they’re good for you”
From an early age, we question most things. We’re uncomfortable with the unknown.
And the internet is full of unanswered questions. Take most forms…
“Give me your email address”
“Give me your phone number”
When the UX writing is good, interacting with a website or product should feel like a conversation. When our interfaces leave customers guessing, it feels one-sided and creates friction.
Customers are more likely to engage with you when you’re open and transparent about your intentions. They want to know why you’re collecting their data. They want to know how many steps there are to a flow. So make sure you keep them in the loop wherever possible.
4. Is it human?
You might be writing the most functional UX copy in existence for a “B2B” cloud platform but you always need to write for the human on the other end of the screen. B2B is a misleading, bullshit term from a writing point of view. You’re always writing for a user, so you should always make sure your copy sounds like it’s written from one human to another.
Use plain English, assume no existing knowledge and avoid any complex jargon that the average person wouldn’t use. Attend as many interviews/testing sessions as you can to start understanding how your users talk.
One rule that will work for you in 9 cases out of 10: if you have to look it up, don’t use it.
5. Is the copy in the design?
Ok, so your copy’s transparent, succinct and useful but this isn’t enough. You need to consider its relationship with the visual and technical elements. It’s why it’s so important to design the words alongside the rest of the process and not before or afterwards.
Imagine you’ve written an absolute killer piece of help copy for a form field. It’s then decided later on that in order to reduce scrolling, this help copy will sit within the field. As soon as the user begins to enter the information, all that help you’ve crafted is gone, leading to an increased risk of error. Even the best words can’t do their job if they disappear. So include words at the sketch phase.
Try not to use squiggly lines in place of words. I spend a lot of time with a sharpie to make sure the visuals, words and features all work towards a common goal from the earliest possible point.
6. But is it actually useful?
Test the words. Your team may not have enough budget to do formal user testing. There may not even be time. But there’s always guerrilla testing. Bug people around the office or buy them a coffee in exchange for their thoughts and insight. Even if they’re not strictly your target users, they can help validate clarity, hierarchy and whether or not the copy helps or hinders the experience.
In advance of speaking to anyone, remember to PEE. Think about:
- The P urpose of the interaction… does the copy help the user complete their task?
- E diting… Are all words needed or can you cut them down? Does the user care about everything you’ve said? Maybe you actually need more words to solve a usability issue.
- E xtra value… is there a way to offer more information or be more helpful? What else does the user want to know?
Structure your conversation around this to validate whether the interface’s microcopy hits your objectives.
Note down any questions the user has and if it’s a common theme work the answers into a second iteration.
Even after you ship, consult the data often. Copy changes really can help bring you closer to what you want to achieve.