Caso de estudio UX
Un sistema de diseño solo está vivo si se usa como código
Este es un proyecto recurrente, un intento en cada empresa en la que he trabajado desde 2017. Una diferencia decidía cuál de ellos seguía en uso después de que me fuera: si la librería se compilaba en el producto o se archivaba como un documento para consultar. El método apenas cambió a lo largo de todos ellos, hasta que llegó la IA agéntica y lo modificó ligeramente. Lo que sigue es cómo se construyó el último de ellos, y lo que los anteriores me enseñaron al quedarse cortos.
Problema
Nadie decide construir cuatro botones distintos
El diseño en una empresa de cualquier tamaño está descentralizado, y por buenas razones: un diseñador trabaja con un equipo, aprende el problema de ese equipo y entrega según el roadmap de ese equipo. El costo llega después y en otro lugar. Basta poner las pantallas de dos de esos equipos una junto a la otra para que las diferencias sean inmediatas.
Esto ocurre a cualquier escala. En el extremo pequeño es un estilo de fuente que queda un poco fuera de lugar, o un tono de gris que existe porque alguien lo sacó de una captura de pantalla. En el extremo grande es todo un flujo que no tenía por qué existir, construido porque el equipo que lo necesitaba no tenía forma de saber que otro equipo ya lo había resuelto.
Lo que hace difícil arreglarlo es que no es un problema de calidad. Cada una de esas pantallas la hizo con cuidado alguien competente. La inconsistencia es un efecto secundario de la estructura, así que la solución también tiene que ser estructural, y un documento que le pide a los diseñadores ser consistentes no es una estructura. Es una petición.
Así que lo que hay que construir no es una guía de estilo. Es un lugar donde los diseñadores y los desarrolladores front end a quienes les importa la experiencia de usuario pueden codificar un lenguaje juntos, y una vía por la cual lo que acuerdan se convierte en parte de la arquitectura del producto.
Objetivos
Lo que un sistema tiene que lograr para valer el sprint
Equipo & audiencia
Un sprint de cada cuatro, y sin product owner
La estructura que mejor me ha funcionado es un equipo prestado en lugar de uno fijo. Un diseñador y un desarrollador front end de cada equipo de producto, que se reúnen según un calendario fijo.
Tres sprints de entrega normal de producto son cómo el equipo descubre lo que realmente le falta a la librería, así que el cuarto llega con una cola que alguien ya sintió la necesidad de crear, en lugar de una lista de mejoras imaginadas en una sala.
Eran seis personas: cuatro desarrolladores front end de cada equipo, y dos diseñadores. Trabajábamos con un tablero kanban y no teníamos product owner.
Sin uno, la redacción de tickets recayó en mí. La mayoría era pequeña y específica. De vez en cuando no lo era: por ejemplo, llevar cada token de color y de tipografía a cumplir con las pautas de contraste del W3C.
Audiencia
Quién lo abre en realidad
El beneficiario es el cliente. Los usuarios son cuatro grupos dentro de una empresa.
Alcance y limitaciones
Lo que no necesitaba un experimento
Casi nada de este trabajo se probó, y esa fue la decisión correcta. Dos decisiones clave constituyeron casi todo, y ninguna es el tipo de pregunta que un experimento puede responder.
El primero es eliminar una variación que nadie eligió. Si un producto tiene tres grises donde dos equipos inventaron uno cada uno y nadie sabe decir para qué sirve el tercero, unificarlos no es una hipótesis. No hay ningún resultado posible que abogue por conservar un accidente.
La segunda es aplicar directrices que ya existen y que están mejor respaldadas por evidencia que cualquier cosa que pudiéramos hacer nosotros mismos. Las relaciones de contraste son el caso más claro: el W3C ya hizo el trabajo, con un tamaño de muestra que ninguna empresa por sí sola alcanza, y volver a probarlo localmente para ver si a nuestros usuarios también les gusta poder leer las cosas sería puro teatro.
Cuando un cambio era realmente una pregunta, salía de este equipo. Bajaba al equipo de producto propietario de ese flujo, donde había un product owner para priorizarlo y un data scientist para diseñar la prueba.
Proceso
Seis pasos, y los primeros tres son política
El orden importa. Tres de estos seis ocurren antes de que se haga un solo componente, y saltárselos es cómo un sistema de diseño se convierte en una carpeta que alguien hizo una vez.
Mapear lo que ya existe
Un inventario antes de una propuesta. Colores, campos de texto, familias tipográficas, toggles, sliders, popups, botones, botones divididos, galerías, y cada variación de cada uno que el producto resultó contener.
El entregable es la versión visual de la lista, porque un recuento de trece estilos de botón es una cifra que alguien puede cuestionar, y trece botones puestos uno junto al otro en tres diapositivas no lo es. Este es el artefacto que hace posible el siguiente paso, y vale el tiempo que toma.
El catálogo resultó ser su propia mejor prueba, algo que solo descubrí al reconstruir esta página a partir de él. En el caso de Findhotel, el botón primario aparece ahí tres veces en tres azules distintos: #3979F5 en la diapositiva de botones, #0074F8 en el encabezado, #4476FB en los diálogos. Nadie eligió tres a propósito.
Formulario
13Botones
13Visualización
9Contenedores
8Imágenes
Menús
Navegación
Superposiciones
- #3979F5Diapositiva de botones, Search
- #0074F8Sección de encabezado, Search
- #4476FBDialog, Back to form
Un botón primario, tres azules. Este es el inventario defendiendo su propio caso.
Comprar el tiempo
Con el inventario en la mano, un lead developer y yo presentamos ante las personas que aprueban a dónde van los sprints. El público se eligió solo. Quienes venían quejándose de que el producto no se parece a sí mismo en distintos lugares eran los que harían esto realidad, porque ya habían notado el problema y no tenían un nombre para él.
Ese es todo el truco de este paso. Nadie financia un sistema de diseño como una abstracción. Lo financian una vez que han visto los trece botones, momento en el cual el argumento ya no es que la consistencia sea buena en principio.
La presentación pregunta cuáles son los problemas y responde con las respuestas simples: las funciones se lanzan despacio, nadie está seguro de qué componentes ya existen o cómo usarlos, los pequeños errores en los componentes nunca se corrigen, falta accesibilidad en toda la aplicación. Leído por separado, es el caso que se podría plantear en cualquier empresa.
Formar el equipo con gente de todos los equipos
Un diseñador y un desarrollador de cada equipo de producto.
Un equipo formado desde todas partes tiene un representante en cada sala donde la librería se usará más adelante. Eso es lo que convierte la adopción de un despliegue en algo que ya ha ocurrido, y es la diferencia entre una librería que usa la empresa y una librería que usan solo sus autores.
Cuatro equipos de producto, y las seis personas que juntan sus fortalezas: cuatro desarrolladores front-end y dos diseñadores UX.
Elegir herramientas
Del lado del diseño, esto se redujo a dos decisiones: en qué diseñar y dónde publicar. En Maersk, en 2019, InVision ya estaba licenciado y era de uso generalizado. En Findhotel era Zeplin. Ambas empresas usaban Sketch. En cada caso, la respuesta fue la herramienta que ya estaba en uso.
Del lado del desarrollo había un requisito nuevo, no uno heredado: la principal consideración era hacer que el proceso de publicar y depurar un componente fuera lo más automático posible.
Las cosas han cambiado desde entonces; Figma se usa ampliamente como la herramienta preferida de los diseñadores UX. Storybook sigue teniendo su lugar en el ciclo de desarrollo. Lo que realmente cambió está debajo de las herramientas. Un diseñador que trabaja con IA agéntica como Claude Code puede escribir y hacer commit del componente directamente, en lugar de depender de un desarrollador para implementar los cambios.
Hacer componentes, y acordar qué es uno
Dividido entre los diseñadores, un componente a la vez, y la unidad de trabajo es el componente en todos sus estados.
Dos diseñadores que se dividen ese trabajo producirán dos mitades incompatibles a menos que alguien escriba qué significa 'terminado', así que lo hice. Se redactaron nueve condiciones como una forma de criterios de aceptación para el sistema de diseño.
- Flexible al redimensionar con autolayout
- Usando la lista oficial de estilos de texto con nombre
- Usando la lista oficial de colores con nombre
- Ajustándose exactamente a la cuadrícula de unidades, cuya unidad más pequeña es de 4px
- Con una versión para móvil, tablet y escritorio, donde eso aplique
- Expone los mínimos permisos de edición que aún lo hacen útil
- Bien nombrado, incluida cada subcapa
- Probado en un lienzo para redimensionado y permisos
- Publicado en la plataforma oficial
Tres de ellas se entienden mejor viéndolas que leyéndolas, porque cada una es una regla sobre una forma.
Reglas de forma
Publicar, que es donde se zanja el argumento
Este es el paso que mis intentos anteriores hicieron mal, y hacerlo mal no parece un fracaso en el momento. Con InVision publiqué para diseñadores. Los diseñadores lo usaron. Los resultados estuvieron bien y los productos se separaron de todas formas, porque un silo de diseño y un silo de desarrollo producen la misma separación que no tener sistema, solo que un traspaso después.
El diseño acaba siendo código o no sale a producción. Así que mi trabajo se dirigió directo a los desarrolladores. Los componentes se mapearon uno a uno entre el lado del diseño y el lado del desarrollo, cada uno con una URL única indexada en un archivo que el front-end podía leer.
Abajo está un componente, la calificación por estrellas, en los tres lugares donde existe. Es el mismo objeto, con variaciones.
Lo que se entregó
Páginas que salieron del sistema de diseño
Estas páginas están ensambladas por completo con piezas hechas en sus sistemas de diseño correspondientes.
Floorplanner, 2018
Una herramienta de dibujo en lugar de un embudo. Las dos páginas de marketing del final son las interesantes, porque una página de marketing armada con los componentes del propio producto es un caso de ejemplo en que la guía llegó más allá del producto principal.
Maersk, 2019
Twill, Maersk's platform for the small and medium exporters and importers who book LCL (less than container load) cargo: shipments too small to fill a container, sharing the space and the cost with other people's freight. The screens below follow one booking from the destination search to the confirmation screen.
Findhotel, 2020
El embudo completo, en escritorio, tableta y móvil. Las capturas móviles son exportaciones de página completa.
Zimmer Biomet, 2021
Un planificador quirúrgico, construido en dieciocho meses. La mayoría de los diálogos de este producto son un componente con contenido distinto adentro. Cambia el componente una vez y cada diálogo cambia con él.
TrackBee, 2025
Cinco flujos mostrados en tres anchos cada uno: iniciar sesión, crear una cuenta, conectar plataformas publicitarias, elegir un plan y volver tras una suscripción caducada.
Conclusión
Un sistema de diseño vivo es un sistema que está programado
Cuando me fui era una librería viva, importada por cada producto del portafolio y no simplemente citada por ellos.
Llevar cada componente a la guía de accesibilidad del W3C cambió todos los productos a la vez, lo cual es un claro ejemplo de éxito.
En Coolblue en 2017 y en Maersk en 2019 lo que construí estaba dirigido a diseñadores, con limitada participación de desarrolladores, y ambos quedaron a merced de quien estuviera sentado en un equipo dado: era trabajo de ese diseñador echar mano de los componentes, mantenerlos al día y aplicarlos bien. Eso es demasiado para colgarlo de la diligencia de una sola persona, y no es una crítica a ninguno de los diseñadores involucrados. Un sistema cuyo mecanismo de cumplimiento es que alguien se acuerde es un sistema que se degrada en el primer sprint ocupado.