Meridian

Cuando llegué a Meridian, la plataforma tenía once grises, cuatro alturas de botón y una documentación que había dejado de ser exacta dieciocho meses atrás. Nadie era descuidado: el vocabulario compartido era demasiado grueso para describir lo que cada equipo necesitaba, así que el mismo problema se resolvía una y otra vez por separado.

Nombrar es el trabajo

Reconstruimos el sistema alrededor de una gramática pequeña en lugar de una biblioteca grande. Cada token responde tres preguntas: qué rol cumple, en qué contexto vive y en qué estado está. Un token de superficie no es «gris 200»: es el plano más silencioso de un panel, y cambia con el tema.

La gramática se pagó sola de inmediato. Los diseñadores podían razonar sobre tokens que nunca habían visto, los ingenieros podían predecir un nombre y las revisiones por fin tenían una frase compartida con la que discutir.

Una sola fuente de verdad

Los tokens vivían en un JSON, transformado con Style Dictionary en propiedades CSS, constantes Swift y variables de Figma. La documentación se generaba de la misma fuente, así que una página obsoleta se convertía en un fallo de compilación. La herramienta era deliberadamente aburrida: nada que mantener, ningún panel que olvidar.

Un sistema es un contrato social

La gobernanza importó más que los componentes. Introdujimos un RFC ligero con dos semanas de comentarios, oficinas semanales a las que nadie estaba obligado y una política de deprecación que siempre nombraba un reemplazo.

Lo que me llevo

Los sistemas de diseño fracasan como producto, no como biblioteca. La curva de adopción es una curva de confianza: se mueve cuando usar bien el sistema es más fácil que rodearlo. La mitad del trabajo es escribir documentación que la gente lea; la otra mitad es ser el tipo de colega al que alguien le envía una idea a medio cocinar.