Microcopy seems straightforward enough on the surface. It’s the small pieces of text that label the informational/navigational elements on a page: buttons, tabs, links, and that sort of thing.
Well, yes. As with any task, there are usually some pretty logical steps to take to do a fair job of writing microcopy. For example, using language that is accessible by the people who are going to read it is usually one of those logical steps.
Similarly, I think it is safe to say that most would acknowledge and understand that the shorter the copy, the more time it takes to write. Everyone who’s ever had to edit and shorten an essay can relate to that!
But, while there are some things about writing microcopy that merely take some logical thinking and careful planning (and perhaps a little empathy and some user testing, too!), there are aspects of microcopy that can turn unexpectedly complex.
Let me use a microcopy problem that challenged a team I recently worked on as an example. We worked on a tool that was meant to assist a user in comparing two drafts of the same contract.
Believe it or not, we found ourselves arguing about whether the label on a button should have the label “Similarities” or “Differences”. Think about that for a second — similarities vs. differences.
Those words are opposites… How could we possibly be arguing over two words that have opposite meanings?
The contract comparison tool we were developing had a two-tiered goal in presenting information to the user.
The first goal of our tool was to clearly display the two contracts to the user in a way that made it obvious which sentences corresponded between them — in other words, the first sentence in Contract 1 should clearly correspond with the first sentence in Contract 2, the second sentence in Contract 1 should correspond with the second in Contract 2, and so on.
Or, in other words, the first goal of our tool was to indicate clearly to the user the similar sentences between contracts.
And so, here was the support used by the side of our team who was pushing for the word “Similarities”.
The second goal of this tool was to show the user where corresponding sentences between the two contracts differed. For example, if a contract template included a sentence outlining responsibilities of the seller, but the new contract was missing that sentence, that would be highlighted, or “redlined”, clearly in the contract in the tool.
Conversely to the pro-“similarities” half of our team, this side of our team was using this second goal of our tool as support for pushing the word “differences”.
Now, let me clarify the intended purpose of this button whose label was stumping our team: Once the user had uploaded both of the contracts they wishes to compare, this particular button in the interface was intended to “activate” the comparison feature, and thus accomplish both the above-explained goals.
So, this is where our division between the terms “similarities” and “differences” began, and hence why we were arguing about which word should be used to label the button in the tool interface that was meant to switch on the “redlining” of mismatching sentences. Half of us prioritized the tool’s goal of displaying corresponding sentences. The other half of us prioritized the second goal of the tool — the goal of drawing attention to where corresponding sentences differed.
Which one did we choose?
It turned out, after user testing, that users were very confused by the label “similarities”. This was because prioritizing the first goal of the tool, displaying corresponding sentences, was redundant to our users. It could be assumed that users using our contract comparison tool already had a good understanding of which sentences corresponded, as the tool’s purpose was to compare a contract template with a new contract, or two different versions of the same contract. Because of the two contracts’ inherent similarity in content, putting such an emphasis on displaying corresponding sentences was unneeded.
Where the users needed guidance from our microcopy, to clue them into where their contract(s) needed attention, was in viewing the sentences that differed between the two contracts.
Though merely labeling our button with the word “differences” did not eliminate usability issues in our tool, it did greatly alleviate a lot of our users’ confusion surrounding this button and its expected function. When it came down to it, our users wanted to know where their contracts differed because that was where action was needed. Those were the sentences and phrases where editing was required to ultimately ensure contract compliance… and contract compliance was our users’ main motivation for using the tool.
Targeting the user’s main motivations is essential to writing useful copy — especially microcopy. When you only have one-word’s-worth of copy to put on a button that wields the main function of a tool, you have to make sure that label reflects the main goal of your users.
When else would a team find themselves arguing over words that have opposite meanings for labeling the same button?