Demasiado color, orden de campos equivocado
Tres criticas de UX que son tendencia hoy exponen el mismo fallo de diseno: pulido visual que socava silenciosamente la usabilidad. El problema del color es mas profundo de lo que crees.
Tres ensayos separados subieron a lo mas alto de Lobste.rs hoy -- una comunidad tecnica curada no conocida por compartir opiniones de diseno -- y todos estan diciendo versiones de la misma cosa incomoda: la UI moderna se esta empeorando a si misma por intentar demasiado.
Vale la pena prestar atencion. Cuando los ingenieros empiezan a escribir ensayos sobre color, orden de campos de formulario y window chrome, generalmente significa que los disenadores se han alejado lo suficiente de la funcion como para que incluso los no-disenadores noten la brecha.
El problema del color que nadie quiere nombrar
"Too Much Color" de Keith Cirkel no llega con un encuadre suave. Argumenta que las interfaces contemporaneas se estan ahogando en ruido cromatico -- que la proliferacion de colores de acento, degradados, tokens de color semanticos y variantes de modo oscuro/claro ha producido UIs que son visualmente mas recargadas sin ser significativamente mas claras.
Esta no es la conversacion de "demasiadas fuentes" de hace diez anos. Es mas especifica y mas condenatoria. Los sistemas de diseno han facilitado desplegar color de manera consistente, y esa consistencia se ha traducido en mas color en todas partes, aplicado con mas confianza, con menos mesura. Las herramientas resolvieron el problema equivocado.
El argumento resuena porque el color en los sistemas de diseno ha cambiado silenciosamente de ser una herramienta de comunicacion a una expresion de exhaustividad. Los equipos envian tokens para 40 tonos de un color de marca no porque los usuarios necesiten 40 tonos, sino porque un sistema de tokens completo se ve completo. El entregable reemplazo al proposito.
Para los disenadores que viven dentro de estos sistemas, el ciclo de feedback esta roto. Estas evaluando el color contra el archivo de diseno, contra la biblioteca de tokens, contra las guias de marca -- casi nunca contra la pregunta de si un usuario puede analizar la jerarquia de esta pantalla en menos de dos segundos.
Codigo postal primero: el diseno de formularios que no fue
Mientras tanto, zipcodefirst.com presenta un caso puntual para reordenar los formularios de direccion para que el codigo postal aparezca antes de la ciudad y el estado. La logica: la mayoria de los sistemas digitales usan el codigo postal para auto-completar ciudad y estado de todos modos, asi que pedirlos primero obliga a los usuarios a escribir informacion que el sistema ya conoce.
Suena menor. Es menor. Eso es exactamente lo que lo hace revelador.
Los formularios de direccion son uno de los patrones de UI mas comunes en internet -- flujos de checkout, registro de cuentas, confirmacion de envio. Los disenadores han copiado y ligeramente rediseñado el mismo orden de campos durante decadas porque refleja el formato de una direccion postal fisica. Pero un formulario digital no necesita leerse como un sobre. Solo necesita ser rapido y resistente a errores.
El argumento del codigo-postal-primero ha estado circulando en los circulos de UX durante anos. El hecho de que siga necesitando ser planteado -- el sitio web existe especificamente porque el patron no ha cambiado -- sugiere algo estructural. Las convenciones visuales heredadas son mas duraderas que los hallazgos de investigacion de usuarios. El formulario se ve bien, asi que se lanza.
Este es el modo de fallo silencioso en equipos de diseno maduros: patrones que tenian sentido para lo impreso, para escritorio, para modelos mentales anteriores, se preservan porque nadie los desafio especificamente. No estan lo suficientemente equivocados como para senalarlos, y cambiarlos requiere esfuerzo que no se mapea a ningun objetivo del sprint actual.
Window chrome como prueba de valores de diseno
El tercer articulo, "The Window Chrome of Our Discontent", examina los bordes, sombras, barras de titulo y enmarcado estructural de las ventanas de aplicacion -- las partes del diseno de interfaces que la mayoria de los disenadores no han repensado desde que aprendieron como se llamaban.
La tension del ensayo es esta: a medida que las aplicaciones se han vuelto mas poderosas y complejas, su enmarcado estructural se ha vuelto mas opinionado y a menudo mas intrusivo. El chrome que deberia retroceder para servir al contenido en cambio compite con el, senala alianza de plataforma, o impone elecciones esteticas que las aplicaciones individuales no pueden sobrescribir.
Para los disenadores de producto, esto presenta un problema real de restricciones. Heredas chrome de la plataforma. Heredas convenciones de campos de formulario de patrones historicos. Heredas sistemas de color de un sistema de diseno construido cuando el producto era un tercio de su tamano actual. Las decisiones originales se acumulan.
El hilo conductor: teatro de completitud visual
Lo que conecta estos tres ensayos no es la nostalgia por el diseno minimal. Es una critica mas precisa -- que ciertas categorias de esfuerzo de diseno visual se han convertido en actuacion en lugar de funcion.
Agregar mas tokens de color demuestra exhaustividad. Mantener ciudad/estado antes del codigo postal preserva un patron reconocible. Un window chrome elaborado senala inversion en la experiencia de la aplicacion. Ninguna de estas elecciones es obviamente incorrecta de forma aislada. Juntas, describen una cultura de diseno que se ha vuelto muy buena produciendo artefactos que se ven como decisiones de diseno consideradas mientras se alejan de la pregunta de experiencia de usuario que esas decisiones debian responder.
Los disenadores que mas riesgo corren aqui no son los descuidados. Son los cuidadosos -- los que genuinamente intentan construir productos cohesivos y pulidos -- que estan usando las metricas equivocadas para medir el exito.
Tres cosas para llevar a la proxima critica
Audita el color por funcion, no por completitud del sistema. Para cada color en uso activo, escribe una oracion sobre lo que esta comunicando a los usuarios. Si la oracion trata sobre marca o estetica en lugar de jerarquia de informacion o estado, marcalo para discusion.
Desafia los patrones de formularios heredados explicitamente. Formularios de direccion, selectores de fecha, flujos de multiples pasos -- escoge un patron heredado por trimestre y pasalo por investigacion de usuarios fresca. No asumas que el patron es correcto porque no ha roto nada.
Lee el articulo sobre window chrome con tu archivo de diseno actual abierto. La pregunta del enmarcado estructural aplica igualmente a contenedores de componentes, wrappers de modales y shells de navegacion. ¿Cual es el chrome en tu producto, y que esta haciendo ademas de existir?
Nada de esto requiere un rediseno. Requiere el habito de preguntar si el trabajo visual esta haciendo trabajo para el usuario -- que es, al final, la unica pregunta que el oficio debe responder.
Fuentes: Too Much Color (Lobste.rs), Put the ZIP code first (Lobste.rs), The Window Chrome of Our Discontent (Lobste.rs), CRO Through UX: What Top UX Design Firms Do Differently (dev.to)