Appszoom for Developers

How to Write Great App Microcopy

Posted by on 07/03/2017

If copy and design met on Tinder, they’d both swipe right and hit it off.

That’s because good copy and good design go hand in hand. Good copy reinforces smart design and improves the user experience (UX). Good design reduces the need for lots of text—reducing friction and also enhancing the UX. You shouldn’t have to write two lines of text to explain what the user needs to do.

But what the blazes is microcopy?  

Microcopy is the text that silently guides you through an online experience. It’s the guy or girl who glides around the party, quietly topping up drinks (and maybe puts you in a cab later when you’ve had one too many). It can take the form of an error message when you complete a field incorrectly, a button that submits a request, or a confirmation message when something’s happened. It’s the kind of thing you never notice, but really miss when it’s not around.

If you’re a regular Facebook user, you probably stare at the same piece of microcopy at least once a day:


“What’s on your mind?” A gentle prod to share something with the world. Without this, new Facebook users wouldn’t really know what to put here. With it, they’re encouraged to think about their feelings and turn them into words.

Let’s dive into in-app examples of happy marriages between copy and design—and examples in which copy and design have already signed the divorce papers.

Also interested in how to write developer description copy for your app? Read all about it here.

Bad microcopy: an unfriendly voice

Over the years, the internet has developed its own vocabulary when it comes to functions, commands, and messages. We tend to become desensitized to this language, and the problem arrives when we build sites and apps, recycling the same words thinking they’re the best way to communicate.

Take this message from ScreenMeet, an app that lets you share your screen with helpdesk agents:


Say it out loud. Now ask yourself: “Would I say this in a real conversation?” Say it out loud again. If the answer’s no, change the copy.

Some simple changes here would:

  1. Make the voice sound lot more friendly, allowing the person using the app to see the developer behind it. This builds trust between the app user and the app creator.
  1. Drastically reduce the on-screen text, creating more room for visuals and making for a more aesthetically pleasing app experience.

John from ScreenMeet would like to see your screen. Is that OK?

Nope / Sure

Now take a look at this error screen that pops up when you enter a code that doesn’t match the one the support agent gave you:


No support agent would talk to you like this in real life. Unless, of course, the company you were calling had replaced their entire support team with a bunch of robots overnight.

Keep it friendly, conversational, and simple:

Oops! Looks like your code is wrong.

Try Again / Get Help

Note how sometimes “less is more” doesn’t always apply. Think carefully about how natural the microcopy in your app sounds. If you wouldn’t say it to a human, don’t put it in your app.

Good microcopy: a friendly voice

In contrast to the examples above, error messages don’t have to sound like the Daleks from Dr.Who. Here’s an example from MailChimp, king of the email marketing jungle and amusing microcopy:


Friendly microcopy is good. But words that raise a smile? Even better. These are the little touches that will endear people to your product and get them raving about you via word of mouth. And that’s the holy grail of app marketing, isn’t it?

Here’s another example of friendly microcopy from search engine DuckDuckGo:


Short and sweet, and it addresses the user directly. After all, they are the most important part of this interaction—without them, all you have are some pixels on a screen that’ll never get seen. And that’s not why you spent five months of your life developing a product you believe in. So start speaking directly to the people you made it for.

Bad microcopy: confusing navigation

As much as I love Barcelona’s bike hire system (I use it at least once a day), some of the UX in the app feels like riding a rusty tricycle with no brakes over an oil spill. 

Here’s the main map screen for the app. The user can work out that there are locations with faded-out pins which probably mean no bikes, and fuller puns with bikes available. But take a look at the second button from the right in the top navigation bar:


A bicycle icon. What do you think happens when you tap it? Will it show the locations for more bikes? Does it mean that what we’re looking at now aren’t actually the locations of bikes?


When you tap it, the pins in the map change, the icon changes to a parking symbol, and a message appears in the center of the screen that says: “See available spaces”.

What you’re actually seeing here is now the amount of space each station has for leaving your bike. But the display is confusing for a number of reasons:

  1. The icon in the top corner is a button that switches the view from bikes to space and vice versa. But the icon represents the current view, not what will happen when you tap it.
  1. The message does the same thing: it aims to reinforce what you’re seeing now. However, it’s phrased in such a way makes it sound like a call-to-action button. See available spaces. I expect to be able to tap here to carry out an action.

Is the best solution a copy or design change? Probably a couple of tweaks to both. The microcopy would make it much clearer if it was changed to something like:

You’re now viewing available spaces

You’re now viewing available bikes

Equally, if the button symbols were switched, the user would have a better idea of what will happen when they tap the button. Your buttons need to be clear on this, unless of course you’re trying to trick the user. In which case go ahead and be as counter-intuitive as you like.

Good microcopy: intuitive navigation

Workplace messaging service Slack is constantly held up as an example of good software design. It’s so “sticky”, in fact, that many people find it hard to not check it outside of work.

Here’s the screen you see when you tap to sign in:


What’s good about the microcopy here is that it provides you with a context that aids understanding. Even if you don’t have your team URL, the microcopy implies that you can just type the name of your company or team. Indeed, when you start typing in the space, it only overwrites the “your-team” part and does nothing to the surrounding URL.

The navigation at the bottom provides two simple paths that tell you what’s going to happen when you tap there.

Good microcopy is empathetic

When thinking about the design of your app, never make assumptions. Empty your mind of the language you’ve built up during your time in app development. Most people using your app will be humans trying to make progress in their lives somehow. Your app is the promised solution. So design it for someone who may have never even used an app before, and guide them—using microcopy—as you would guide a human.

Empathy is key. Think about the struggles of your users and potential barriers to a frictionless experience with your app. Don’t just think, but test.

UsabilityHub is a great way of testing those interactions with real users. On a budget? Get friends and colleagues to navigate your app, sharing their thoughts out loud as they do. Ask for permission to record them. Listen to it back more than once. Listen carefully to moments in which they’re unsure, ask questions, or explicitly say that they’re confused.

Those moments are the micro-interactions between the app and the user that you should focus on improving. Make your microcopy empathetic—your users will thank you for it.

  Steve Howe is a freelance writer, translator, and teacher living in Barcelona.

Read more about him here.

Topics: App promotion