Why developers need to take microcopy seriously

Microcopy are all those tiny pieces of text that aren't really editorial content, but rather describe a feature (or result) to the user.

So what does that have to do with you as a developer?
Fact is, you write microcopy all the time - and you may not even be aware of it.

Microcopy is in form labels, placeholders (form hints), aggregation headings, and error/confirmation messages.
It's in content type names, property captions, tab names, button texts, and dropdown list options.

Some of these are visible to visitors, while others are visible only in the editor's interface in the CMS.

Trivial, isn't it? Just put whatever text in, make the feature work, and users will figure it out.

But the truth is:
Even if your code works flawlessly, poor microcopy can cause a bad user experience.

Poor microcopy can be confusing

• Unclear content type names can make your editors select the wrong one when creating new content (causing time-consuming cleanup work.)
• Ambiguous property names can make your editors select the wrong kind of content reference or media type (resulting in errors or empty listings.)
• Illogical tab names can make it difficult for editors to find a particular property or setting (wasting precious time or giving up entirely.)
• Vague button texts can make a user fear what will happen when it's clicked (making them hesitant to proceed.)

What was the difference between "Settings" and "Configuration" again?

Poor microcopy can be distracting

• Un-translated form labels may hinder users from completing the form (costing you conversions, or increasing your support load.)
• Weird phrasing can break your attempts at a consistent tone-and-voice (users will notice).
• Out-of-context translations can make your site seem rushed or low-quality (globalization was an afterthough, huh?)
• Undescriptive filtering/navigation options can make users lose track of where they were.

Every single Norwegian editor is mystified by the weird/out-of-context translation "Skjemalegg publisering" (schedule for publishing) in EPiServer CMS.

Poor microcopy can be annoying

• Too technical error messages can anger users that don't understand what they mean.
• Too vague error messages can upset users that don't understand how to troubleshoot the problem.
• Missing confirmation messages can make users think their request wasn't submitted properly (then trying repeatedly.)
• Properties displaying their technical name instead of a useful caption can make editors feel their workspace is messy (which makes content creation a chore.)

Properly captioning a property can make a big difference to the user.

Poor microcopy can even be dangerous..

As an example from the real world, I found this sign on the bathroom door of a cruise ship cabin:



Dangerously poor microcopy.

The English version conveys the warning message in one simple sentence.
But the Norwegian version is twice as long - and even has one line in a smaller font!
(Literal translation: "The cabin floor may be very slippery! Please be attentive if you have wet feet.")

Someone clearly either spent too little time on this particular microcopy - or completely overdid the Norwegian version of it.
Anyway - a warning sign that cannot quickly deliver its message, has failed.

(Imagine if the "STOP" sign was neglected this way..  Hat tip @arvesystad)

But I write code, not copy...

Sure, that's mostly true. But when building a site, developers encounter way more microcopy than the designer or content strategist could anticipate in their specifications.
(When was the last time you saw a design spec that covered every single mode of a page type or feature?)

Also, most of these texts are static, hidden away in language files or database strings (or *horror* hardcoded into templates) - places where editors don't see them until they suddenly appear on the site.

As a developer, you will uncover the need for additional content types, properties, headings, buttons and messages.
It's your responsibility to address them properly as you go along.

If you have writing skills and a good grasp of the site's intended tone-and-voice - give it your best shot.
Or, you can delegate the task to someone with a flair for writing.
In any case, it might be worth making a list of all those newly discovered pieces of microcopy, so you can review them with a designer, content strategist or the site owner.

Developers often give lots of thought when naming classes, interfaces, variables and properties.
Still, we are notoriously bad at creating text that's meant for user consumption.

Even with practice, writing good microcopy is a skill that's not for everyone.
But by being more aware of them and handling them appropriately, we can help increase the overall quality and user experience of the sites we build.