Una buena entrega de diseño permite entender las decisiones, el comportamiento esperado y el alcance sin tener que adivinarlos. Esta lista conecta cada requisito con un resultado comprobable y una persona responsable. El ejemplo de compra muestra qué documentar, incluidos los estados que no se ven en una captura de la pantalla ideal.
Registra el contexto de la decisión
Indica el problema del usuario, la opción elegida, las alternativas y la evidencia que respalda la decisión. En una pizarra online compartida, sitúa ese contexto junto a la especificación para que diseño, desarrollo y QA trabajen sobre la misma versión.
En este ejemplo, la tarea consiste en realizar un pedido desde la página de compra. La entrega incluye la revisión final, el envío y la confirmación; modificar el carrito queda fuera del alcance. El riesgo principal es la incertidumbre: si la respuesta tarda, el cliente puede intentar enviar el pedido de nuevo. La especificación debe distinguir un rechazo confirmado de una solicitud cuyo resultado todavía se desconoce.
| Qué revisar | Qué incluir | Cuándo está listo |
|---|---|---|
| Alcance y decisión | Tarea, pantallas incluidas, exclusiones y motivo del flujo elegido. | El equipo puede explicar qué resuelve el cambio y qué no. |
| Estados y transiciones | Preparado, datos no válidos, envío, resultado desconocido, rechazo y éxito. | Cada estado tiene un desencadenante, un mensaje y una siguiente acción. |
| Componentes y contenido | Referencia del componente, textos aprobados, recursos y versiones. | No quedan textos provisionales ni archivos de referencia ambiguos. |
| Adaptación de la interfaz | Orden de lectura, reglas de ajuste del texto y ejemplos en los anchos admitidos. | Los textos largos y los errores no ocultan el total ni la acción. |
| Accesibilidad | Orden de teclado, foco visible, nombres accesibles y anuncios de estado. | El flujo funciona sin ratón y no depende solo del color. |
| Pruebas de aceptación | Condición inicial, acción del usuario y resultado observable. | QA puede reproducir el caso sin interpretar qué significa «funciona bien». |
| Responsables | Persona responsable, preguntas pendientes, revisor y fecha. | Cada bloqueo tiene responsable y las excepciones acordadas están registradas. |
Detalla estados, recursos y contenido
Enumera los estados relevantes, no solo la pantalla ideal. Adjunta los recursos finales, las reglas de contenido y la referencia vigente de los componentes. Si un estado vacío o de permisos no corresponde a este flujo, deja constancia de ello en lugar de añadir pantallas innecesarias.
| Estado y desencadenante | Comportamiento visible | Siguiente acción y comprobación |
|---|---|---|
| Preparado: están los datos necesarios | Mostrar el total y el botón «Realizar pedido». | El foco llega al botón después de los campos de revisión; activarlo inicia un solo envío. |
| No válido: falta un campo obligatorio | Mostrar un error específico junto al campo y un resumen de errores. | Llevar el foco al resumen, con un enlace al campo. No enviar la solicitud del pedido. |
| Enviando: la solicitud está en curso | Cambiar el texto a «Enviando pedido…» e impedir activaciones repetidas. | Mantener el foco en el control y anunciar el estado. Repetir clics o pulsaciones no crea otros pedidos. |
| Desconocido: se interrumpe la respuesta | Mostrar «Estamos comprobando tu pedido», sin afirmar que ha fallado. | Consultar el intento existente antes de ofrecer otro envío y conservar los datos introducidos. |
| Rechazado: el servicio confirma que no se creó el pedido | Explicar el problema y ofrecer «Reintentar» cuando sea posible. | Anunciar el error, conservar los datos válidos y permitir otro intento tras la corrección. |
| Confirmado: se recibe el identificador del pedido | Abrir la confirmación con el identificador y el resumen. | Llevar el foco al encabezado. Recargar la confirmación no vuelve a enviar el pedido. |
Estos son los comportamientos previstos para el ejemplo. Desarrollo debe definir cómo se envían y se consultan los pedidos, incluida la identificación de solicitudes repetidas. Un botón que parece desactivado no basta para evitar pedidos duplicados.
Describe el comportamiento adaptable y los casos límite
Muestra cómo cambia la interfaz en los anchos admitidos y contempla textos largos, traducciones, foco de teclado, movimiento reducido y cortes de red. En esta compra, el total debe permanecer asociado a la acción de envío. En pantallas estrechas, coloca el resumen y la acción en orden de lectura y permite que los textos traducidos ocupen varias líneas sin tapar el precio.
Revisa un nombre de producto largo, un error de varias líneas y una vista ampliada con zoom. Si hay una acción fija, indica cómo se evita que cubra el campo enfocado o el error. La animación de carga puede ser útil, pero el texto debe seguir explicando el estado cuando se reduce el movimiento.
Haz verificables el comportamiento y la accesibilidad
Escribe reglas observables: qué ocurre al hacer clic, enviar, reintentar o volver. Incluye el orden del foco, el contraste esperado y el nombre accesible de los controles. Sustituye «gestionar bien los errores» por casos concretos:
- Datos incompletos: si falta un campo obligatorio de la dirección, al activar «Realizar pedido» no se envía la solicitud; el foco pasa al resumen de errores y desde allí se llega al campo.
- Respuesta lenta: con los datos válidos, activar de nuevo el botón durante el envío no genera otro pedido. El estado se entiende con teclado y lector de pantalla.
- Respuesta perdida: si el resultado es desconocido, al recuperar la conexión se consulta ese intento. Si el pedido existe, se muestra su confirmación sin crear otro.
- Rechazo confirmado: si el servicio confirma que no se creó el pedido, el cliente puede corregir el problema y reintentar sin volver a introducir los datos válidos.
- Éxito: el cliente puede leer el identificador, llegar a la siguiente acción con el teclado y recargar la confirmación sin repetir el envío.
Define criterios de aceptación y responsables
Asigna una persona responsable, un criterio de aceptación y una fecha de revisión a cada elemento. Diseño se encarga de estados, textos y especificación del foco; frontend, de la interfaz y la interacción; backend, de identificar pedidos y gestionar solicitudes duplicadas; QA, de registrar los resultados. En el documento de trabajo, sustituye estos roles por nombres.
En Boardmix, organiza la decisión, la lista y la matriz de estados en un mismo tablero. Añade comentarios junto al estado correspondiente, registra las preguntas pendientes y enlaza la especificación vigente y los resultados de las pruebas. Por ejemplo, junto a «Desconocido», pregunta al responsable de backend qué respuesta confirma el pedido existente. El tablero mantiene la conversación en contexto; las pruebas de la aplicación verifican la implementación.
La entrega está lista cuando diseño y desarrollo acuerdan cómo comprobarla, no cuando se ha descrito cada píxel. Si falta definir cómo consultar el estado del pedido, deja ese elemento bloqueado con su responsable y la decisión pendiente; no des por terminado el flujo solo porque las pantallas estén listas.
