Writing · Free lesson
Web development English: write a useful form error
You are reviewing a project-creation form. Its project-name field allows up to 30 characters, but the user entered a longer name. “Something went wrong” leaves the user unsure what to edit.
Professor Scott MendozaThe short answer
Instead of “Invalid input,” write “Project name is too long. Use 30 characters or fewer.” The field name locates the problem, and the second sentence gives a usable limit.
Give the user a next action, not just an error label.
Project name matches the field label. Too long names the specific problem. Use starts a direct instruction, and 30 characters or fewer gives the accepted limit. Avoid blaming the person or showing internal system jargon. This wording is for a fixable input problem; it should not pretend a server outage is the user’s fault.
Compare the examples
Invalid input.
Project name is too long.
Use 30 characters or fewer for the project name.
The 30-character rule is a fictional requirement for this exercise. Match real product limits when writing actual interface copy.
Build the meaning step by step
Locate the problem
Project name is too long.
Give the correction
Use 30 characters or fewer.
Try it now
Choose useful error wording
Read all answers and explanations
Why include “Project name” in the error?
To tell the user which field to edit.The message connects the correction to the right input.
The maximum is 30 characters. Which instruction preserves it?
Use 30 characters or fewer.Or fewer includes the maximum and shorter entries; words are a different unit.
Why is “Try again” alone weak for an overlong name?
It does not explain what needs to change.Repeating the same input will not address the stated length problem.
Put it into practice
Rewrite a vague error
The project-name field has a 30-character maximum. The entered name is too long. Choose a specific correction without blame.
Invalid input. You did it wrong.
See a model answer
Project name is too long. Use 30 characters or fewer.
A clear instruction can be respectful without blaming or adding unnecessary detail.
A little more clarity
Common questions
A few useful details before you move on.
Does adding please make an unclear error useful?
Not by itself. Please is not grammatically wrong, but it does not replace the field name, the reason or the correction. Follow the product’s voice while keeping those details clear.
Use 30 characters or fewer for the project name.
Should an error message guess why the user made a mistake?
No. Describe the relevant field problem and a usable correction. Avoid blame or an unsupported explanation of the user’s intentions.
Project name is too long. Use 30 characters or fewer.
Take it into your day
A useful error message names the field and a specific correction.
English for Careers · Coming Soon
Practice the English of a web-product team.
English for Full Stack Web Developers: Career Simulation is coming soon. The planned course develops communication across browser, server, testing and delivery work. Sign up on the course page for its launch news.
Get launch updatesFull Stack Web Developers · Career Simulation
Your next step · Available on Udemy
Strengthen your English foundations.
The available English Grammar and English Speaking Master Course develops broader grammar, sentence-building and communication foundations. Clear instructions and concise sentences help users understand what to do.
Explore the course English Master Course: English Grammar and English Speaking