5 exercises — Practice writing validation messages that guide users to correct input: count-based errors, inline validation, password checklists, multi-error summaries, and sensitive age-gating.
0 / 10 completed
1 / 10
A credit card number field shows this validation message when a user enters 15 digits: "Invalid input." What should replace it?
Form validation messages are most helpful when they tell users exactly what went wrong and what the correct value should be.
Analysis:
• Option A — "valid credit card number" is vague; tells them nothing specific about the error
• Option B — too long and formal; "expected format" is developer language
• Option C ✓ — tells the rule (16 digits) AND what they entered (15 digits) — maximum specificity
• Option D — correct but missing the diagnostic ("you entered 15") that helps users understand the mistake
The gold standard for count-based validation: state the required count AND the current count.
Other examples:
• "Password must be at least 8 characters. Yours is 6."
• "Title can be up to 60 characters. You've used 63."
Key vocabulary:
• Validation message — inline feedback explaining why input was rejected
• Diagnostic copy — validation text that tells users what they actually entered vs. what was expected
• Character/digit count feedback — showing current vs. required count in validation messages
• Specific constraint — naming the exact rule being violated, not a generic error
2 / 10
An email field has inline validation that fires when the user leaves the field. The user entered "john@" without a domain. Which message is best?
Email validation messages should specify what's missing and show an example of the correct format.
The user typed "john@" — the at-sign is present; the domain is missing. The validation message should be as targeted as possible:
• "Invalid email" — generic; tells them nothing
• "Please enter a valid email" — same level of vagueness
• "Email format is incorrect" — slightly more diagnostic but still no example
• "Please include a domain — for example, john@gmail.com" ✓ — names what's missing, shows a concrete example
When users see their own username (john) reflected in the example, it creates a personalized, helpful moment.
Key vocabulary:
• Inline validation — validation that fires immediately when a field loses focus (on-blur)
• On-blur validation — validation triggered when the user moves to the next field
• Example-led correction — showing a correct example rather than just stating the rule
• Targeted validation — a message that diagnoses the specific error, not a generic failure
3 / 10
A password field requires: at least 8 characters, one uppercase letter, one number, and one special character. The user submits a 6-character lowercase password. Which validation approach is best?
Complex password requirements need real-time, progressive validation — not a post-submit error dump.
Why each option works or fails:
• Option A ("does not meet requirements") — zero diagnostic value; most frustrating pattern
• Option B ✓ — real-time checklist lets users build the password interactively; each rule is a mini-goal with immediate feedback
• Option C — listing all 4 rules as errors after submission is overwhelming and inaccurate (they met some requirements already)
• Option D — only shows first failure; once fixed, a new error appears; this "whack-a-mole" pattern frustrates users
The checklist pattern also:
• Communicates requirements BEFORE the user attempts to submit
• Reduces anxiety with progressive ✓ marks as they go
• Makes the password field feel like a guide, not a gatekeeper
Key vocabulary:
• Real-time validation — validation feedback that updates as the user types
• Progressive validation — showing completion status incrementally, not all-or-nothing
• Requirement checklist — a list of password rules shown inline, checked off as they're met
• Whack-a-mole validation — anti-pattern where one error at a time is shown, creating repeated submission failures
4 / 10
A user submits a form but accidentally skips 3 required fields. Which approach to displaying the errors is best?
Multi-field validation errors require both inline messages AND an accessible summary at the top of the form.
Why this dual approach is best:
1. The summary helps users understand the scope ("3 fields") without having to scroll through the entire form
2. Anchor links in the summary take users directly to each problem field
3. Inline messages provide context when they arrive at each field
4. Both together meet WCAG accessibility guidelines (complex forms must have accessible error summaries)
Why other options fail:
• A — "fix the errors below" provides no count; requires full-form scanning
• C — modal prevents users from seeing which fields need correction
• D — whack-a-mole pattern; frustrating for complex forms
Key vocabulary:
• Error summary — a top-of-form component listing all validation errors with links to each field
• Inline error — validation message displayed adjacent to the field it refers to
• WCAG (Web Content Accessibility Guidelines) — accessibility standard that includes form error handling requirements
• Anchor link — a link that jumps to a specific location on the page (used in error summaries)
5 / 10
A date-of-birth field accepts only users 18+. A user enters a date that makes them 16. Which validation message is most appropriate?
Age-gating validation messages should state the rule AND confirm that their input was processed — not just assert a generic rule.
This is a sensitive validation scenario. The user:
• May have entered the date incorrectly
• May be genuinely under 18
A good message:
1. States the rule clearly ("18 or older")
2. Confirms the input was understood ("based on the date you entered")
3. Leaves room for the user to re-enter if they made a mistake
4. Doesn't accuse them of lying
Option B ("You must be 18 or older") states the rule but doesn't acknowledge what they entered — the user may wonder if their date wasn't processed.
Option D ("rejected", "not met") is cold and bureaucratic.
Key vocabulary:
• Age-gating — restricting access based on the user's age
• Input acknowledgment — copy that confirms the user's input was received before explaining why it failed
• Sensitive validation context — validation around personal information (age, identity) requiring careful, non-accusatory language
• Re-entry invitation — validation phrasing that implicitly invites correction without assuming bad intent
6 / 10
Alex, a junior developer, is reviewing a PR that includes an address field. The validation currently displays: 'Please enter a valid email address.' What's the most appropriate message to replace this?
The current message incorrectly suggests the field accepts email. The prompt should clearly state the expected input type – an email address. Using 'Invalid email format' is too technical for a user-facing message; it focuses on *how* to fix the error, not *what* the problem is. 'Email address is required.' is also accurate but less helpful as it doesn't guide the user.
7 / 10
Sarah, a UX designer, wants to improve the feedback for a new form field. The user enters 'test' into a phone number field. Which message is most effective at guiding them towards correct input?
The key to good validation messages is providing specific guidance. Simply stating 'Invalid phone number' doesn't tell the user *why* it's invalid or how to correct it. Providing an example format helps the user understand the expected input and reduces frustration. The other options are too generic or simply reiterate that the field is required.
8 / 10
Ben, a senior developer, is crafting a PR description for a new password strength validation rule. Which of the following descriptions best explains the validation to reviewers?
Reviewers need to understand *how* the validation works. A vague statement like 'This code enforces minimum password complexity' is insufficient. The detailed explanation clarifies the specific requirements and rules being enforced, allowing reviewers to assess the implementation thoroughly. Options 2 & 3 are too high-level.
9 / 10
A form has multiple required fields. The user leaves all of them blank. Which approach to displaying the errors would be most effective for guiding the user?
Providing clear and immediate feedback is crucial. Highlighting each empty field with a red border and a tooltip immediately draws attention to the problem. This approach is more effective than a general message because it directs the user's focus to exactly where the issue lies. Option 2 is also good but potentially overwhelming.
10 / 10
Chloe, a frontend developer, is implementing validation for a field that accepts ages. The user enters 'twenty'. Which message should she display to provide the best feedback?
The user provided text instead of a numerical value. 'Invalid age' is the most direct and informative message in this situation, clearly indicating that the input was incorrect. It avoids technical jargon and focuses on the core problem – that the entered data wasn't what was expected. Options 2 & 3 are overly verbose.
This exercise, "Form Validation Copy", tests your understanding of ux writing vocabulary and phrasing through 10 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 10 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.