Tres productos, tres marcas, un design system: la cuenta cierra con design tokens organizados en capas. El token separa decisión de valor; qué color representa la acción primaria es decisión, el hex exacto es valor. Sin esa separación, cada marca nueva copia componentes y el conjunto diverge en semanas. Con ella, la marca sobrescribe valores y el sistema cambia de piel sin fork de componente.

¿Cuáles son las capas de tokens?

  1. Tokens primitivos: valores crudos como color-blue-500, compartidos por todas las marcas
  2. Tokens semánticos: action-primary, surface-raised, text-danger, referencian a los primitivos
  3. Component tokens: button-bg, consumen los semánticos y aíslan variaciones

La disciplina de naming sostiene el conjunto: los nombres describen rol, así que la marca B renderiza danger en naranja y text-danger sigue en pie. Los primitivos cambian poco; los semánticos acompañan al producto; los component tokens absorben excepciones sin contaminar el resto. Renombrar un token después de la adopción cuesta más que cualquier debate de naming en la creación.

¿Cómo compilar tokens para varias plataformas?

Fuente única en JSON, compilación vía Style Dictionary a CSS custom properties, Swift, Kotlin y config de Tailwind. Una referencia rota entre capas hace fallar el build en CI, antes de llegar al design review. Un tema sincronizado a mano diverge en semanas; el pipeline publica paquetes versionados por plataforma.

¿Cómo cambiar de marca en runtime?

Las custom properties cascatan por scope. Un atributo data-theme="marca-b" en el wrapper redefine los tokens semánticos, y la página cambia sin rebuild. El mismo mecanismo sirve para white-label: el host redefine dos tokens y el widget embebido viste la identidad del partner. Los tokens inline cuestan pocos KB y dispensan request extra; en SSR entran antes del paint para evitar el flash del tema equivocado en el primer render.

¿Cómo mantener coherencia entre marcas diferentes?

Una escala tipográfica modular en razón 1,25 con grid de espaciado de 4/8px sostiene tres personalidades distintas. Las marcas varían color, radio de borde y peso del display; el ritmo vertical y la jerarquía permanecen iguales en todas.

¿Cómo gobernar los cambios de token?

El PR de token pasa por review con snapshots de regresión visual en Chromatic y screenshots de Playwright comparando componentes en las tres marcas. El pipeline publica changelog por release, y los equipos consumidores ven el diff en el PR antes de actualizar. Un rename breaking sigue un ciclo de deprecación como cualquier API pública: la versión nueva convive con el alias de la antigua por un release.

¿El dark mode sale gratis?

Sale. El dark theme se vuelve un archivo de marca más que sobrescribe solo tokens de surface y text. Ningún selector nuevo, ningún fork de componente; la capa semántica absorbe la variación entera.