[añadir imagen de portada]

Chronicle

Chronicle es el sistema de diseño de Dots. Memories: el conjunto de fundamentos, componentes y reglas con el que se construye el producto. Nació de una necesidad concreta: la aplicación crecía más rápido de lo que podía sostenerse pieza a pieza.

Ámbito
Design System
Product Design
Documentación
Handoff to dev
Rol
Design System Manager
Product Designer
Equipo
Diseño y desarrollo
Periodo
Dots. Memories
2024 — 2026

Contexto

Cuando llegué, la interfaz no tenía un sistema común

Cada botón, popup o componente podía ser una pieza única. La aplicación había evolucionado a partir de diferentes proyectos y equipos, acumulando estilos y patrones que ya no siempre encajaban entre sí.

Para diseño significaba perder consistencia. Para desarrollo, implementar y mantener cada pieza individualmente. Cada pantalla nueva costaba más que la anterior.

[añadir botones inconsistentes]
Variantes de un mismo elemento, cada una por su cuenta
[añadir popups distintos]
Patrones duplicados con comportamientos distintos

Enfoque

Un sistema no se empieza dibujando componentes bonitos

Se empieza entendiendo qué hay, qué se repite y qué sobra. El trabajo siguió un orden: primero el inventario, después la base, y sólo entonces los componentes, su documentación y su paso a desarrollo.

Proceso de construcción del sistema, en seis pasos: auditoría, fundamentos, tokens, componentes, documentación y desarrollo.

Auditoría

Lo primero fue el inventario: recoger todo lo que existía y ponerlo junto

Sin ese mapa, cualquier componente nuevo habría sido una pieza más en la pila. La auditoría dejó cuatro cosas claras.

Inventario
Todo lo que existía, en un solo sitio.
Agrupación
Qué elementos eran en realidad el mismo.
Duplicados
Piezas distintas resolviendo lo mismo.
Inconsistencias
Comportamientos que no coincidían entre pantallas.
[añadir inventario de la auditoría]
El punto de partida, todo junto

Fundamentos

Antes de los componentes, la base

Color, tipografía, espaciado, rejilla, radios e iconografía. Convertidos en tokens y variables, dejan de ser criterio de cada pantalla y pasan a ser decisiones del sistema.

[añadir color]

Color y tokens

Una paleta reducida a roles: superficie, texto, acción y estado. Cada color existe una sola vez y se nombra por lo que hace.

[añadir tipografía]

Escala tipográfica

Una escala cerrada de tamaños e interlíneas, con un papel definido para cada nivel.

[añadir espaciado y grid]

Espaciado y rejilla

Un paso base y sus múltiplos para todo el espaciado, y una rejilla que se comporta igual en cada tamaño de pantalla.

[añadir iconografía]

Iconografía y radios

Un único set de iconos con la misma retícula y trazo, y una escala de radios ligada al tamaño del elemento.

Componentes

Un componente no es un dibujo reutilizable: es una regla

Por eso cada uno se definió con su anatomía, sus variantes, sus estados y su comportamiento responsive, además de cuándo usarlo y cuándo no.

[añadir Button]

Button

Anatomía, variantes y estados. La misma pieza en toda la aplicación.

[añadir Input]

Input

Validación y estados: vacío, activo, con error y deshabilitado, con el mismo comportamiento en cada formulario.

[añadir Modal / Bottom Sheet]

Modal y Bottom Sheet

Un patrón, dos contextos. Las mismas reglas de contenido y cierre, adaptadas al tamaño de pantalla.

[añadir Navigation]

Navigation

Comportamiento responsive definido desde el componente, no desde cada pantalla.

[añadir componente complejo]

[añadir componente propio del producto]

[añadir descripción]

[añadir componentes en contexto real]
Los componentes funcionando dentro del producto

Diseño y desarrollo

Una misma fuente de verdad para diseño y desarrollo

Los tokens y los componentes viven en Figma y en código con los mismos nombres y las mismas reglas. Lo que se cambia en el sistema llega al producto sin rehacerlo pieza a pieza.

Antes

Cada componente requería trabajo individual, en diseño y en desarrollo.

Después: diseño y desarrollo comparten una misma fuente de verdad.

Qué cambió: menos piezas resolviendo lo mismo, el mismo elemento se comporta igual en todas partes, se cambia en un sitio y llega a todos, y una funcionalidad nueva parte de piezas que ya existen.

Cadena de trabajo: design tokens, componentes, Figma, desarrollo y producto.

Resultado

De piezas aisladas a un lenguaje compartido

Antes

Piezas aisladas.
Estilos inconsistentes.
Implementación individual.

Después

Sistema compartido.
Componentes reutilizables.
Mayor consistencia y control técnico.

[añadir before / after del producto]

Reflexión

Chronicle cambió la forma en la que el equipo podía diseñar y construir el producto

De piezas aisladas a un lenguaje compartido. El sistema no sólo ordenó lo que ya existía: cambió cómo se empieza cada pantalla nueva.

Y no está terminado. Un Design System evoluciona al mismo ritmo que el producto al que sirve.

Siguiente proyecto

PMM CIEx Web Design