Interfaces que se explican solas: 5 reglas de diseño

El diseño en Anested tiene una frase rectora: las interfaces deben explicarse solas. Todo lo demás que practicamos — cada comentario de revisión, cada mockup rechazado — es consecuencia de esa única prueba. Si un usuario necesita un manual, el diseño no está terminado.

Primero, jerarquía antes que decoración. Una pantalla es un argumento ordenado sobre qué importa más. Si todo está en negrita, nada lo está; si cada elemento exige atención, el usuario no le da atención a ninguno. Fijamos escalas tipográficas, espaciado y alineación antes de que nadie pueda elegir un color, porque la jerarquía comunica incluso cuando el estilo falla.

Segundo, los estados son el diseño. Estados vacíos, de carga, de error, de éxito — ahí es donde los usuarios viven realmente, sobre todo en la primera semana de uso de un producto. Los diseñamos primero, no al final. Un camino feliz precioso unido a un estado de error críptico no es un producto precioso; es un producto roto con buen marketing.

Tercero, el movimiento debe ganarse su costo de renderizado. Eliminamos casi toda la animación de nuestro propio sitio corporativo, y lo que sobrevivió fue la retroalimentación al pasar el cursor y nada más. Cada animación es un cobro sobre la atención del usuario y la batería del dispositivo. La contención, hemos descubierto, se lee como confianza.

Cuarto, la accesibilidad es un piso, no una funcionalidad. Ratios de contraste, estados de foco, navegación por teclado y marcado semántico se exigen en revisión de código exactamente como cualquier otro problema de corrección. Una interfaz que solo funciona para algunos usuarios es una interfaz con un bug.

Y quinto: si nos sorprendemos escribiendo un tooltip para explicar un control, primero intentamos rediseñar el control. A veces el tooltip gana — pero tiene que ganar el debate. El manual es el bug, y cada principio anterior es solo una forma distinta de no escribirlo.