Diseñar formularios de proyecto con campos y errores claros
Un diseño de formulario aclara datos obligatorios, textos de campo y errores concretos. La información introducida se conserva al corregir.
Un formulario largo de proyecto se revisa mejor cuando está claro el siguiente paso de trabajo. Determine primero qué datos necesita realmente el equipo. Después planifique conjuntamente etiquetas, validación y respuestas.
Partir del siguiente paso de trabajo
En el portal ficticio siguiente, el equipo debe clasificar una primera consulta de software y hacer preguntas por correo. Por ello son obligatorios el título, el objetivo del proyecto y el correo. El teléfono sigue siendo opcional. No se exigen dirección de facturación ni número interno de cliente para esta consulta inicial. Es una decisión del flujo de ejemplo.
W3C WAI recomienda pedir solo la información necesaria para el proceso correspondiente. Cada pregunta restante debe tener un fin comprensible.
Mantener visibles los textos de campo
Las etiquetas permanecen visibles durante la entrada y se asocian técnicamente con sus campos. Un texto provisional dentro de un campo vacío no sustituye la etiqueta: desaparece al escribir. Por eso, finalidad y carácter opcional se explican junto al campo.
Campo | Antes | Previsto |
|---|---|---|
| Proyecto | Título del proyecto (obligatorio) – ¿Cómo llama su equipo a esta iniciativa? |
| Descripción | Objetivo del proyecto (obligatorio) – ¿Qué tarea debe facilitar el software? |
| Contacto | Correo para consultas (obligatorio). |
| Teléfono * | Número de teléfono (opcional). |
«Opcional» debe concordar con la validación al enviar. Un campo de teléfono vacío no debe causar error en este flujo.
Vincular el error a la situación concreta
Para este formulario se prevé validar al enviar. Los datos ausentes, las entradas incompletas y una transmisión no confirmada reciben respuestas distintas.
Situación | Mensaje previsto |
|---|---|
Falta el correo | Introduzca un correo electrónico para consultas. |
El correo contiene | El correo electrónico está incompleto. Ejemplo: |
Transmisión no confirmada | Aún no se ha confirmado la recepción de su consulta. Los datos introducidos se conservan aquí. |
Comprobar el formato no confirma que el buzón sea accesible. Un problema de transmisión no se presenta como un campo de correo mal cumplimentado.
Corregir sin perder datos
Tras un error de entrada, el diseño prevé un resumen de errores que recibe el foco del teclado y enlaza al campo afectado. El mismo mensaje comprensible aparece junto al campo; las tecnologías de asistencia también deben poder asociarlo. Se conservan los valores introducidos, incluido el que debe corregirse.
El mensaje de éxito llega solo tras la confirmación de recepción del servidor. Si el resultado es incierto, el flujo de reenvío debe aclarar cómo reconocer una consulta que quizá ya haya llegado.
Comprobar una tarea completa
Pida completar la consulta de ejemplo sin teléfono. Compruebe además la ruta de error con un correo incompleto: ¿se puede encontrar el mensaje, corregir la dirección y completar la consulta conservando el objetivo del proyecto? Incluya teclado, pantalla estrecha y tecnologías de asistencia utilizadas. Registre dónde se necesita ayuda y si al final se confirma realmente la recepción.
Fuentes
Seguir leyendo
Todos los artículos
Diseño y UX con ASES
Experiencia de usuario, interfaces e imagen de marca