5 exercises — Practice writing clear, calm, and actionable error messages for login failures, validation, server errors, and network timeouts.
0 / 12 completed
1 / 12
A user attempts to log in with an incorrect password. Which error message follows UX writing best practices?
Error messages should be specific, calm, and offer a clear recovery action.
Breaking down each option:
• A ("Error: Authentication failure. Status 401") — technical jargon, no recovery path
• B ("Wrong password") — the word "wrong" feels blaming; "Try again" is redundant (they will)
• C ✓ — neutral ("incorrect"), specific (password, not credentials), recovers with a direct link
• D — too verbose; "please verify" and "resubmit" are bureaucratic; no user should read this
Key vocabulary:
• Error message — UI text explaining what went wrong
• Recovery action — a link or instruction that helps the user fix the error
• User-blaming language — copy that makes the user feel at fault (e.g., "wrong", "you entered")
• Inline validation — error messages shown next to the field that caused the error
2 / 12
A form submission fails because the server is temporarily unavailable. Which error message is most appropriate?
Server errors require reassurance, a recovery action, and no technical jargon.
When the error is on your side (not the user's), the message must:
1. Own the problem ("we couldn't" not "there was an error")
2. Tell the user what happened in plain language
3. Give a recovery action ("try again in a moment")
4. Reduce anxiety ("your work is safe") if relevant
Option B ("something went wrong") is acceptable but vague — it doesn't explain what happened or reassure the user.
Option D is wordy and "we apologize for the inconvenience" reads as corporate boilerplate.
Key vocabulary:
• System-owned error — an error caused by your product, not user mistake
• Reassurance copy — text that reduces user anxiety during errors (e.g., "your data is safe")
• Plain language — no technical codes, jargon, or status numbers
• Conversational tone — first person ("We couldn't") rather than passive ("Error occurred")
3 / 12
A file upload form requires a JPG or PNG under 5 MB. A user uploads a .PDF file. Which validation message is best?
Validation messages should tell users what to do next, not just what went wrong.
Anatomy of a good field-level validation message:
1. Action verb: "Please upload…" (directive, not declarative)
2. Accepted formats stated positively: "JPG or PNG"
3. Explains the constraint briefly: "PDFs aren't supported here"
Option A ("Invalid file format") — too vague, gives no path forward
Option B — better, but "Error:" prefix and the formal "Allowed types:" format feel cold
Option D — too long; users scan, not read; loses the key info in the middle of a long sentence
Key vocabulary:
• Validation message — inline text that tells users why their input was rejected
• Constraint copy — text that communicates acceptable input before or during entry
• Directive tone — using action verbs ("Please upload") rather than passive statements
• Affordance — communicating what a UI element can accept or do
4 / 12
A required field (first name) is left blank on form submission. Which message is best?
Validation messages for blank required fields should be direct and instructional.
Option A ("Field required") — too terse; doesn't tell users what to do
Option B ("You forgot") — user-blaming language; creates a feeling of fault
Option C ("This field is required. Please enter…") — redundant; the user already knows it's required since they're seeing an error; cut the first sentence
Option D ✓ — direct action, specific, no blame, no redundancy
Principle: don't explain the constraint — tell them what to do instead.
Key vocabulary:
• Required field — a form input that must be completed for submission
• User-blaming language — copy that implies user error ("you forgot", "you missed")
• Action directive — a validation message that immediately tells the user the fix
• Brevity — eliminating redundant explanation in micro-level error copy
5 / 12
A connection times out during a network request. The user is on a mobile app. Which error message is most appropriate?
Network error messages should diagnose the likely cause simply and give a clear recovery step.
Mobile users encountering connection errors are typically on spotty Wi-Fi or cellular. The message should:
1. Describe what happened simply ("can't connect")
2. Suggest the most common fix ("check your internet connection")
3. Provide a recovery action ("try again")
4. Stay short — mobile screens have limited space
Option A — error code is meaningless to non-engineers
Option B — "device configuration panel" is too technical; most mobile users can't navigate there
Option D — "we have been notified" is only appropriate when it's a server-side issue you're actively fixing, not a client-side connectivity problem
Key vocabulary:
• Network error — failure caused by connectivity loss, not app logic
• Probable cause framing — suggesting the most likely fix when the cause is ambiguous
• Retry affordance — providing a "try again" button or instruction to encourage retry
• Context-appropriate length — keeping mobile error copy shorter than desktop copy
6 / 12
Alex, a junior developer, just submitted a pull request with a new API endpoint for user profile updates. During code review, you notice the response format doesn't consistently include error codes when a validation fails. Which of the following messages would be most effective in guiding Alex to improve this?
This scenario focuses on API response messaging. Option 2 directly addresses the issue – the lack of standardized error codes – and provides actionable guidance to Alex. Options A and D are too generic, while option C is technically correct but doesn't explain *why* Alex needs to add a status code; it just states the requirement.
7 / 12
Sarah, a senior UX writer, is drafting the description for a Slack message informing users that their automated deployment has failed. The deployment process involves several microservices. Which of these messages best balances clarity and technical detail?
This tests messaging in a less formal environment like Slack. Option 2 provides sufficient context – mentioning microservices – without overwhelming the user with technical jargon. Options A is terse and unhelpful, option B is too vague, and option C is misleading (as it claims success).
8 / 12
During code review, you're examining Ben's pull request for a new feature that calculates shipping costs. He's used the calculateShipping() function, but the error message displayed to the user when the calculation fails is simply 'Invalid Input'. Which of the following options best reflects UX writing principles for this scenario?
The current message 'Invalid Input' lacks helpful guidance for the user. UX writing emphasizes clarity and actionable feedback. A better message would explain *what* needs to be fixed – perhaps a specific format requirement or missing data – reducing frustration and guiding the user toward a solution. This avoids simply stating the problem without offering a path forward.
9 / 12
You're crafting a Slack message to notify a team of a critical database outage impacting the user authentication service. The message is being sent by an automated monitoring system. Which of these messages would be most effective in conveying urgency and directing action?
The key to effective urgent notifications is clear communication and a call to action. A simple statement of the problem isn't enough. Using an emoji (🚨) adds visual emphasis, while directly stating 'Critical: Authentication service outage detected!' immediately highlights the severity and prompts immediate investigation. Option 1 is too vague, and options 3 & 4 lack urgency.
10 / 12
A user attempts to update their profile picture through the web application. The upload fails due to a file size limit (2MB). Which error message is most appropriate and aligns with UX best practices?
The most effective error message is concise and clearly states the problem—the file is too large. It avoids technical jargon like 'maximum allowed size' which can confuse the user. Option 2 provides helpful guidance, but 'Error: File...' isn't as immediately understandable for a non-technical user. Option 3 adds unnecessary detail, while option 4 focuses on file type instead of size.
11 / 12
You're writing the description for a pull request that introduces a new API endpoint for retrieving order history. The endpoint returns JSON data with various fields, including an 'error_code' field when an error occurs. Which of these PR descriptions is best?
The best PR description provides sufficient context without overwhelming the reviewer with technical details. Option 1 is too brief and doesn't highlight the key feature. Option 3 clearly explains the endpoint's purpose *and* mentions the important `error_code` field – crucial for developers to understand how errors are handled. Option 4 lacks detail and doesn't mention error handling.
12 / 12
During a standup meeting, David announces he's working on improving the performance of the search feature. He mentions that the current implementation is slow and inefficient. Which of these phrases would be most appropriate for him to use when describing his task to the team?
David's statement needs to be specific and convey the desired outcome. Simply stating he's 'optimizing' is too vague. The best phrasing – 'I'm tackling the performance issues... aiming for a significant speed improvement' – clearly articulates the problem, the goal, and provides a measurable target. It frames the task in terms of a positive result.
This exercise, "Error Message Writing", tests your understanding of ux writing vocabulary and phrasing through 12 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 12 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this UX Writing exercise for?
It's designed for IT professionals and learners who want to sound natural discussing ux writing topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more UX Writing exercises?
Browse the full UX Writing exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.