The invisible pieces of microcopy you’re forgetting

Add these pieces of microcopy to your UX checklist.

Whether you’re working with wireframes, designed screens, or post-development screenshots, when you’re writing the microcopy you’re usually working with screens from the main flow.

This is why it’s so easy to forget the power of states, even though that’s where we really need microcopy. (I’ll bring some examples for this in a moment.)

Read more: Who should write your microcopy?

So, what are the hidden parts of UI that can’t fall through the cracks, and should be added to your UX and microcopy to-do checklist?

1. Empty states: Preliminary and ongoing uses

A. Preliminary use
What are your users going to see in their first empty state, before they actually do anything?

For example, I recently wrote the microcopy for a complex system that shows monthly deadlines that have already passed, and are now late; however, the system only knows that the deadline has passed after a whole month of use. So, what will users see on this page during the first month?

Take note that the initial empty state is not the same as ongoing empty states. In this system, the initial empty state has to be developed to address a preliminary situation when there are no late tasks yet because the system hasn’t been used for long enough for a task to be late. It might be educational and explain how the system works and when you should come back. In addition, the UX designer and the microcopy writer has to address an empty state for the user who hasn’t missed a deadline even after the month passed, just because they are good at sticking to their schedule. This one can give the user a pat on the back and encourage them to keep up the good work. Both of these situations demand their own separate use cases and microcopy.

In the wireframe that I received, the UX designer thoroughly noted all the details of the deadline to be presented to users running late, and of course a button taking them to where they could make progress, but it still didn’t address this initial use case.

Then there’s another system that predicted the performance of job ads, but had to accumulate information for seven days before it could provide a reliable forecast. Here too, the designer developed three graphs showing different aspects of the forecast side by side—but what would be there over those first seven days? How will the page be displayed to users who are still learning to use the platform: what will they see, and what will be written?

These examples show why UX designers need to remember to plan the initial empty states, and to make sure these states reach microcopy writers who will write the strong, efficient texts that will walk users through the system and help them understand how it works and how it’ll improve their life or their work.

Ongoing use
In any dynamic area where empty states are possible, with or without user involvement, you should ask:

• What happens in the Favorites section before users add items?
• What does the basket look like while it’s still empty?
• What’s in the notifications area when there are no updates?
• How can we help our users find what they’re looking for when there are no search results?

Sometimes all you need is one sentence of well-written microcopy to encourage the user to save items to their Favorites or head back to the store.

A good example of this is Society6’s cart, sending users back to the shop:

Or, in the case of no search results, Gmail invites users to change their filters or head to advanced search, with a direct link.

If microcopy writers don’t get wireframes or designs for empty states, they’re likely to forget about this use case, just like the UX designer did. If this happens, your user’s going to end up with your classic, No results, no favorites, and your basket is empty, with no directions or call to action.

Tip: If you catch them in time, empty states can turn into triggers.

If you think about addressing empty states before design and development, you can turn them into mini-features that will help users—and with the right combination of UX and microcopy, even motivate them to take action. For example:

• If there are no search results for apartment ads, instead of writing “No matching ads were found for this search,” you can automatically run several tangent searches and offer ads for apartments in the same neighborhood, at the same size, or for the same price as the original search.
• If I looked for a branch of a supermarket chain in my city but there isn’t one, you can show me the nearest branch or the shipping price to the city I’m in.
• In an empty basket you can show current sales, the most popular products, or social proof, like how many customers have already bought something lovely today.

All of these demand small (and fun!) changes to the flow, so the earlier you think of these use cases the easier you’ll make it for the UX designers to add them in.

2. Error messages, even (and especially) for special situations

When do we encounter situations like the one presented above?

When no one in the product, UX, or microcopy process predicted this scenario, so it didn’t get proper copy treatment.

Error messages are often not included in wireframes, or at least not all of their use cases. Even after development, unless they’re deliberately shown, it’s likely that they’ll remain out of sight, out of mind.

Read more: How to turn an error state into a conversation starter

That is why microcopy writers need to receive—or request, if not offered—a breakdown of each screen with all of the possible states in which the system might return an error. This is the only way they can be sure to add microcopy addressing, or preventing, these instances.

UX designers and microcopy writers should make sure they address issues like:

