Escribe desde el estado real del sistema y una acción que pueda cumplirse. Revisa el mensaje junto al campo, los datos conservados y la respuesta después del reintento.
Identifica qué clase de problema ocurrió
Un campo vacío, un formato no admitido y una interrupción del servicio requieren respuestas distintas. Antes de redactar, pide al equipo que explique qué detectó el sistema y qué se conoce del envío. Si no puede confirmar si se guardó, el mensaje debe conservar esa incertidumbre y ofrecer una forma de comprobarlo.
En una tienda ficticia, el formulario solicita datos para preparar una muestra. “Algo salió mal” deja a la persona sin saber si debe cambiar una entrada o esperar. El primer trabajo editorial es convertir el estado técnico en una situación comprensible, sin publicar detalles internos innecesarios.
Relaciona la instrucción con el campo
Estos ejemplos originales suponen reglas ficticias que el servicio tendría que aplicar realmente. El texto debe cambiar si cambia la regla; copiarlo sin revisar el formulario puede crear otra contradicción.
| Estado | Mensaje propuesto |
|---|---|
| Falta el nombre del proyecto | Escribe el nombre del proyecto. |
| El archivo supera 5 MB | El archivo debe pesar 5 MB o menos. Elige una versión más pequeña. |
| La fecha elegida ya pasó | Elige una fecha de entrega posterior a hoy. |
GOV.UK recomienda que el mensaje utilice las palabras de la etiqueta y explique cómo corregir. Comprueba que la persona encuentra el campo nombrado y que la instrucción corresponde a una acción disponible.
Mantén una voz clara en un momento de dificultad
El humor puede ocultar la instrucción o resultar extraño cuando alguien teme perder trabajo. Prueba una frase directa antes de añadir personalidad. “Revisa el archivo” sigue siendo ambiguo: explica qué condición impide utilizarlo y qué alternativa admite el proceso.
Para un fallo del servicio, evita atribuir el problema a la persona. Una respuesta ficticia podría decir: “No pudimos confirmar el envío. Conserva esta pantalla y consulta el estado con la referencia indicada”. Esa opción solo sirve si la pantalla y el canal realmente permiten hacerlo. Una buena frase necesita una operación que la sostenga.
Revisa lo que permanece después del error
Al volver al formulario, ¿siguen las respuestas anteriores? ¿El mensaje permanece cerca del campo correcto? ¿La persona puede localizarlo sin depender únicamente del color? El patrón de GOV.UK conserva las respuestas al mostrar errores. La implementación requiere revisar también etiquetas, asociaciones y navegación.
W3C explica que, cuando se detecta un error y se conocen sugerencias para corregirlo, deben ofrecerse, salvo que comprometan la seguridad o el propósito del contenido. Esa condición importa: no reveles información de cuentas ni inventes una corrección que el sistema no puede conocer.
Prueba un recorrido completo de recuperación
Prepara entradas ficticias para los estados que el equipo reconoce: vacío, dato fuera de formato, archivo demasiado grande e interrupción simulada en un entorno de prueba. Pide a alguien que explique qué ocurrió y que intente continuar. Registra dónde duda, qué conserva y qué confirma el sistema al terminar.
Este ejercicio evalúa comprensión y comportamiento en esos casos. No acredita por sí solo accesibilidad completa ni un aumento de conversiones. El mapa de recorrido del cliente sitúa después esta recuperación dentro de la experiencia más amplia.
Mantén juntos mensaje y regla
- Estado detectado y evidencia disponible.
- Campo o parte del servicio afectada.
- Texto y traducciones aprobados.
- Acción posible y datos que permanecen.
- Resultado observado al reintentar y responsable de revisión.
Conserva la ficha cuando cambien límites o validaciones. La promesa de marca orienta qué experiencia quieres ofrecer; esta revisión comprueba una frase y su consecuencia concreta. Empieza por un error frecuente documentado antes de cambiar todos los mensajes.
Error Messages That Help People Continue a Form
A brand’s voice also appears when something fails. A useful message lets a person recognize what needs attention, what they can do and whether their request was saved.
Write from the system’s actual state and an action that can be completed. Review the message alongside its field, retained data and response after retrying.
Identify what kind of problem occurred
An empty field, an unsupported format and a service interruption require different responses. Before writing, ask the team what the system detected and what is known about submission. If it cannot confirm whether the request was saved, the message needs to preserve that uncertainty and offer a way to check.
In a fictional shop, a form collects information to prepare a sample. “Something went wrong” leaves a person unsure whether to change an entry or wait. The first editorial task is turning a technical state into an understandable situation without publishing unnecessary internal details.
Connect the instruction to its field
These original examples assume fictional rules that the service would need to enforce. Wording must change when a rule changes; copying it without reviewing the form can create another contradiction.
| State | Proposed message |
|---|---|
| Project name is missing | Enter the project name. |
| File exceeds 5 MB | The file must be 5 MB or smaller. Choose a smaller version. |
| Selected date is in the past | Choose a delivery date after today. |
GOV.UK recommends using the label’s wording and explaining how to correct the error. Check that the person can find the named field and that the instruction corresponds to an available action.
Keep the voice clear during difficulty
Humor can hide an instruction or feel strange when someone fears losing work. Try a direct sentence before adding personality. “Check the file” remains ambiguous: explain which condition prevents its use and which alternative the process accepts.
For a service failure, avoid attributing the problem to the person. A fictional response could say: “We could not confirm submission. Keep this screen and check the status using the reference shown.” This option works only if the screen and channel actually support it. Good wording needs an operation behind it.
Review what remains after an error
Back on the form, are earlier answers still there? Does the message remain near the correct field? Can someone locate it without relying only on color? GOV.UK’s pattern retains answers when showing errors. Implementation also needs a review of labels, associations and navigation.
W3C explains that when an error is detected and correction suggestions are known, they are provided unless doing so compromises security or the content’s purpose. That condition matters: do not reveal account information or invent a correction the system cannot know.
Test a complete recovery journey
Prepare fictional inputs for states the team recognizes: empty, incorrectly formatted, oversized file and an interruption simulated in a test environment. Ask someone to explain what happened and try continuing. Record where they hesitate, what is retained and what the system confirms at completion.
This exercise evaluates comprehension and behavior in those cases. It does not by itself establish complete accessibility or increased conversions. Our customer journey map then places this recovery within the broader experience.
Keep the message and rule together
- Detected state and available evidence.
- Affected field or service area.
- Approved wording and translations.
- Available action and retained data.
- Observed retry result and review owner.
Keep the record when limits or validation rules change. A brand promise guides the experience you want to offer; this review checks a sentence and its practical consequence. Begin with one documented frequent error before changing every message.
让人能够继续填写的表单错误提示
品牌语气也体现在出错的时候。有用的提示让人知道哪里需要处理、能够做什么，以及请求是否已经保存。
根据系统真实状态和能够完成的动作写提示。将文字与字段、保留的数据、重试后的结果一起检查。
先判断发生了哪类问题
字段为空、格式不受支持、服务中断，需要不同回应。动笔前，请团队说明系统检测到了什么，以及对提交结果知道多少。如果无法确认是否保存，提示就需要保留不确定性，并提供核对方式。
一家虚构商店用表单收集制作样品所需的信息。“出了点问题”让人不知道该修改输入还是等待。编辑的第一项工作是把技术状态解释成人能理解的情况，同时避免公开无关的内部细节。
让指令对应具体字段
以下原创例子采用虚构规则，服务必须实际执行这些规则。规则改变时，文案也需要改变；未经检查就复制，可能制造新的矛盾。
| 状态 | 建议文案 |
|---|---|
| 缺少项目名称 | 请输入项目名称。 |
| 文件超过 5 MB | 文件需为 5 MB 或更小，请选择较小的版本。 |
| 选择的日期已经过去 | 请选择今天之后的交付日期。 |
GOV.UK 建议采用字段标签中的词语，并说明怎样纠正。检查读者能否找到被点名的字段，以及指令是否对应实际可执行的动作。
困难时刻保持清楚的语气
幽默可能掩盖指令，也可能让担心丢失工作的人感到突兀。先尝试直接表达，再考虑个性。“检查文件”仍不明确：应说明什么条件阻止使用，以及流程接受什么替代方案。
服务失败时，不要把问题归因于用户。一条虚构回应可以是：“我们无法确认提交结果。请保留此页面，并用所示编号查询状态。”只有页面和渠道确实支持此操作时，这句话才成立。好的文字需要实际流程支持。
检查错误后保留下来的内容
回到表单后，之前的答案是否还在？提示是否靠近正确字段？用户能否不只依靠颜色找到它？GOV.UK 的模式在显示错误时保留答案。实现还需检查标签、关联和导航。
W3C 说明，检测到错误且知道纠正建议时，应提供建议，除非会危及安全或内容目的。这个条件很关键：不要透露账户信息，也不要编造系统无法知道的纠正方法。
完整测试一次恢复过程
针对团队确认的状态准备虚构输入：空值、格式错误、超大文件，以及在测试环境模拟的中断。请一个人解释发生了什么，并尝试继续。记录哪里犹豫、哪些内容保留，以及结束时系统确认了什么。
练习评估这些情况中的理解和行为，本身不能证明全面无障碍，也不能证明转化增加。本站客户旅程图可以将这次恢复放入更大的体验中。
把提示与规则保存在一起
- 检测到的状态及现有证据。
- 受影响的字段或服务部分。
- 批准的文字及翻译。
- 可执行动作与保留的数据。
- 重试观察结果及审核负责人。
限制或校验规则改变时，保留并更新记录。品牌承诺指引希望提供的体验；本审核检查一句话及其实际后果。先处理一个有记录的常见错误，再考虑修改所有提示。
Fuentes y método
Fuentes consultadas el 19 de octubre de 2026. Los escenarios y cifras ilustrativos son ficticios. Las fichas y ejercicios son propuestas editoriales originales, sin resultados de clientes ni pruebas de proveedores atribuidos. Editorial standards · Disclosures.
