Caso de estudio UX
Un sistema de diseño solo está vivo si se usa como código
Esto es más una postura que un proyecto. Cuatro intentos de lo mismo, en cuatro empresas, entre 2017 y 2020, y una sola diferencia decidió cuál seguía en uso después de que me fui: si la librería se compilaba dentro del producto o se archivaba como un documento para consultar. El método apenas cambió entre los cuatro. Lo que sigue es cómo se construyó el último, y lo que me enseñaron los anteriores al quedarse a medio camino.
Muestra del sistema de diseño de Floorplanner. Un campo de texto puede tener varias variantes según su estado.
Problema
Nadie decide construir cuatro botones distintos
En una empresa de cualquier tamaño el diseño está descentralizado, y lo está por buenas razones: un diseñador se sienta con un equipo, aprende el problema de ese equipo y entrega contra la hoja de ruta de ese equipo. El costo llega después y en otro lado. Pon las pantallas de dos de esos equipos una junto a otra y las diferencias saltan de inmediato, y ninguna de ellas se eligió nunca.
Ocurren a todas las escalas. En el extremo pequeño es un estilo tipográfico que está un paso corrido, o un gris que existe porque alguien lo tomó de una captura de pantalla. En el extremo grande es un flujo entero que no necesitaba 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 los que les importa el diseño puedan codificar juntos un lenguaje, y una ruta por la que lo acordado llegue al producto sin que nadie lo vuelva a teclear.
Objetivos
Lo que un sistema tiene que lograr para valer el sprint
Nunca he cumplido del todo con las tres, y lo digo antes que cualquier otra cosa. Son la vara, y qué tanto se quedó corto un intento es lo más útil que tiene.
Equipo & audiencia
Un sprint de cada cuatro, y sin product owner
El arreglo 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, reuniéndose con una cadencia fija, y en el último intento esa cadencia fue un sprint de cada cuatro.
El intervalo está haciendo trabajo real. Tres sprints de entrega normal de producto son la forma en que el equipo descubre qué le falta de verdad a la librería, de modo que el cuarto llega con una fila que alguien ya sintió necesaria y no con una lista de mejoras imaginadas en una sala.
Éramos seis personas: cuatro desarrolladores front-end, uno de cada equipo, y dos diseñadores. Trabajábamos con un tablero kanban y no teníamos product owner, lo cual es menos una presunción que una explicación del siguiente párrafo.
Sin uno, escribir los tickets me tocó a mí. Casi todo era pequeño y específico: los estados de un componente o el nombrado de un componente. De vez en cuando no: llevar cada token de color y tipografía a la guía de contraste del W3C era un ticket en el sentido de que tenía un solo título.
Cada variante de componente lleva el nombre con el que se le llamará en el código, lo que hace que el diseño coincida con la implementación.
Audiencia
Quién lo abre en realidad
Vale la pena separar a los dos, porque un sistema construido para el equivocado falla de una forma difícil de ver. El beneficiario es el cliente. Los usuarios son cuatro grupos dentro de la empresa, y si alguno de ellos no obtiene lo que necesita, ese grupo empieza a mantener su propia versión.
Alcance y limitaciones
Lo que no necesitaba un experimento
Casi nada de este trabajo se probó, y esa fue la decisión correcta y no un atajo. Dos tipos de cambio conformaban casi todo, y ninguno es el tipo de pregunta que un experimento pueda 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.
El segundo es aplicar una guía que ya existe y está mejor sustentada que cualquier cosa que pudiéramos hacer nosotros. 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 alcanza, y repetirlo en casa para ver si nuestros usuarios también prefieren poder leer sería puro teatro.
Cuando un cambio sí era una pregunta, salía de este equipo. Bajaba al equipo de producto dueño de esa superficie, donde había un product owner para priorizarlo y un data scientist para diseñar la prueba, que además es el único lugar donde vivía el tráfico para responderla. Un equipo de sistema de diseño que corre sus propios experimentos es un equipo de sistema de diseño compitiendo con la hoja de ruta de la que depende.
Proceso
Seis pasos, y los primeros tres son política
El orden importa más que el contenido. Tres de estos seis ocurren antes de que se dibuje un solo componente, y saltárselos es como un sistema de diseño acaba siendo 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.
La lista no es el entregable. El entregable es la versión visual de la lista, porque un conteo de trece estilos de botón es un número que alguien puede discutir y trece botones desplegados en tres diapositivas no lo es. Este es el artefacto que hace posible el siguiente paso, y vale los días que toma.
El catálogo resultó ser su mejor prueba, algo que descubrí apenas al reconstruir esta página a partir de él. El botón primario aparece tres veces en tres azules distintos: #3979F5 en la diapositiva de botones, #0074F8 en el encabezado, #4476FB en los diálogos. La diferencia entre el primero y el último es de sesenta y ocho puntos de rojo. Nadie eligió tres. Tomados de las propias diapositivas del deck, cinco años después de hacerlo.
Form
13Buttons
13Display
9Containers
8Images
5
Menus
3Navigation
3Overlays
2- #3979F5Diapositiva de botones, Search
- #0074F8Sección de encabezado, Search
- #4476FBDialog, Back to form
Un botón primario, tres azules, ninguna decisión. 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, y no es un truco. Nadie financia un sistema de diseño como abstracción. Lo financian una vez que han visto los trece botones, y a partir de ahí el argumento ya no es que la consistencia sea buena en principio.
El deck en sí son diez diapositivas y casi nada de él habla de botones. Pregunta cuáles son los problemas y responde con los llanos: las funciones salen lento, nadie está seguro de qué componentes ya existen ni de cómo usarlos, los errores pequeños en los componentes nunca se arreglan, falta accesibilidad en toda la aplicación. Luego dedica dos diapositivas a consistencia, eficiencia, escala y calidad, y una a lo que hay que evitar, que era volverse tan rígido que la librería empiece a decidir qué se puede diseñar. Leído por su cuenta es el argumento que podría hacerse en cualquier empresa, y para eso sirve. El argumento específico era el tablero de arriba. El deck es el general que escribes después para que haya algo que aprobar.
Formar el equipo con gente de todos los equipos
Un diseñador y un desarrollador de cada equipo de producto, en lugar de las dos o tres personas más entusiasmadas con los sistemas de diseño. El entusiasmo es más fácil de encontrar y da un peor resultado.
Un equipo formado con gente de todas partes tiene un representante en cada sala donde la librería luego se usará o se ignorará. Eso convierte la adopción de un despliegue en algo que ya ocurrió, y es la diferencia entre una librería que usa la empresa y una que usan 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, sobre todo al no elegir
Del lado del diseño esto se redujo a dos decisiones: en qué dibujar y dónde publicar. En Maersk, en 2019, InVision ya estaba licenciado y se usaba mucho. En Findhotel, un año después, era Zeplin. Ambas empresas tenían licencias de Sketch. En cada caso la respuesta fue la herramienta que ya estaba en la casa, y hacer lo contrario habría gastado la credibilidad temprana del proyecto en una migración que nadie había pedido.
Del lado del desarrollo había un requisito real y no heredado: la mayor parte posible del camino de un componente publicado a un componente usable tenía que ser automática, porque cada paso manual en ese camino es un lugar donde las dos copias empiezan a diferir.
Zeplin La fuente de verdad que miraban ambos lados. Todo lo de abajo está dispuesto para mantener esta honesta. 
Sketch Donde se dibujaban los componentes, y la licencia que ambas empresas ya pagaban. 
Figma La alternativa en línea, y en 2020 la retadora. Hoy es la opción por defecto, y Sketch es la que hay que defender. 
Storybook El otro extremo del mismo estante. Un componente que existe aquí existe en el producto. 
Chromatic Lo que convirtió un pull request en algo que un diseñador podía revisar, al volver un diff una imagen. Dibujar componentes, y acordar qué es uno
Repartido entre los diseñadores, un componente a la vez, y la unidad de trabajo es el componente en todos sus estados, no el componente. Un campo no está terminado cuando se ve bien vacío.
Dos diseñadores que se reparten ese trabajo producirán dos mitades incompatibles a menos que alguien escriba qué significa terminado, así que lo hice. Nueve condiciones, y un componente cumplía las nueve o no iba al estante.
- Flexible al redimensionar
- Usa la lista oficial de estilos y familias tipográficas
- Usa la lista oficial de colores
- Encaja exactamente en la retícula de 8px, o en la de 4px
- Tiene versión móvil y de escritorio, donde 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
Cuatro de ellas se entienden mejor viéndolas que leyéndolas, porque cada una es una regla sobre una 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 el último intento se dirigió directo a los desarrolladores: componentes mapeados uno a uno entre el lado del diseño y el lado de la construcción, cada uno con una URL 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 en los tres, y ese es todo el argumento de esta página reducido a algo comprobable.
Lo que se entregó
Páginas que salieron del estante
Ninguno de estos es un diseño que presentaría como una pieza de trabajo por sí sola. Están aquí como el otro tipo de evidencia: páginas armadas casi por completo con piezas que alguien más también pudo haber usado.
En el orden en que ocurrieron los sistemas, que para los primeros cuatro es el orden de las marcas bajo el encabezado. Dos de ellos tienen pantallas aquí, uno tiene un espacio reservado, y de Coolblue en 2017 no queda nada que pueda mostrar. El quinto es posterior a todo lo demás en esta página, y lo que puede mostrar es de otra naturaleza.
Floorplanner, 2018
El más antiguo del que queda algo por mostrar, y un tipo de producto distinto: 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 el caso en que la guía llegó más allá del producto para el que se construyó.
Maersk, 2019
El de en medio, y el hueco de esta página. Maersk se menciona tres veces arriba de esta línea, y otra vez en la conclusión, donde es una mitad del contraejemplo del que depende todo el argumento. Mientras no se muestre algo de él aquí, esa mitad descansa en mi palabra. El espacio se reserva en lugar de omitirse en silencio.
Selección de material
Findhotel, 2020
El embudo completo, en ambos dispositivos. Las capturas móviles son exportaciones de página completa y una de ellas es doce veces más alta que ancha, así que lo que se muestra aquí es la parte superior de cada una; al abrir una se obtiene la página entera.
Zimmer Biomet, 2021
Este queda fuera de la serie de arriba. Un planificador quirúrgico, construido en dieciocho meses, y el único producto médico de los cinco.
Primero las pantallas. Después las piezas de las que están hechas, que es de lo que trata esta página: 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.
Las piezas. Las primeras cuatro son el mismo diálogo con algo distinto en el centro. Las dos siguientes se dejaron fuera a propósito, y decidir qué no es un componente es el mismo trabajo que decidir qué sí lo es. Las últimas dos son componentes tal como aparecen en el producto, con el botón que los abre.
Conclusión
Uno de los cuatro seguía compilando cuando me fui
Cuando dejé Findhotel era una librería viva, importada por cada producto del portafolio y no simplemente citada por ellos. Qué ha sido de ella desde entonces, no tengo forma de saberlo.
Llevar cada token a la guía de contraste del W3C cambió todos los productos a la vez, algo que un documento no puede hacer a ninguna velocidad.
Átomos listados en la librería publicada, contados en la barra lateral de la captura de la calificación por estrellas del paso seis, donde la lista se sale por abajo de la pantalla.
Nadie midió qué efecto tuvo todo esto en la rapidez con que se construían las cosas. Ese hueco es lo último que esta página tiene que decir, al final de ella.
El contraste con dos de los tres anteriores es la razón por la que existe esta página. En Coolblue en 2017 y en Maersk en 2019 lo que construí estaba dirigido a diseñadores, con poca 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.
Los mismos seis pasos desde entonces
Todo lo de arriba se detiene en 2020, que es cuando se escribió. El método no se detuvo ahí. Se ha usado dos veces más desde entonces, en dos campos con poco en común con un embudo de reservas, o entre sí.
Casi todo se trasladó. El inventario sigue viniendo antes de la propuesta, y publicar sigue siendo el paso que decide si la librería se usa. Lo que cambia es cuánto cuesta un error. Donde ese costo es alto, las nueve reglas se vuelven más estrictas y no distintas.
Zimmer Biomet, 2021
Un planificador quirúrgico, dieciocho meses, un diseñador en el producto.
El paso tres no ocurrió. No había un diseñador y un desarrollador de cada equipo de producto, porque había un diseñador y un product owner. Así que la librería se usó porque quien la dibujó era también quien la usaba. Esa es una prueba mucho más pequeña que la que los cuatro proyectos de arriba le dieron al método, y no leería más que eso en ella.
Los demás pasos corrieron como antes. Las herramientas fueron las que ya se usaban, Figma y Zeplin. Los componentes se seguían dibujando de uno en uno, en todos sus estados, y un componente seguía sin estar terminado cuando solo se veía bien vacío.
Lo que añadió el entorno médico fue un segundo nivel. Primero tokens, después componentes construidos a partir de esos tokens. La razón es el papeleo. Cada cambio a este producto necesitaba cuatro cosas por escrito: qué significaba el éxito, el riesgo para el paciente, qué más tocaba el cambio, y evidencia de que funcionaba. Cuando documentar un cambio cuesta tanto, cambiar un token sale mucho más barato que cambiar cuarenta componentes. Ese es todo el argumento del segundo nivel.
Así que la novena regla crece. Publicar solía ser donde un componente quedaba terminado. Aquí es donde empieza su papeleo. Las otras ocho no cambian.
Si dos niveles son la respuesta correcta para el siguiente, todavía no lo sé. Es la respuesta que este proyecto necesitaba.
TrackBee
El segundo de los dos, y el actual. El mismo espacio que Maersk más arriba, reservado por la misma razón y en los mismos términos.
Selección de material
Aprendizajes
Hay una cuarta y es la incómoda. Nada de esto tiene un número asociado. Puedo mostrar que la librería se construyó, que se importó, que decenas de componentes se estandarizaron y se eliminaron duplicados, y no puedo decirte qué efecto tuvo nada de eso en la velocidad de entrega, porque nadie lo instrumentó y yo no insistí lo suficiente para que alguien lo hiciera.
El costo de eso no es académico. Cada sistema de diseño en el que he trabajado ha tenido que defenderse otra vez, desde el principio, ante gente con todo el derecho a preguntar qué devolvió el anterior. Una respuesta a esa pregunta es el artefacto más valioso que este trabajo pudo haber producido, y es justo el que no tengo. Si empezara el siguiente el lunes, la medición iría en el primer sprint, no en el eventual.