Reto
Dar una base común a Dots. Había mutado y crecido tanto que un mismo botón tenía cinco versiones, la tipografía no tenía escala y cada cambio se implementaba pieza a pieza.
Un marco común para que producto y desarrollo hablen el mismo lenguaje.
Chronicle es el sistema de diseño de Dots. Memories: las foundations, componentes y reglas con los que construimos la app para iOS, Android y web.
Nació de una necesidad muy concreta: la aplicación crecía más rápido de lo que podíamos mantenerla. Había componentes duplicados, decisiones distintas para el mismo problema y cambios que había que repetir pantalla a pantalla.
Mi trabajo fue ordenar esa complejidad y convertirla en un sistema que pudiéramos usar tanto en Figma como en código.
- Rol
- Product Designer
- Equipo
-
- Áreas
- Design System Multiplatform
Decisiones
Empezamos por auditar el producto y ordenar sus foundations antes de crear componentes y tokens. Priorizamos lo que tenía más impacto y dejamos fuera aquello que no aportaba valor.
Resultado
Un sistema de componentes compartido entre diseño y desarrollo. Una base que permite construir nuevas funcionalidades sin volver a resolver las mismas decisiones desde cero.
Chronicle en el producto
Proceso
El producto funcionaba.
Hasta que tratabas de cambiar un botón.
La aplicación había crecido y mutado a partir de distintos proyectos y equipos, acumulando estilos y patrones que ya no encajaban entre sí: cada botón, modal o aviso podía ser una pieza única.
Para diseño significaba perder consistencia; para desarrollo, implementar y mantener cada pieza por separado. Cada pantalla nueva costaba más que la anterior.
Un mismo botón, cinco versiones
Patrones duplicados con comportamientos distintos: distintas estructuras, distintos botones y distintas formas de cerrar.
43 estilos tipográficos, con color y opacidad implícitos en cada uno y sin mínimos de accesibilidad definidos.
Pantallas originales desde las que partíamos
El punto de partida
Un sistema que creció junto al producto
Chronicle no fue un proyecto paralelo. Lo construimos mientras seguíamos diseñando y desarrollando la aplicación, y eso condicionó muchas de las decisiones del sistema.
No intentamos sistematizarlo todo. Con el rebranding había piezas que iban a desaparecer, así que no tenía sentido convertirlas en componentes ni construir tokens para colores que ya no íbamos a mantener.
Empezamos por aquello que más se repetía y tenía más impacto, y fuimos incorporando el resto a medida que avanzábamos. Para cada nuevo componente primero probábamos los patrones nuevos en producto y, cuando funcionaban, los convertíamos en componentes.
El punto de partida: 30 estilos de color con 11 valores únicos, 41 estilos de texto en tres familias, un solo estilo de efecto y ningún componente reutilizable.
Foundations
Antes de los componentes, la base
Antes de construir componentes, ordenamos las decisiones que había detrás de ellos: color, tipografía, espaciado, grids, radios e iconografía.
Color y tokens
Los tokens se compartían entre Figma y Flutter, así que una misma decisión tenía el mismo nombre y valor en diseño y en código. Creamos colecciones de primitivos y tokens semánticos, cada uno con un rol: superficie, contenedor, texto, acción o estado y su valor en light y dark.
Escala tipográfica
De 43 estilos a 9 niveles: H1 a H6, Body Large, Body Default y Label Default, estos últimos en Regular, Medium y Bold.
También dejamos atrás Helvetica Neue. No terminaba de funcionar con la nueva dirección visual y la sustituimos por Inter. Fue uno de los cambios que más se notaron en pantalla.
Antes
Después
Espaciado y radios
Definimos los px mínimos de interacción y una colección de variables de layout con dos modos, 19,5:9 y 16:9, que nos permitían estandarizar espaciados y adaptar el diseño a dispositivos con pantallas más reducidas con otra proporción.
Iconografía
Los iconos también tenían su propia deuda: nombres distintos, retículas inconsistentes y estructuras diferentes y obsoletas dentro de Figma. Los catalogamos, unificamos nomenclatura y retícula y creamos un único componente de slot para controlar el tamaño sin duplicar variantes.
Después
Antes
Componentes
Un componente no es un dibujo reutilizable: es una regla
Cada componente tenía que definir algo más que su apariencia: anatomía, variantes, estados, comportamiento y nomenclatura.
Empezamos por lo que más se utilizaba en la mayor parte de las pantallas del producto (botones, modales, navegación, toasts e inputs) y posteriormente fuimos añadiendo más componentes a medida que avanzábamos con el rebranding de la app.
Resultado
Resultado
De piezas aisladas a un sistema compartido
No todo salió a la primera.
La documentación no se leía. Invertía tiempo en marcar paddings y restricciones que nadie consultaba. Así que cambiamos el enfoque: si una regla era importante, tenía que vivir en una anotación en el propio componente y no en una sección aparte.
El efecto blur rompía la app. Introdujimos blur y gradient blur en distintas superficies, pero el rendimiento no aguantaba algunas de ellas. Terminamos definiendo en el sistema cuándo usar blur y cuándo recurrir a una alternativa plana.
- 43 → 9
- estilos tipográficos
- 248
- tokens
- 429
- componentes
Después
Antes
Flujo de trabajo agéntico
De Figma a producción
Al principio, el proceso tenía varios pasos: diseñaba en Figma, desarrollo construía los componentes en Storybook y yo validaba cada decisión antes de llevarlos a Flutter.
Más adelante introdujimos IA en parte del proceso. Hoy un cambio visual puede salir de Figma y llegar a producción de forma directa. Identificamos el error, lo corregimos en Figma y, a través del MCP, un agente revisa el componente real y lo alinea al diseño propuesto. Diseño corrige, abre rama y lanza la PR y, por último, desarrollo la revisa y se integra en la app.
La IA no decide cómo es un componente. Reproduce la estructura, nomenclatura y variantes que hemos definido en Figma.
Aprendizajes
Cerrar antes de entregar
Una de las cosas que más aprendí con Chronicle fue a no dar un componente por terminado cuando solo funciona en el caso ideal.
Antes de pasarlo a desarrollo, intento cerrar sus estados, variantes y casos límite. Qué pasa cuando el texto es más largo, cuando falta información, cuando cambia el contexto o cuando alguien utiliza el componente de una forma que no había previsto.
Eso evita volver atrás después y, sobre todo, hace que diseño y desarrollo compartan la misma decisión.
Chronicle sigue creciendo. La IA ha cambiado cómo algunas de esas decisiones llegan al producto, pero el sistema sigue siendo el mismo: una forma compartida de diseñar y construir.