Write Effective Copy
Last updated
Last updated
When writing copy, it is important to determine the tone of voice of your app (how professional, or how friendly should it be?) and keep it consistent throughout. All your copy should be as succinct and clear as possible while giving the user all the information and context needed to understand what to do next.
Apps can contain two types of alerts. These include either confirmations, which are usually dialogs with "confirm" and "cancel" type buttons requesting that the user confirm proceeding with an action or acknowledgments which do not always require an action and can take the form of a notification bar informing the user that something has happened or will happen in the background.
Use these dialogs sparingly as they tend to interrupt the user. If they are used too often, users tend to stop reading dialogs and clicking any button to get rid of them. When writing the copy, summarize the action that needs to be confirmed in one sentence and accompany it with two buttons allowing the user to take action. Avoid using vague description button labels like "Are you sure?", "Yes" and "No". Instead, use clear language so the user has no doubt about what will happen next, for example: "Delete this user?" with "Cancel" and "Delete".
These notification bars should be used to remove uncertainty and notify the user when an action has been completed. These should be as short as possible, since the notification bar disappears after a few seconds, but they should still be informative and useful. They can contain text like "Report sent". They can also contain an action, provided that it is not a critical action to take. The user should be able to ignore the notification and move on if need be.
When in doubt, use confirmation dialogs when it is absolutely necessary to stop the user and ask them to confirm or cancel an action. Furthermore, if you have a dialog popping up with only one button on it, limiting the user to one action only, consider that a notification bar may do the same job in a less jarring way.
Error messages should be informative, helpful and friendly. Always word error messages in a way that does not make the user feel blamed or stupid. Furthermore, error messages should be as descriptive as possible so that the user knows how to fix the problem - avoid vague messages like "Something went wrong" or, worse, "Error".
When specifying your own empty-message on your components, keep in mind that empty states should have a positive tone and add clarity. It's not your user's fault that there are no items yet - so avoid saying things like "No items found", as this makes it sound like there is an error or like your user has done something wrong. Where relevant, empty state messages could include an explanation on how the list or table could be filled so that the user has a better idea of the purpose of the empty component, as well as what to do next.
Read more about confirmation and acknowledgments .
It is also helpful to include an instruction or explanation so that the user knows what to do next. has more helpful tips on writing good error messages.
More guidelines on writing copy can be found in .
