# How to write messages ## 👋 Introduction Messages in the product, like error messages, success messages, are a combination of titles, body copy and buttons. When written well, they give the user feedback, clarity and reinforce brand voice. *** ## 1️⃣ Error messages An error message interrupts a user’s flow and can be frustrating. A good error message eases that frustration by explaining the problem, providing a solution, and turning the delay into a neutral, if not pleasant, experience.

> **Describe the problem—**Tell the user what went wrong and why the system responded with an error.

> **Describe the solution—**Tell the user what to do to complete the process. If there is no solution, offer an alternative action such as turning to support.

> **In standard error messages,** you can leave out either the description of the problem or the solution to the problem.

> **Make it human—**Rewrite the error message to reinforce the brand’s personality and to speak like a human. *** ## 2️⃣ Success messages When users complete a task successfully, they expect a success message to confirm that the action was completed and to tell them what the next step is. There are four components of a good success message.

> **Confirmation—**Give a clear indication that what the user wanted to do, did in fact occur.

> **Consequence—**Now that the user has completed the action, what can they expect?

> **Guide users forward—**Direct the users to a mandatory or optional next step.

> **Go beyond the template—**Do not use a template “x successfully completed” message for every time. Speak to your user with warmth. *** ## 3️⃣ Loading states Every system needs time to load, process data or run a search. While the user is waiting, changing text, animation or even a progress bar can shorten the perceived time.

> **Inform the user—**Tell the user what the system is doing for them.

> **Delight the user—**If the loading time is long, suggest an alternative way to spend time or reinforce brand voice. *** ## 4️⃣ Empty states Empty states can set the expectation and build excitement while indicating that the empty space is intentional. Empty states can be just a title, or a title and description and a button. ### Feature before first use

> **Tell the user what is supposed to be there—**If a user has never used a feature and lands on an empty page, it will turn them away,

> **Add instructions—**Tell the user how to use the feature. *** ### Feature not in use

> **Tell the user why there is nothing there—**Set expectations with the user and let them know that nothing is wrong.

> **Encourage the user to use the feature—**What can the user do next? Direct them to action. *** ### Search Sometimes, when a user searches for something, the system might not have anything to show. When this happens, use the empty state to inform and suggest.

> **Inform and suggest—**Tell the user that you didn’t find what they were looking for. Suggest other ways to find what they were looking for. For example: try rephrasing your search, search for a category, check spelling. *** ## 5️⃣ Dialog boxes Dialog boxes are useful and necessary, but that they interrupt a user’s flow. Write the copy so that the user needs to spend as little time as possible reading and understanding the copy. ### Titles

> **Be clear—**The dialog box is used for alerts or confirmations. In the title, speak about the action the user will take.

> **Be brutally concise.** *** ### Buttons

> **Be consistent with the title—**Use the same verb in the title and the button. Using two different verbs will confuse the user.

> **Be descriptive—**It’s important that the user knows exactly what will happen when they click on a button.

> **Keep two buttons—**Most dialog boxes need just two buttons. Add a third button only if there is a third action. *** ### Body

> **Not all dialog boxes need body copy.** If there is nothing to add, don’t add body copy in the dialog box.

> **Inform the user of the consequence—**If the action has a consequence the user should know about, write that in the body copy.

> **Suggest an alternative action—**If the user can pursue an alternative course of action, let them know in the body copy. *** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://university.obvious.in/product-design/microcopy/how-to-write-messages.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.