• Which fields are mandatory
• If there are certain values ​​that the system does not accept
• If two modes can’t be selected together
• If there’s a limit to files that can be uploaded or added, or what happens if you try to click Continue when you haven’t added enough files

and so on.

This particular error showed above—Invalid JSON string—could have been prevented by telling the microcopy writers what type or size of file can be uploaded, so that thus prompt will appear before the user tries to upload something that the system won’t accept.

And, of course, formulate a more useful text…

3. Confirmation messages for deleted items

When users want to delete or modify an item, it’s best practice to verify that they understand what happens when they press delete before they take an irreversible step.

For example:

Another option is to allow users to undo their deletion, just like Gmail does:

Either way, don’t forget that you’ll have to provide a verification message after deletion.

4. Confirmation messages

You’ve finished up the purchase process, designed a pop-up for newsletter signup, prepared a Submit or Save button of some kind, but what happens next?

Like error messages, confirmation messages aren’t always included in the flow, and are then predictably left out.

This is particularly common in complex systems after important or relatively rare operations, where users will be happy to receive feedback after their action has taken place as intended. All you need is a brief toast message that comes and goes on its own, or even a check mark, so long as there’s something giving the user some reassurance and encouragement.

Something like this (from WIX and HappyCow):

Of course, more significant processes like buying, joining, or signing up need to be addressed with messages that are more explanatory, or exciting, than those above.

The UX designers will determine which actions require explicit certainty or confirmation, and it’s their responsibility to pass this information to the microcopy writers.

The writers, on the other hand, should remember these messages, and if this isn’t in the design, it’s perfectly fine to ask for it to be included.

5. Dropdowns, and anything else that can be opened and closed

What’s hidden in this drop-down list is one of the most important things that microcopy writers have to work on, and it’s often left unseen.

Users will need to easily understand the various options in the dropdown to quickly choose from them, so items in the list need to be very clear, concise, and familiar. Microcopy writers are exactly the right people in the process to make sure this happens, so they absolutely need to be given (or request!) open modes for all drop-down menus.

Same goes for expand/collapse sections.

The general rule is anything that has different closed and open states should reach the microcopy writers in both states.

6. Standby and loading times

In a perfect world, systems would load so fast that users would never need to see a loading message. However, our ambitions and our reality don’t match up here. So, what do users see while a system is loading? These screens are often forgotten and show a boring and uninformative Please wait.

And yet! This is a great place to put an animation and let the microcopy writer take a nap, but if you want to make your users feel happy and connected you’ll keep them in their seats and give them the chance to shine.

This is particularly true if you expect an exceptionally long loading time, like when the site or app is processing a big load of data and the users know they’ll be waiting. In this case especially, it’s important to give the user copy that will make the time fly by, or even help them out with using the app.

Think about offering pieces of trivia, interesting statistics about your platform, jokes—whatever fits your tone of voice.

Google Adwords, for example, uses their waiting time to give tips for using the platform:

7. SMS, emails, and other cross-platform messages

If the verification code is sent by SMS, if the password recovery link is sent by email, if urgent system alerts are sent to the mobile, if the arrival instructions for the event are sent by email immediately after registration, if the order details are sent to the email… someone needs to write all of these messages.

In writing SMS messages, it’s important to make sure that the main piece of information is at the beginning—that the users will quickly understand who it’s from, and that there’s a link to continue.

For emails, don’t forget a subject line!

If you don’t think emails are proper microcopy work, you’re right: email copy is its own field. However, microcopy does include confirmation messages and the accompanying SMS messages, so writing the complementary emails lets you make sure all of the messages that users are receiving within a short window work well together.

In the event that you’ll be writing a few of these messages, keep a list handy so you won’t forget anything.

Conclusion: Keep an eye out for what you can’t see

When UX designers hand over wireframes for the microcopy writer to start working, everyone involved in the process needs to think about all of the possible situations users might encounter and what might not be addressed. This kind of thinking is what will keep your users from running into that JSON message, ruining their experience in the product you’ve spent so much time working on.

Popular posts like this

• Microcopy best practices I learned from Lemonade
• 7 guidelines for writing accessible microcopy
• Why we can’t let UX writing steal microcopy’s thunder