
Sobre un sistema de diseño que parte de colores y componentes y se extiende al comportamiento, el contexto y la confianza.
Imaginemos una tabla de trabajo. Acotamos los registros, seleccionamos algunas filas y pasamos a otra vista para examinar un detalle. Al volver, esperamos que se conserven nuestra búsqueda, nuestra selección y el punto en el que estábamos.
Pocas veces describimos esta expectativa como parte del diseño. Sin embargo, buena parte de nuestra relación con una interfaz se construye aquí: ¿Qué ocurrirá como respuesta a lo que hacemos? ¿Qué recordará el sistema? ¿Cómo sabremos que una operación no ha terminado?
Esta fue la pregunta que me interesó al trabajar en Muhit: ¿Cómo pueden las distintas partes de una interfaz ofrecer al usuario un comportamiento compartido?
¿Dónde empieza la coherencia?
Es fácil describir la parte visible de un sistema de diseño. Se reúnen familias tipográficas, colores, espacios, botones, tarjetas y tablas. Entre las páginas aparece un ritmo familiar.
Pero dos botones de aspecto similar pueden generar expectativas distintas. Uno completa una operación de inmediato; otro abre un diálogo de confirmación. Un formulario muestra el error junto al campo correspondiente, mientras otro ofrece solo una notificación breve. Una tabla conserva el filtro; otra vuelve al principio con cada actualización.
En una interfaz así, el usuario tiene que aprender de nuevo el comportamiento aunque reconozca el aspecto.
Muhit nació de la idea de convertir en una biblioteca independiente las piezas desarrolladas durante el trabajo de interfaz de Nevmos. Separarlas exigió preguntarse qué decisiones pertenecían a un producto concreto y cuáles podían trasladarse a otros trabajos.
El logotipo y los contenidos de un producto pertenecen a su contexto. En cambio, el foco visible del teclado, las etiquetas de estado comprensibles, la posibilidad de reintentar tras un error y la información sobre el resultado de una operación tienen un ámbito de uso más amplio.
Muhit intenta mantener juntas esas decisiones comunes. También encuentro sentido aquí a las asociaciones de entorno y vecindad que tiene su nombre: cada pieza cumple su propia función, mientras el ambiente que forman entre todas debe seguir siendo comprensible.
Un mismo lenguaje en condiciones distintas
Ese entorno no tiene por qué verse igual en todos los proyectos.
Una herramienta de investigación puede dar espacio a textos largos y referencias. Una pantalla de administración de uso frecuente puede necesitar una distribución más compacta. Otro trabajo puede construirse con superficies más serenas y espacios más generosos.
Abordo los temas de Muhit a partir de estas diferencias. El color, la tipografía, la densidad, los bordes y las preferencias de movimiento pueden cambiar conjuntamente. Bajo esos cambios hay funciones definidas, como texto, fondo, acento, estado y foco.
Así, cuando cambia un tema, también debemos preguntarnos: ¿El texto sigue siendo legible? ¿Se entiende el estado seleccionado? ¿La persona que navega con el teclado puede ver dónde está? ¿Las zonas táctiles son suficientes en la vista compacta?
Una comprobación similar aparece en los distintos estados de una página.
Una pantalla llena de contenido muestra solo un momento del diseño. La misma pantalla debe tener una respuesta prevista mientras espera datos, cuando aún no hay registros, cuando falla una solicitud o cuando se requiere acceso.
«Todavía no hay registros» y «No se han podido cargar los registros» son situaciones distintas. El siguiente paso del usuario también puede ser diferente. En la primera tiene sentido crear un registro; en la segunda puede ser necesario volver a intentarlo.
Trabajar estos estados en las recetas de página de Muhit incorpora al diseño el comportamiento de la pantalla fuera de su recorrido habitual.
El mismo cuidado continúa al conectar los componentes a una aplicación. En las integraciones de referencia cobran importancia detalles como conservar el borrador de un formulario al cambiar de idioma, o trasladar el filtro y la selección al volver a montar una tabla. Lo que el usuario acaba de hacer constituye el contexto del siguiente paso.
Una interfaz que cumple su promesa
Este planteamiento también tiene sentido cuando los agentes proponen interfaces.
Un modelo puede proponer, mediante una definición estructurada, la información que se mostrará y las acciones que se ofrecerán. Es posible establecer de antemano en qué componentes puede convertirse esa definición y dentro de qué límites debe mantenerse.
Aquí interviene el adaptador de agentes de Muhit: valida la definición y construye la vista con los componentes permitidos. Cuando el usuario elige una acción, comunica esa elección a la aplicación. Guardar los datos, enviar una solicitud y comprobar la autorización necesaria siguen siendo responsabilidad de la aplicación.
Esta distinción también debe resultar clara para el usuario. La presencia de un botón «Guardar» en la pantalla no indica que el guardado haya terminado correctamente. La información que ofrece la interfaz debe apoyarse en el estado real de la operación que hay detrás.
Aquí se concentra la idea que guía el diseño de Muhit: La promesa de una interfaz debe corresponderse con lo que hace el sistema.
Sigue siendo un ámbito de trabajo que requiere comprobaciones. Muhit 0.15.0 incluye controles automáticos de componentes, estados de página, opciones de tema y ejemplos de integración. El uso en dispositivos reales y la evaluación con lectores de pantalla siguen formando parte del trabajo pendiente.
A medida que un sistema de diseño evoluciona, incorpora nuevos componentes. Junto a ello, quiero observar cuánto aprendizaje nuevo exige al usuario.
Cuando un comportamiento que ya hemos aprendido conserva su sentido en otra página, cuando nuestra selección encuentra su lugar en el siguiente paso y cuando el sistema ofrece un camino comprensible ante una situación inesperada, empieza a formarse un lenguaje común.
Desarrollo Muhit como un entorno en el que distintos trabajos puedan encontrar un lugar dentro de ese lenguaje conservando su propio carácter.
Formas distintas, un ritmo compartido. La ilustración de portada se generó con IA para este artículo.
Recursos: Código fuente de Muhit · Documentación de Muhit 0.15.0
Artículo relacionado: ¿Qué hace posible un lenguaje visual limitado?
Conceptos del Atlas: Diseño · Software · Contexto · Sistemas
Sigue leyendo
Publicaciones con temas en común.
¿Proponer una interfaz otorga permiso para actuar?
Los límites entre las propuestas de interfaces de la IA, los permisos de operación y el control humano, a través de Muhit.
Muhit: ¿Cómo funciona una decisión de diseño en pantalla?
Cómo se concretan las decisiones sobre borradores, foco, errores, cancelación y temas en los ejemplos funcionales de Muhit.
Se conecta con
¿Qué hace posible un lenguaje visual limitado?
Relaciona las posibilidades de un lenguaje visual limitado con el comportamiento compartido de las interfaces y la conservación del contexto en Muhit.
Muhit: ¿Cómo funciona una decisión de diseño en pantalla?
Desarrolla el lenguaje compartido de comportamiento del primer artículo sobre Muhit mediante ejemplos funcionales de borradores, foco, errores, cancelación y temas.
¿Proponer una interfaz otorga permiso para actuar?
Relaciona la idea del primer artículo de que una interfaz cumpla su promesa con la distinción entre la propuesta de un modelo y el resultado de una operación real.