Ser dueño del dashboard, no alquilarlo.

El reto

Los paneles de cara al cliente de Brambles se construían de dos formas, y ninguna de las dos nos pertenecía. Algunos vivían en Power BI, funcionales pero sin encajar del todo con la forma real de trabajar de los clientes de SCI. El resto funcionaba sobre Brix, un sistema de paneles interno construido sobre el backend de un proveedor externo, y la tarifa de ese proveedor había crecido hasta el punto de que la empresa ya no estaba dispuesta a pagarla.

Es una forma de problema muy reconocible: una capacidad de la que depende el negocio, apoyada en una relación con un proveedor que ha dejado de tener sentido comercial. La oportunidad genuina no era solo «construirlo más barato». Era usar la ventana de renovación del contrato con el proveedor como el momento para construir una experiencia de panel que los clientes pudieran moldear ellos mismos de verdad, con nuestros datos, nuestro frontend, por niveles de suscripción, en lugar de un producto fijo entregado por un proveedor.

Antes de que esa reconstrucción pudiera empezar, había un trabajo más corto y acotado que hacer primero: aplicar el white-labelling a los paneles existentes de Brix con el aspecto propio de SCI, para que los clientes experimentaran un producto coherente mientras el sistema real se construía entre bastidores. Yo dirigí esa transición, manteniéndola rápida y visualmente coherente con SCI, precisamente para que no tuviera que convertirse en una historia propia. Eso compró el tiempo que la construcción real necesitaba.

La oportunidad no era un panel más barato. Era un panel que nuestros clientes pudieran construir ellos mismos de verdad.

Mi papel

Lideré el diseño de producto del sistema de paneles personalizables para SCI, trabajando a través de UX, investigación, implementación y equipos de cara al cliente, y directamente con ingeniería, para llevarlo desde los bloques de construcción hasta un producto por niveles ya lanzado.

Eso incluía la base de sistema de diseño sobre la que se asienta toda la construcción: los componentes de gráfico, tabla y métrica a partir de los cuales se montan los paneles, los flujos para crear, editar y personalizar un panel, y la funcionalidad que decide qué puede construir realmente un cliente dado, según su nivel de suscripción. Con la fecha límite muy ajustada, incorporé a Dmytro, uno de los diseñadores más sólidos con los que he trabajado, a los componentes de visualización de datos como colaborador cercano en lugar de como un traspaso; co-creamos esa pieza juntos, y trabajamos estrechamente con los equipos de implementación y de cara al cliente para validar lo que los usuarios sobre el terreno, en la oficina y en la planta de fábrica, realmente necesitaban que un panel les dijera de un vistazo.

Todos los paneles de SCI, sea cual sea el nivel o la audiencia para la que se construyen, se montan a partir del mismo conjunto subyacente de componentes: bloques de gráfico, bloques de tabla y bloques de métrica, cada uno con su propio conjunto de variantes según el tipo de dato y el nivel de urgencia detrás de él. Un responsable de cadena de suministro que busca un problema necesita una lectura distinta de la de alguien que prepara un resumen de rendimiento mensual para una reunión con un cliente, así que la biblioteca de bloques tenía que servir a ambos sin convertirse en dos sistemas separados.

Aquí es donde más me apoyé en herramientas asistidas por IA, no para sustituir el pensamiento de diseño, sino para acelerar el puro volumen de variantes que necesita una biblioteca de componentes real. Dada la fecha límite, incorporé a Dmytro para co-crear conmigo los componentes de visualización de datos, y juntos usamos herramientas asistidas por IA para desarrollar los bloques de gráfico, tabla y métrica en Figma, de modo que un equipo pequeño pudiera producir un conjunto de bloques de construcción genuinamente amplio, y sus estados, en el tiempo que realmente permitía la fecha límite del contrato.

Los bloques de tabla y de métrica seguían la misma lógica: un componente, varias densidades y estados, en lugar de una tabla a medida construida por pantalla. Una tarjeta de métrica que muestra un solo número necesita comportarse igual tanto si informa sobre la entrega a tiempo de una sola ubicación como de todo un flujo, así que los estados, correcto, en riesgo, incumplido, se diseñaron una vez y se reutilizaron en cualquier sitio donde un número necesitara transmitir un veredicto, no solo un valor.

Nada de esto consistía en construir componentes por construirlos. Cada bloque existía porque los equipos de implementación y de cara al cliente habían validado una necesidad de usuario real detrás de él, trabajando directamente con las personas que día a día construyen paneles para Walmart, Costco y Tesco, y con los arquetipos al otro extremo de ellos: un analista de oficina con tiempo para profundizar en una tabla, y alguien en la planta de fábrica que necesita un solo número que le diga, de un vistazo, si tiene que actuar.

Aquí está la biblioteca completa, cada variante de métrica, tabla y gráfico, sus tamaños y sus estados, tal y como están documentados en Figma. Haz clic y usa el scroll o el gesto de pellizco para hacer zoom, arrastra para desplazarte.

Los clientes no debían partir de la nada. Según su nivel de suscripción, a un cliente se le podía entregar un panel de partida ya construido, para luego personalizarlo, añadir una tarjeta, eliminar otra, cambiar un gráfico por una tabla, o construir uno completamente nuevo a partir de la misma biblioteca de bloques. Internamente, los account managers tenían la misma capacidad de construcción, así que un panel que un cliente necesitaba con urgencia no tenía que esperar a un ticket de ingeniería.

La segmentación por niveles no se añadió después. Lo que un cliente dado podía construir, partir de una plantilla frente a construir desde cero, un conjunto limitado de bloques frente a la biblioteca completa, fue una parte de primer nivel del diseño de flujos desde el principio, porque es lo que permitió al negocio ofrecer un producto genuinamente diferenciado en cada nivel de suscripción, en lugar de una única experiencia de panel bloqueada tras un muro de pago.

