Most of what you see on a screen are words. Words make up the content, the navigation, it’s on the buttons, in the headings, it’s everywhere.
Everyone knows what the product is supposed to say. Yet, at the last minute, someone on the team is tasked with filling in the final wording. If you have ended up being that person, this article is for you.
If handed a single screen or isolated component in an application, and you’ve been asked to work on the wording you should work on answering 3 simple questions:
- What can I do here?
- Is the next step obvious?
- Do I know what will happen when I take the next step?
If you’ve done your job right then you should be able to look at the screen from 20 steps away and answer all three questions.
Without too much thinking you should be able to tell:
- It’s an invoice
- The amount to pay is $245.81
- Clicking the big green button at the bottom lets you pay the invoice
I found this example in course a course on UX writing fundamentals by the UX writers collective. It’s a good introduction to the topic and I’ve made sure the link is in the footer.
Their example of what not to do comes from UPS. What can you tell about the following screen from 20 steps away?
- What can you do on this screen?
- Is the next step obvious?
- Do you know what will happen when you take the next step?
The first UPS screenshot is from 2018. If we look at a more recent version of the same screen in 2021 there are a few helpful changes.
The two main changes:
- There are less links on the page, which makes figuring out the next step easier.
- The ‘verify email address’ is now more obvious because it is green.
If we want to improve this further there are patterns we can rely on to answer each of our the questions about what we can do, the next step and setting expectations.
The purpose of a heading is to provide immediate clarity of context and action to be taken.
The title needs to provide context and reassure people that they are in the right place because they are often the first and only text a person reads in an experience.
Avoid using vague heading like “Are you sure?” and ask the question you actually want them to answer. If you want a user to confirm sending a payment try:
- Send this payment?
- Send payment now?
- Ready to send?
The purpose of a description is to help people move forward in the experience and know what to expect.
In English, people using an interface will rapidly scan lines up to about 40 characters wide, which is enough space for about three to six words.
Similarly, people’s eyes will linger on a few of the words when a paragraph of text has three lines or fewer.
There are two types of buttons: Sales buttons and functional buttons.
A Sales button needs to sell you on the value of proceeding, not the act of proceeding. There is plenty of content on sales button copy on the internet so I won’t be covering them here.
On the other hand, a functional button doesn’t need to be interesting. It just needs to be clear and reassuring. A functional button’s job is to help you get to where you want to go.
A good rule of thumb when writing button text (this includes links and clickable images or icons) is that someone should never be surprised by what happens when they click on it.
Some other best practices include:
- Be specific. “Save” is not the same as “submit.”
- Front-load meaning. Say “Continue,” not “Click to continue.”
- As few words as possible. Aim for 3 words or less in a button: When you must use more, remember to consider localisation and what the button will look like on a mobile screen.
- When there is only one thing you can do on a page, button text is most effective if it mirrors the wording in the title. For example, if you are on a payment page the button should say “Pay now” not “Confirm” or “Submit.”
- When designing a destructive action the primary button should not say “Cancel”. Instead, try “Cancel my subscription” to be more specific and explicit. In these scenarios, the best choices for the secondary button are “Never mind” or “Go back”.
4. Click Triggers
Sometimes it’s helpful to write something next to the button that can push that decision at the last minute. The tiny bits of text that you’ll see close to user controls like buttons, selections, or text entry fields are called microcopy or click triggers.
Great click triggers do a few things well:
- They provide clarity, direction and instruction.
- They confirm expectations and provides reassurance around decisions.
- They can answers questions that come up in someone’s mind on the spot, like “Why do you need this personal information?”
Click triggers are valuable because they are contextual. They address specific questions and speaks to concerns in the context they appear.
These 4 elements make up a common pattern for the majority of situations that need to be worded in an interface. I’m going to call this pattern the dialogue pattern. It’s the base pattern you see will come across on most pages, alerts, modals and informational components.
Taking these dialogue pattern into account, we can probably make a few minor changes to make the UPS experience:
First, a heading to give the whole experience context. Then rewording the primary action, making it larger and making all the secondary actions more subtle by changing their colour.
Now, this screen becomes much clearer at a distance. Hopefully, you have a better sense of what you can do on the screen, what the next step is and what will happen if you take the next step.
We can probably improve things further by matching the wording in the title and the primary button. We could also make the primary button look more like a button and distinguish it from other links on the page. The point is that these changes took less than two minutes to make in the browser, they are small tweaks to the formatting and wording and have a significant impact on the overall end-user experience.
Working a single screen in isolation is a terrible way to handle the words in your copy. Without aligning the wording to the larger context of the experience usually leads to a choppy, disconnected product experience. Still, this scenario comes up more often than not on small teams and I wanted to offer 3 short, easy question to fall back on when you have to work on the words in a design:
- What can you do on this screen?
- Is the next step obvious?
- Do you know what will happen when you take the next step?
Thinking of your product as a conversation
Patterns and frameworks for fixing words at the last minute are great, but you want to start thinking about the words much earlier in the design process. Ideally the words are part of the conversation where you’re structure the steps in a digital experience.
The best way I’ve learned to think about the steps in a product experience comes from a book by Torrey Podmajersky called Strategic writing for UX. She recommends pretending to be your product and having a conversation with someone to help them solve the problem you’re designed to solve.
For example, let’s pretend I’m working on a platform that helps small businesses get design work reviewed by professional designers. I’m going to role-play being the product and I’ve asked a friend to pretend they’re working on a redesign of their newsletter for their florist business.
My job is to help them get to where they want to go. I’m playing the role of a thoughtful host. I’m polite and I’m looking to anticipate needs as I improvise my way through the interaction. The other person’s job is to be clear about what they want and to keep pushing till they get it.
Hey there, how can I help?
Hi, I want to get some feedback on some designs I’ve been working on.
Yep, do you have the designs with you, or would you like to send them to me later?
I don’t have them on me at the moment.
Ok. Can you tell me a bit more about what kind of feedback you are looking for, or would you like me to give you some examples of how we can help?
I’ve just finished the design for a newsletter revamp. I don’t have any specific questions. I was hoping someone who knows what they’re doing could go through and tell me what I’ve missed or if there is anything I need to pay attention to.
Absolutely. Once I have a better sense of the kind of business this is for, I can match you up to a designer who has experience in that industry. They will review your newsletter. You will get two types of feedback. The first will be localised comments to specific design areas. They can point out any quick fixes that could help make things better. Then you will also get overall feedback on the project and what they think of it as a whole. Does that sound like it’s what you are looking for?
Yes. That sounds great. I do have some questions though. For instance, I’m not sure about the logo’s placement. I’ve also gone back and forth on the reds we’re using in the header a few times.
Not a problem at all. We can add these questions to specific areas in the design. When your designer does their spot review, they will start by responding to your comments first.
Oh lovely. Great, so how do we get started?
All I need to know before we can get started is what industry your business belongs to and what it does. Then I can shortlist the best people for you and send you three options for designers you could work with. Once you pick a designer, you will need to send us your designs and then it will take 48 hours for us to get back to you with the feedback.
What if I have questions about their feedback?
Great question. We let designers and clients handle all communication in a chat system on every project. So you can respond to their feedback with as any questions or clarifications you need. The chat system stays open for one week after the review is complete and our designers usually take a day to respond to each request.
That sounds great. How much does it all cost?
If you’re looking for a one-off review, then our prices vary from designer to designer. Most designers cost between $200 and $500 for a review. If you’d like to maintain an ongoing relationship with your designer, we also offer monthly subscriptions that start at $1000 a month. If you have a specific budget in mind, I can also factor that in when recommending the best designers for your project.
Ok. I think I’ll start with a one-off project. I want to stick to the $250 range, and then we can take it from there.
Excellent I will send you a link where you can pay for the review and then you will receive a shortlist of designers to pick from in the next 24 hours.
Before you go, I need to know a little bit about your business to start searching for the right designers. Can you tell me what industry you are in and what kind of service you offer?
Sure. We sell flowers online. Birthdays, anniversaries, that kind of thing. We’ve just added a whole new range of tropical flowers to our offering, and this newsletter introduces the new flowers to our members.
Wonderful. Thank you very much. Is there anything else you’d like me to go over?
No. I think that covers it. Thank you very much.
I’m going to stop there. I made my point. If you do this exercise for your product, continue the conversation after the payment gets made. The point is to map the conversation all the way till you have solved the problem they came to solve.
Ideally, you want to do this in person. If you can’t, then do it over text with a friend. Also, this isn’t something you do once. You will need to role-play the conversation several times. Five conversations is typically enough (you’re unlikely to hear anything new after ten).
If your first conversation turns out to be a car crash, that’s fine. An awkward conversation reveals problems that you need to consider in your design. Address the underlying confusion and then try again with someone else. At the very least, you should never have the same car crash twice.
Once you’ve run through the conversation several times, patterns will begin to emerge. A common language that people use to refer to things. Maybe there’s a common sequence when people ask for certain things.
If we’re sticking to the example above, now we know a few important details:
- People need a basic outline of the process and how long it will take upfront.
- We should cover whether or not you can attach specific questions to designs.
- Pricing also needs to be addressed upfront.
- Another concern is around how much communication people can have with a designer after the service is delivered.
- We need some basic information about their business to match them with the right designer.
- We also need the actual designs to get started.
If we run the conversation a few times, the ideal sequence of questions becomes clearer. What’s also interesting is what we did not cover:
- Where our designers come from.
- How long the report would be.
- What the subscription payment options were.
- Who is behind the project?
- Whether they can sign up to our email newsletter.
- If they would like to leave a review of the experience.
Now you have a starting point for designing your product experience. You know what key terminology to use, the ideal sequence of beats in the conversation, and what not to include in the experience. This is a first draft of how your ideal experience should unfold. I say ideal because it closely maps how a real human conversation about the same topic would unfold.
If your product is tiny and only has one use case, you can get away with one conversation for the whole product. More often, you will have multiple use cases for a product, and you will need to repeat the whole process for each use case. Either way, start with your product’s primary use case.
Once you’ve mapped the beats to your ideal product conversation, you can overlay this on your current product experience and see where things deviate, what’s missing or what needs to be moved around.
Aim for a straight line between what your customers came to do and helping them actually do it. Unfortunately, products don’t only exist to serve users. This means business requirements and practical constraints that also need to be factored into the conversation.
This process of thinking of your product in terms of a conversation won’t give you the layout or the final wording for your interface components. It’s a helpful process that fits into the bit of the design process before you sketch out your first wireframes—a strategic way to think about the important steps in the big picture.
A pattern for the words in your product
Once you have the big picture in place then you can rely on best practices around a common pattern that unfolds when people do things with digital products to eke out the final wording for each step.
The motivation to do something usually originates outside of the actual application. When they come to the product for the first time they usually have a vague sense of something they want to do, and their initial experience is typically with the blank state version of your product.
The most important thing to keep in mind about a blank state is that you never want it to feel empty. The goal is to talk about what could go there and how to make that happen. You want a clear, easy path to their first meaningful win.
When designing a blank state:
- Reaffirm why people came to the product or feature and then convey the value they will get out of using it. Echo the promise you made on your landing page, or explain how the feature connects to that promise.
- Then tell them why and exactly how to do get the value they came for.
Empty-state text can be as simple as a single line of text. In most cases, using the format “To do X, do Y” is enough. They can also be as complex as a title, description, and button.
Here’s Dropbox Paper…
It’s a little wordy but I love their empty state text. It reaffirms you’re in the right place, tells you what you will get out of it and tells you what to do next.
Another consideration when handling people’s motivation to use a product is navigation.
Build your navigation around objects, not tasks. I learned this gem from the UI Audit by Jane Portman.
Task-based navigation gets messy fast. Think nouns, not verbs. There will be a finite number of objects you can base your navigation system on. The tasks you can perform on these objects is endless. Arranging them into a navigation system is impossible.
If people can navigate to where they need to go then the next step will lead to some form of interaction. If it’s a passive, informative experience then you can rely on titles, description, buttons and click triggers. I covered best practices for these in my quick fix post (which I link to in the footer). If there’s more interaction than a button or two then you are going to end up in some variation on a form-like interface.
Rules for forms
This form is where the term microcopy was first invented.
A product designer called Joshua Porter added this sentence to his form and the cart abandonment problem he was dealing with went away. Porter wrote a post about it and that’s where he shared the term microcopy for the first time.
When designing forms here are some best practices to keep in mind.
- No more fields than necessary. Use autofocus to bring people to the first input when a page loads.
- One idea per section. Group related information. A neat trick I learned on the UXWC fundamentals course (linked to in the footer) is that you can also use section titles to shorten the length of field labels. For example, you could name the grouped section below ‘Business Info’.
The word “Business” repeats in each field.
Removing the word “business” lets us be more specific.
- Break up large form into stages. If you must do this then show a Progress bar to tell the people exactly how much of the form is complete. If it’s a massive form then explain how long it will take, to complete. Cover what documents they need and whether they can save progress and continue later.
- Pre-fill when possible and give people the opportunity to correct the pre-filled text.
- When you can’t pre-fill form inputs, use labels outside of the text field as well as placeholders within. If you have to pick one, use labels so that they know what the input os for after they begin entering information. Placeholders are better used as an example of what a valid entry looks like.
- User microcopy to address confusion in context. Clarify technical terms or jargon. Explain why you need sensitive data. Set expectation around consequential decisions. As a general rule of no more than 150 characters is good practice. It’s better to put this kind of assistive text, above the field rather than below it.
- A screen reader will only get to the password requirements after they’ve filled out the field.
- If you need to communicate a longer message, use a tooltip. Resist the urge to sprinkle loads of tooltips everywhere. Tooltip copy is typically written form the user’s point of view (I, me, my), like “How do I find my tax ID?”.
- Avoid drop-downs at all costs. When dealing with toggles, describing the state of the system that the switch is currently in. Keep things unambiguous by always using positive language. Remeber that a screen reader will read out a checkbox as “checked” or “unchecked”. Keep things simple, start with a verb and end with a noun. Also, stay consistent, don’t switch between checkboxes, toggle and radio buttons.
- ❌ Include non-discounted items
- ✅ Show discounted items
A good rule of thumb for writing form buttons is that someone should never be surprised by what happens when they click on it. As few words as possible and be specific. “Save” is not the same as “submit.”. Front-load meaning, so “Continue,” not “Click to continue.”. When designing a destructive action the primary button should not say “Cancel”. Instead, try “Cancel my subscription” to be more specific and explicit. In these scenarios, the best choices for the secondary button are “Never mind” or “Go back”.
When someone completes a form there’s usually a pause while the system deals with the information. This pause can be stressful depending on how important the task is.
Acknowledge the pause. A lot of times forms seem unresponsive but they work fine. Changing the submit button text to a verb when you click on it solves this. Generic verbs like ‘submitting’ or ‘sending’ work fine, specific words are always better. If the form submission takes you to a new screen then a spinner is enough to acknowledge the transition. You want people to know they have done what they needed to do, and that if they wait, the process will complete.
When the loading process takes a while you can use the time to put a smile on people faces.Telling people what is actually happening behind the scenes is good for creating a sense of anticipation while they wait.You can also use loading times to help people get into the mood of the product. My favourite example comes from a discontinued application called the email game. The started with “loading…” and progressed to to “Still loading…”, then broke out into “Optimizing entertainment algorithms…”, “Coloring whitespace…”, “Deindividualizing unit tests…”, “Entering the matrix…”, “Installing anti-Skynet firewalls…”, “Initiating launch sequence…”, “Opening a mysterious package…”, etc. Every time it cycled through a different combination of entertaining loading messages.Upwork rotates between different “Did You Know?” facts about its service. You can also use more relevant information to the experience your product fosters. For example, a travel app could cycle through practical information about the local currency, customs and weather.
With long delays, or unpredictable ones (like when you’re waiting for someone to join a call), mini-games and quizzes can offer a more engaging interactive experience. The cost of developing this capability seldom makes sense though. Better to let your users know that they’ll have to wait a while, tell them they can close the window and you’ll let them know when they can come back.
Too often products don’t think of confirmation messages as part of their experience. Someone has successfully accomplished what they came to do. This is a momentous occasion and, more often than not, worth celebrating. Sometimes the change from the transitional text can be its own confirmation. But when the effect is more subtle, it’s a good idea to err on the side of providing a confirmation message. You don’t have to throw up confetti every time someone completes a task, but it’s crucial you acknowledge their success so that people know the thing actually happened.
The simplest acknowledgement is to use the past tense of the verb that described the transition. Submitting/submitted, sending/ sent, removing/removed, deleting/deleted, and posting/posted. This type of functional confirmation is great for actions that people do often. “Toast messages” that pop up in a corner of the screen and then disappear without being a nuisance are also great.
A more celebratory confirmation message can be for more significant milestones. Moments like when you create your first podcast or send your first message, are important because they mean people have figured out how to use your product. When celebrating, tell people why what they did was meaningful. Connect the action back to the core promise of the product in your confirmation message.
- Confirm that the thing happened without sounding like a robotic. “Your message was received” is mechanical. “Your feedback improves the quality of ads on Instagram” makes it feel like you actually did something and made a difference.
- Remind people how the action benefits them personally. “Thank you for helping us keep your account secure.” or “You won’t receive any mail from us ever again.”
- Then encourage people to take the next step. An important aspect of confirmation messages is helping people take the next step. A confirmation message is not an end but rather a slingshot to the next meaningful step.
If you don’t have the next milestone lined up then use the momentum to time less desirable asks. This is when it makes sense ask users to approve push notifications, ask for a review, share stuff on social media, sign up to your newsletter, and so on.
Start with people’s motivation, this moves to a dialogue, which leads to a transition and ends in a confirmation. This concluded the beginning, middle and end for most digital tasks. Yet, at any point, the experience can breakdown.
Error messages are the most important place to empathise with the person trying to use the product. The words in an error message are the difference between someone who abandons a task and someone who carries on despite the error because they understood what has gone wrong and how to fix it.
The best way to deal with an error that comes up a lot is to prevent it. When errors start to show up repeatedly you need to look at the cause and address the problem before it happens. Passwords are an obvious example here. Just tell people what their password should contain upfront. Instead of “Incorrect username”, apologize and offer to help find the solution. That worst kind of error message is “You can’t do this, but we’re not going to tell you why.”
Once you’ve done everything you can to prevent an error the next step is to construct the error messages. The best way to I’ve found to write an error message is to think of my parents. They are not the most tech-savvy. Nor should they be. A good error message will calm my mother down and convince her it’s not her fault. The real trick is to communicate what happened well enough that she can mansplain the whole situation to my dad and then gloat about how easy it was to fix.
- Can you prevent the error?
- Does it say what went wrong in a humane way? Writing “an error occurred” is not helpful, please be specific. Conversely, don’t use jargon.
- Do you provide the easiest possible solution to fix the problem?
- Do you take responsibility for the issue? It’s never the user’s fault. Apologize, offer a solution, move on.
- If the error is low impact, can you have a little fun to lighten the mood? Make sure you consider the seriousness of the problem and how frustrated the user is likely to be.
These best practices apply to inline errors, error modals, error alerts, empty search results, 404 pages, it doesn’t matter. You can never leave people lost. That’s the core principle here.
Doing the actual writing
You are not going to hit a hole-in-one. Your first draft will be shit. Acknowledge that it’s going to take several drafts and the whole process becomes much easier.
- Speed through your first draft as fast as possible. The goal is coherence. Be as verbose as you need to be. Don’t worry about finding the right words. Say what needs to be said for the interface to make sense.
- Next is brevity. Nobody wants to read the text in a product. The goal for my second draft is to remove as many characters as possible without sacrificing coherence.
- Once I’ve shortened things down as much as possible, the next step is to breathe some life back into the words. Focusing on brevity can make things sound mechanical. For my third draft, I make sure everything still sounds like something a human would say in a conversation.
- My final draft is for clarity. This means pay attention to the details and using active, positive, definite sentences.
Active means using the active voice. “I will always remember my first visit to London.”. Passively this could be, “My first visit to London will always be remembered.” The passive voice is unnecessarily vague.
Positive means using a positive form. Instead of “He is usually never on time “ use “He is always late”. Avoid tame, colourless, hesitant, non-committal language.
Definite means using specific, concrete language. Use specific over general, definite over vague and concrete over the abstract. Instead of “a period of unfavourable weather” say, “it rained every day for a week.”
That’s the pattern you can use to tune a digital experience, along with best practices at each stage.
On a parting note, please remember to care about the people at the end of it all. Forget about your product for a moment and focus on what they are trying to do and why.
Your product is not a collection of screens and buttons and components. It is a set of things people want to do.
Focus on this and speak to people in a way that is natural, simple and conversational. No one has ever complained about something being too easy to understand.
Links mentioned and other relevant stuff…
- A lot of the example images were mostly taken from a course on UX writing fundamentals by the UX writers collective, UX Writing Essentials by UX writing hub and Microcopy & UX Writing by Kinneret Yifrah. These are all good introduction to the topic. I have nothing to do with any of these courses and am not affiliated in any way. I found these and a bunch of other resources on https://www.uxwritinglibrary.com/books.
- Navigation: Mine or yours? John Saito wrote a lovely article on calling objects mine or yours in an interface
- The UI Audit by Jane Portman covers the idea of building navigation around objects, not verbs
- Joshua Porter’s post that introduces the term microcopy for the first time.
- Some extra guideline for dealing with toggles
- My official stance on using drop-downs.
- The whole drafting process thing is adapted from Torrey Podmajersky’s ‘Strategic writing for UX’. Please check it out. Such a fantastic book. Everyone has their own way of writing. Here is an alternative called the ACB’s from Scott Kubie . If you don’t have a system, just pick one and build on it as you go.