Evaluar el sistema de diseño en el flujo real
El número de componentes dice poco sobre su utilidad. Un botón de pedido muestra qué estados necesitan reglas compartidas.
Evalúe un sistema de diseño por la capacidad de sus piezas para apoyar tareas recurrentes de forma fiable. El número de componentes dibujados es una medida débil. Un solo botón de pedido muestra cuánto separa una vista atractiva de un comportamiento útil.
El ejemplo es ficticio. Un portal de clientes recibe un botón «Enviar pedido» cuidadosamente diseñado. El espaciado, el color y la tipografía son adecuados. El componente se considera terminado en el diseño. Lo que ocurre después de iniciar una solicitud sigue sin decidirse.
Un aspecto no cubre resultados distintos
Situación del ejemplo | Información que debe comunicar la interfaz |
|---|---|
Solicitud en proceso | La operación sigue activa; una nueva activación se trata según el flujo. |
El servidor confirma el pedido | Se muestran la referencia B-42 y el estado confirmado. |
El servidor rechaza una cantidad inválida | La cantidad sigue visible y puede corregirse de forma comprensible. |
La conexión se interrumpe tras el envío | El resultado es incierto; hay que comprobar el estado del pedido. |
Un botón rojo no explica la última situación. El pedido podría existir ya. Tampoco una marca verde sin respuesta confirmada demuestra el éxito. La información correcta importa junto al diseño visual.
Conectar comportamiento común y reglas del producto
El componente puede aportar foco visible, espacio para etiquetas largas y una presentación del procesamiento. El flujo de pedido debe saber qué cantidades son válidas y cómo aclarar un resultado incierto del servidor. Un botón genérico no resuelve esas reglas.
La guía WAI-ARIA explica una relación similar: un rol comunica el significado esperado, pero no implementa la interacción con teclado. Los valores visuales compartidos, como un color de texto con nombre guardado en un token de diseño, tampoco sustituyen el comportamiento ni la conexión entre diseño y código.
Un botón deshabilitado tampoco es la respuesta adecuada a todos los errores. GOV.UK señala posibles dificultades de comprensión. Si se bloquea una acción, la persona necesita una explicación comprensible y un siguiente paso accesible.
La profundidad necesaria depende del uso
Una página informativa estática no necesita estado de pedido. Un logotipo meramente visual no necesita una máquina de estados para peticiones al servidor. Imponer las mismas variantes a todos los componentes crearía mantenimiento innecesario.
Por otro lado, una biblioteca existente y probada puede cubrir bien estas necesidades. Integrarla adecuadamente puede tener más sentido que reconstruirla. La valoración cambiaría si se demostrara que los flujos reales no pueden representarse de forma comprensible con los componentes disponibles.
Valide un flujo recurrente en la interfaz implementada, incluidos errores y traducciones largas. Aquí el componente solo está integrado de forma útil cuando la persona con un resultado de pedido incierto también sabe qué hacer después. Evitar pedidos duplicados requiere además reglas de servidor adecuadas; deshabilitar un botón no basta.
Fuentes
Seguir leyendo
Todos los artículos
Su proyecto con ASES
Descríbanos su proyecto. Le responderemos con una primera valoración.