A warning message, different from error messages, appears before someone takes an action to indicate a significant change or potential loss of data. It draws their attention to a potential problem that may or may not require an action on the user’s part.
When crafting warning messages, remember that most people scan text instead of reading everything. Make every word count and avoid irrelevant details.
Titles are optional depending on the component you choose.
Include an informative, scannable title. Try and imagine people trying to understand what’s happening by reading the title on its own.
Avoid explaining what to do.
Limit titles to three to four words where possible, excluding “an”, “a”, or “the”. The character count will depend on the component you choose.
Write in sentence case with appropriate punctuation.
Do
Do: Warning bill increase
Don't
Dont: Warning bill increase
By giving people this warning before they add extra members to their team you’re giving them a chance to reconsider their options after having all the information. Avoid using a wink in instances where there could be a problem for people.
Include: the reason for the warning and the potential problem, how someone should act, and what happens if they don’t act.
If you don’t know the reason for a warning, don’t make one up – just say that something’s gone wrong and offer a solution for what they can do.
Avoid repeating content from the title.
Keep messages to 1 to 2 sentences.
Avoid people having to look in another location for more information. If this can't be avoided, use a “Learn more” link.
Do
Do: Warning trouble connecting
Don't
Dont: Warning trouble connecting
Use ‘we’re' instead of ‘you’re' to avoid blaming users for issues they may be facing with the products.
When a warning message invokes a choice, use imperative verbs such as “Save”, “Remove” or “Create”, in the CTA to describe what action people will be making instead of vague terms such as “Done”.
An option to dismiss or cancel lets people feel reassured that they can opt-out.
Limit your CTA to 1 or 2 words.
You want to leave people feeling informed, supported and reassured. Convey the correct level of urgency and make sure they understand how to respond. Follow some of the following Atlassian Voice and Tone principles to build your message:
Inform, but don't alarm. If the warning comes before an action, clearly communicate what will happen if the action is taken.
Give clear, concise advice on which path to take and describe and provide alternatives if possible.
Use language that sounds and feels human, is natural and accessible. Explains the situation clearly and without assuming they have any advanced knowledge.
Consider the context in which the message appears. The type of warning message required will change depending on the risk, consequences, and immediacy of the problem.
Warning messages make people aware of a condition or potential problem, even if they don't have to take immediate action.
Do
Payment details needed
Don't
Payment details needed
This message describes the condition or problem, the implications and their importance, and offers a button to dismiss the message.
This is when someone needs to act immediately to prevent an issue.
Here the message describes what people need to do, explains the condition and why it’s important, and offers a button for each of the options.
It's important to give people a timeline in which to make a certain change. You don’t want to create panic and rush people into making changes.
This message should ask people whether they want to proceed, explain any reasons why they may not wish to proceed, and offer commit buttons for proceeding or canceling an action. You should also inform them whether any actions they take can be easily undone.
Do
Confirm a risky action
Don't
Risky action
Use warning messages in the following components:
Use alternative text for illustrations and symbols in your messages
Avoid jargon and use simple language
Make links as descriptive as possible
Make text easily scannable to highlight key information.
Was this page helpful?
We use this feedback to improve our documentation.