Un formulario puede rechazar una consulta válida porque espera un teléfono de un solo país, un apellido sin espacios o un nombre demasiado corto. El intento de mantener datos limpios termina convirtiéndose en una barrera. Validar bien exige distinguir un dato imposible de un dato poco habitual. También implica explicar cómo corregirlo sin hacer que la persona vuelva a escribir todo. Si tu negocio atiende clientes de distintos lugares, las reglas deben responder a necesidades operativas reales y no a suposiciones sobre cómo se escriben sus datos.
Justifica cada restricción antes de implementarla
Haz una lista de campos y pregunta para qué utiliza cada uno el equipo. Si el teléfono sirve para contactar, quizá necesites un país o prefijo, pero no una regla rígida basada solamente en la cantidad de dígitos local. Para nombres, considera espacios, acentos y diferentes estructuras. Restringe únicamente aquello que puedas explicar desde la tarea. Cuando exista un formato obligatorio, muéstralo antes del error. Una ayuda visible y un ejemplo pertinente permiten completar el campo sin adivinar las expectativas del sistema.
Distribuye la validación entre pantalla y servidor
MDN señala que la validación del lado del cliente mejora la experiencia, pero no reemplaza los controles del servidor. En términos prácticos, la pantalla ayuda a corregir antes de enviar y el servidor decide si puede aceptar la operación. Ambas capas deben compartir reglas compatibles. Si una acepta un dato y la otra lo rechaza sin explicación, la persona queda atrapada. Pide que las reglas se documenten y que los cambios se prueben en ambas partes, especialmente cuando un formulario alimenta una plataforma externa.
Presenta errores cerca de la decisión
Describe qué campo necesita atención y cómo corregirlo. Un borde rojo sin texto deja dudas y puede resultar difícil de percibir. Conserva el contenido correcto y evita borrar la selección de servicio por un error en el correo. Si hay varios errores, un resumen al inicio puede facilitar la navegación, siempre que cada mensaje también esté asociado al campo correspondiente. No reveles detalles internos del servidor. Para un fallo temporal, distingue claramente entre datos incorrectos y un problema técnico que la persona no puede resolver cambiando su respuesta.
Prueba casos reales sin usar datos personales
Construye una pequeña colección de ejemplos ficticios: nombres compuestos, correos con etiquetas, teléfonos internacionales, mensajes largos y campos opcionales vacíos. Prueba con teclado, autocompletado y un teléfono. Incluye el regreso a un formulario después de un error y una conexión interrumpida durante el envío. La revisión debe comprobar tanto la aceptación de datos válidos como el rechazo claro de datos incompletos. Cuando el equipo solicite una restricción adicional, conserva un ejemplo que muestre qué problema resuelve y otro que demuestre que no excluye situaciones legítimas.
DE LA LECTURA A LA ACCIÓN
Para aplicar hoy
- Relaciona cada restricción con una necesidad operativa comprobable.
- Mantén reglas compatibles en la pantalla y en el servidor.
- Explica los errores y conserva los campos que ya estaban correctos.
Fuentes y referencias
Documentación para profundizar. Los ejemplos de esta guía son didácticos.