Qué promete el sistema
El formulario debe reunir contexto para responder, sin exigir una especificación. Empiece por la siguiente decisión del equipo: si encaja el trabajo, quién lo revisa y qué duda conversar. Cada campo obligatorio debe servir a una de esas decisiones.
Comparar opciones prácticas
Nombre, correo y explicación sencilla pueden bastar. Tipo de proyecto o presupuesto aproximado ayudan si las opciones se entienden y permiten incertidumbre. No exija teléfono porque una plantilla interna lo incluya. W3C destaca etiquetas, instrucciones y feedback como partes funcionales del formulario.
Probar el recorrido completo
Imagine una persona con una idea inicial y sin fecha. Ofrezca una opción de plazo desconocido, sin forzar una fecha inventada. Si el correo es incorrecto, señale el campo, explique cómo corregirlo y conserve la descripción. Tras enviar, distinga solicitud guardada y fallo de envío. Nadie debería adivinar si pulsar otra vez duplica la petición.
Hacer visible la recuperación
No use el texto de ejemplo como única etiqueta ni el color como único error. Muestre errores junto al campo y un resumen accesible en formularios largos. Pruebe teclado, zoom, etiquetas traducidas extensas y conexión lenta. El éxito debe reflejar recepción persistente y un siguiente paso real, sin prometer tiempos no comprobados.
Revisar el formulario como conversación y transacción
Escriba por qué necesita cada campo ahora, quién lo lee y qué ocurre si se desconoce. Si el presupuesto orienta la conversación, use rangos reales del equipo y opción pendiente. No obligue a inventar tamaño de empresa, arquitectura o fecha para pasar validación. El contexto opcional puede pedirse tras responder, cuando su propósito es más claro.
Pruebe correcciones con el formulario lleno. Escriba descripción larga, correo incorrecto y envíe. El mensaje debe explicar el problema, conservar lo válido y facilitar llegar al campo. Mueva el foco con criterio al resumen y anuncie el resultado sin interrumpir repetidamente la escritura. Repita con lector de pantalla y texto ampliado; cercanía visual no explica por sí sola la relación.
Revise después el servidor. Perder respuesta tras guardar es distinto de no recibir la solicitud. Los reintentos deben resolver al mismo registro y confirmar recepción persistente. No anuncie entrega del aviso solo porque entró en la cola. Explique el siguiente paso y cómo pedir ayuda. Use datos ficticios y destino local en pruebas; examine registro, notificación y pantalla.
Pruebas de aceptación del formulario
| Situación | Experiencia esperada |
|---|---|
| Respuesta desconocida | Opción pendiente o campo opcional permiten responder sin inventar. |
| Un campo inválido | El error lo identifica, explica la corrección y conserva lo demás. |
| Conexión perdida tras guardar | El reintento encuentra la misma solicitud sin duplicar registros. |
| Aviso retrasado | La solicitud sigue recibida; no se promete entrega ni se exige reenviar todo. |
Ejemplos para la revisión
¿Qué respuestas cambian la acción siguiente? ¿Puede una persona no técnica responder todo lo obligatorio? ¿Existe reintento seguro tras un corte? Revise un envío normal y otro fallido como recorridos completos, no solo el formulario vacío.