Editar un panel existente seguía la misma lógica de bloques de construcción a la inversa: seleccionar una tarjeta, cambiar lo que muestra, redimensionarla, o eliminarla, sin salir nunca del propio panel hacia una pantalla de configuración aparte. Eso importaba más de lo que parece. Un cliente a mitad de una conversación con sus propios interesados necesitaba poder remodelar lo que estaba viendo en ese mismo momento, no abrir una solicitud y esperar.

Todo lo anterior es el resumen. A continuación están los dos flujos completos de Figma que hay detrás, cada estado, caso límite y anotación, tal y como se diseñaron. Haz clic en cualquiera de los dos y usa el scroll o el gesto de pellizco para hacer zoom, arrastra para desplazarte.

Una vez que existían los bloques de construcción en Figma, producto, UX e ingeniería trabajaban directamente a partir de ellos, construyendo el frontend en React, usando Claude en VS Code para convertir un componente documentado en código funcional rápido: constrúyeme una página, añade esta tarjeta, conecta este flujo. Ese flujo de trabajo es lo que permitió que la biblioteca de bloques se convirtiera en un producto real en semanas en lugar de meses, sin la habitual brecha entre lo que se diseñaba y lo que se lanzaba.

Ese flujo de trabajo se volvió aún más rápido una vez que la propia biblioteca de componentes de Figma se sincronizó con una biblioteca de componentes de código equivalente dentro del mismo AI Playground. Cada bloque de gráfico, tabla y métrica del Capítulo 01 ya existía como un patrón nombrado y documentado en ambos lados, diseño y código, así que añadir uno a una página de panel dejó de ser una pequeña tarea de construcción y se convirtió en un único prompt: añade un gráfico de barras aquí, cambia esta tarjeta por una tarjeta de métrica, añade una tabla debajo. El Playground no está adivinando cómo debería verse ese componente. Está leyendo el mismo bloque que el sistema de diseño ya define.

La fuerza de esto no está en que elimine la ingeniería, sino en que elimina la brecha entre un componente validado del sistema de diseño y una página funcional. Una tarjeta de gráfico, tabla o métrica que antes significaba un pequeño ticket de construcción ahora tarda segundos, y como cada tarjeta sigue procediendo de la misma biblioteca sincronizada en lugar de código puntual, esa velocidad no cuesta la coherencia que la construcción paralela del Capítulo 04 estuvo a punto de costar. Es la misma disciplina que el resto de esta construcción, aplicada un prompt cada vez.

Brambles estaba probando el desarrollo acelerado por IA de forma más amplia en ese momento, y una de las líneas de esa prueba produjo una segunda versión de la construcción del panel, construida rápidamente con herramientas de IA, pero construida fuera del sistema de diseño y sin los patrones de UX ya validados y en producción. Es un error fácil de cometer precisamente porque la IA elimina la fricción que antes obligaba a una comprobación: construir un sistema paralelo desde cero solía tardar lo bastante como para que alguien se preguntara si debía existir. Con IA, ya no, así que la divergencia puede llegar a producción antes de que alguien la detecte.

El resultado llegó a los equipos de implementación como algo que parecía terminado pero no era utilizable. Es la evidencia más clara y directa que tengo de que un sistema, por muy rápido que te permita moverte, solo se gana esa velocidad si lo que produce sigue siendo coherente.

Me opuse directamente a ello, no por defender un archivo de diseño por sí mismo, sino porque ya existía una versión funcional y validada, y reconstruir alrededor de ella desde cero le estaba costando al negocio un tiempo real frente a una fecha límite de cara al cliente. Tomé la decisión de traer la construcción paralela de vuelta bajo el mismo sistema en lugar de dejar que siguiera desviándose, volví a reunir en la misma mesa al product owner, al lead engineer y a Dmytro, y conseguí el apoyo aprobado para cerrar la brecha rápido sin retrasar la fecha límite que había puesto en riesgo. La solución no era ralentizar el desarrollo asistido por IA. Era apuntarlo hacia el sistema que ya funcionaba.

Lideré ese realineamiento personalmente, involucrándome directamente en la propia construcción acelerada por IA en lugar de revisarla después de los hechos, trabajando junto al product owner y al lead engineer, y con Dmytro de vuelta en los componentes de visualización de datos, para asegurarme de que trabajaba a partir de la misma biblioteca de componentes, los mismos bloques de Figma y los mismos patrones de UX validados que todo lo demás en SCI. Esa es la diferencia real entre la IA como atajo para saltarse un buen proceso y la IA como acelerante de ese proceso: la misma herramienta, apuntada hacia un sistema en lugar de rodeándolo, con alguien responsable de tomar esa decisión.

Una vez que ese realineamiento ocurrió, los números con los que había estado conviviendo el equipo de implementación se invirtieron. Los paneles que habían tardado hasta seis horas en construirse, y que aun así no quedaban bien, bajaron a minutos, porque montar una página a partir de componentes validados y documentados es un trabajo fundamentalmente más rápido que hacer ingeniería inversa de un patrón de UX desde cero cada vez, asistido por IA o no.

La biblioteca de componentes tampoco se quedó dentro de este único proyecto. Otros tres productos de Brambles han adoptado desde entonces los mismos componentes de panel y la misma UX de personalización para construir sus propios paneles, y la propia biblioteca se ha integrado en el sistema de diseño oficial de Brambles, no como un puñado de componentes atómicos tipo botones y campos de entrada, sino como patrones completos: los bloques de gráfico, tabla y métrica, y los flujos para montar, editar y personalizar un panel, a partir de los cuales otros equipos ahora pueden construir funcionalidades directamente en lugar de diseñarlas desde cero.