El sistema de diseño “aburrido” para agencias que entrega más rápido: bases token-first, gobernanza y reglas de contenido

Un sistema de diseño no falla porque los botones no sean bonitos.

Falla porque nadie sabe quién puede cambiarlo, cómo se aprueban los cambios y qué pasa cuando el contenido no encaja.

Las agencias lo sienten más que nadie. Estás haciendo malabares con múltiples clientes, plazos y equipos—muchas veces con nuevos contratistas incorporándose a mitad de proyecto. Una librería de componentes “brillante” está bien, pero no te va a salvar de la rotación, el retrabajo y la muerte por casos borde.

Este es el argumento a favor del sistema de diseño aburrido para agencias: restricciones token-first, rituales claros de handoff y reglas de contenido que evitan layouts rotos—más la gobernanza justa para que el sistema sea confiable.

Callout: El sistema de diseño para agencias que gana no es el que tiene más componentes. Es el que reduce la toma de decisiones, evita regresiones y hace que la entrega sea predecible.

---

Por qué las agencias necesitan sistemas “aburridos” (y por qué a los clientes les encantan)

En empresas de producto, los sistemas de diseño suelen venderse como escalabilidad. En agencias, se venden como retención y margen.

Esto es lo que “aburrido” significa de verdad:

• Predecible: menos decisiones a medida por página, menos sorpresas en QA.
• Restringido: tokens y reglas que mantienen el trabajo dentro de guardarraíles.
• Transferible: el cliente puede hacerse cargo después del lanzamiento sin llamarte cada semana.
• Gobernado: los cambios no rompen en silencio 30 plantillas.

La verdad incómoda: los clientes no pagan por tu librería

Los clientes pagan por resultados—lanzamientos, conversiones, rendimiento, mantenibilidad. Un kit de UI es invisible hasta que se rompe.

Un sistema aburrido se convierte en una propuesta de valor de cara al cliente cuando lo planteas así:

1. Iteración más rápida (campañas, landing pages, nuevas funcionalidades)
2. Menor riesgo (menos regresiones, menos páginas de CMS rotas)
3. Onboarding más barato (nuevas contrataciones internas pueden mantenerlo)
4. Expresión de marca consistente en todos los canales

La matemática del margen que las agencias rara vez hacen

Si tu equipo quema 10–15% de un proyecto en retrabajo—inconsistencias de espaciado, deriva tipográfica, estados faltantes, “este componente no funciona con contenido real”—eso es margen.

Un sistema token-first reduce el retrabajo haciendo automáticas las decisiones más comunes:

• el espaciado se elige de una escala
• la tipografía se elige de un conjunto
• los colores se eligen por roles (no por valores hex)
• los componentes aceptan contenido dentro de límites definidos

---

Bases token-first: el conjunto más pequeño que cubre el 80%

La mayoría de los equipos empiezan por componentes porque son tangibles. Pero los componentes construidos sobre bases inestables se convierten en un patchwork de arreglos puntuales.

Token-first invierte el orden:

1. Definir las decisiones de diseño (tokens)
2. Codificarlas en diseño + código
3. Construir componentes que no puedan escapar de esas restricciones

Qué son realmente los tokens (y qué no son)

Los tokens no son “una paleta”. Los tokens son decisiones con nombre.

• Mal: blue-500, gray-200
• Mejor: color.text.primary, color.surface.default, color.border.subtle, color.brand.primary

Los tokens basados en roles sobreviven a rebrands y giros del cliente porque el significado se mantiene estable aunque cambie el valor.

El set inicial de tokens para agencias

Si quieres cubrir el 80% sin intentar hervir el océano, empieza aquí:

Tokens de color (basados en roles)

• color.text.primary, color.text.secondary, color.text.inverse
• color.surface.default, color.surface.muted, color.surface.inverse
• color.border.default, color.border.subtle
• color.brand.primary, color.brand.accent
• color.feedback.success, color.feedback.warning, color.feedback.danger

Tokens tipográficos

• font.family.base, font.family.display
• font.size.1–8 (o una escala con nombres como xs, sm, md, lg, xl...)
• font.weight.regular, font.weight.medium, font.weight.bold
• line.height.tight, line.height.base, line.height.loose

Tokens de espaciado

Elige una escala y comprométete. Las agencias ganan por ser consistentes, no por ser ingeniosas.

• space.0, 1, 2, 3, 4, 6, 8, 12, 16 (basado en 4px u 8px)

Radio, elevación y motion (mínimo)

• radius.sm, radius.md, radius.lg
• shadow.sm, shadow.md
• motion.duration.fast, motion.duration.base

Callout: Si tu sistema tiene 60 tokens de color y 9 escalas de espaciado, no tienes un sistema—tienes un museo.

Handoff de tokens que no se desmorona

Token-first solo funciona si diseño y desarrollo comparten la misma fuente de verdad.

Un enfoque probado en campo:

• Diseño: variables de Figma para tokens (color, tipografía, espaciado)
• Código: un paquete de tokens (p. ej., Style Dictionary, Tokens Studio, o un JSON simple + un paso de build)
• Naming: basado en roles, con prefijos claros (color.*, space.*, type.*)

Ritual práctico:

1. Revisión de tokens en el kickoff (30 minutos)
2. Bloquear el set inicial de tokens antes de producir componentes
3. Cualquier token nuevo debe justificarse: “¿Es una decisión nueva, o un one-off?”

---

Reglas de la librería de componentes: variantes, estados y restricciones de contenido

Los componentes son donde los sistemas de agencia suelen colapsar—porque los componentes se encuentran con la realidad: titulares largos, imágenes faltantes, localización, entradas raras del CMS y pedidos de marketing.

La solución no es “más componentes”. Son reglas.

Define los componentes como contratos

Cada componente debería tener:

• Propósito: para qué sirve (y para qué no)
• Variantes: las opciones permitidas (tamaño, tono, layout)
• Estados: hover, focus, disabled, loading, empty
• Reglas de contenido: qué contenido se permite y qué pasa cuando excede los límites

Si estás construyendo en Webflow, Framer, React o un stack con headless CMS, el principio es el mismo: los componentes deberían ser difíciles de usar mal.

Variantes: menos, más fuertes

Las agencias a menudo entregan “sopa de variantes” porque cada stakeholder del cliente pide una versión ligeramente distinta.

En su lugar, apunta a:

• 2–3 tamaños (p. ej., sm, md, lg)
• 2–3 tonos (p. ej., default, brand, subtle)
• 1–2 layouts (p. ej., stacked, inline)

Ejemplo: un Button no debería tener 14 estilos. Debería tener un conjunto pequeño que cubra:

• acción primaria
• acción secundaria
• acción destructiva
• acción estilo enlace

Estados: la fábrica de defectos en QA

Los estados faltantes son una de las formas más fáciles de perder tiempo en QA.

Haz obligatoria una “lista de verificación de estados” para componentes con los que los usuarios interactúan:

1. Default
2. Hover
3. Focus (visible con teclado)
4. Active
5. Disabled
6. Loading
7. Error (para inputs)
8. Empty (para componentes de datos)

Referencia del mundo real: equipos con sistemas maduros (piensa en Shopify Polaris o Material Design) documentan estados sin descanso porque saben que ahí es donde ocurre la deriva entre UX e ingeniería.

Restricciones de contenido: el puente entre diseño y CMS

Aquí es donde los sistemas de agencia se convierten en herramientas de retención.

Los clientes no rompen sitios porque te odien. Rompen sitios porque el CMS se lo permite.

Crea reglas de contenido por componente que sean explícitas y aplicables.

Reglas de contenido que deberías dejar por escrito

Para cada componente respaldado por CMS, define:

• longitud máxima del titular (y qué pasa si se excede)
• requisitos de proporción de aspecto de imagen
• campos opcionales vs obligatorios
• elementos permitidos de rich text (p. ej., nada de H1 dentro de cards)
• comportamiento del enlace (toda la card clicable vs solo el CTA)
• reglas de truncado vs salto de línea

Aplica las restricciones donde ocurre el trabajo

• En Webflow: usa component properties, estilos bloqueados y una guía clara para campos del CMS
• En headless CMS (Contentful, Sanity, Strapi): usa reglas de validación, límites de caracteres, campos obligatorios
• En código: agrega guards en runtime y fallbacks sensatos

Callout: Si tu sistema de diseño no incluye reglas de contenido, no tienes un sistema. Tienes una demo.

El playbook de “layout roto” (para que tu equipo deje de adivinar)

Decide de antemano qué pasa cuando el contenido es un desastre:

• Títulos largos: truncar después de 2 líneas con puntos suspensivos, mostrar el título completo en hover o en la página de detalle
• Imágenes faltantes: mostrar un placeholder neutro o cambiar a un layout solo de texto
• Demasiadas etiquetas: envolver a dos líneas y luego “+3”
• Secciones vacías: ocultar el componente por completo en lugar de dejar huecos incómodos

Estas decisiones evitan debates de última hora y mantienen el build avanzando.

---

Gobernanza que no te frena

La gobernanza suena a burocracia hasta que has entregado tres sitios de clientes y no recuerdas qué versión del componente hero es “la de verdad”.

La gobernanza ligera es cómo mantienes velocidad sin caos.

Un modelo de gobernanza simple para agencias

Necesitas tres cosas:

1. Responsables
2. Un camino para solicitar cambios
3. Versionado

Responsables: un único responsable (por sistema)

Elige:

• Design System Owner (Design): responsable de la integridad de tokens/componentes en Figma
• Design System Owner (Dev): responsable de la integridad de la implementación en código/Webflow

No hacen todo el trabajo. Deciden qué se integra.

Solicitudes de cambio: una sola plantilla

Usa un formulario ligero (Notion, Linear, Jira, GitHub issue) con:

• qué cambia
• por qué se necesita (pedido del cliente, bug, accesibilidad, rendimiento)
• componentes/plantillas impactados
• capturas/ejemplos
• plan de despliegue (nueva versión vs parche)

Regla general:

• Si afecta tokens o componentes muy usados, es una solicitud de cambio.
• Si es pura composición a nivel de página, no lo es.

Versionado: trata el sistema como un producto

Incluso si no estás publicando un paquete npm público, el versionado evita roturas silenciosas.

• Patch: correcciones de bugs, sin cambios de API (p. ej., arreglo de estilo de focus)
• Minor: nuevas variantes o componentes (compatible hacia atrás)
• Major: cambios incompatibles (renombrado de tokens, cambios en la API del componente)

El ritual de releases amigable para agencias

Una cadencia que funciona sin frenar la entrega:

• “System sync” semanal (20–30 minutos)
• Los cambios se agrupan en una nota de release
• Cada proyecto de cliente fija una versión del sistema (o al menos un snapshot con fecha)

Esto es especialmente útil cuando mantienes múltiples instancias de clientes (común en Webflow y builds con CMS).

La gobernanza incluye accesibilidad—por defecto

Las agencias se queman cuando la accesibilidad se trata como una checklist de última etapa.

Incorpora algunos no negociables:

• objetivos de contraste de color (WCAG AA como base)
• estilos de focus visible para todos los componentes interactivos
• reglas semánticas de headings para módulos del CMS
• soporte para reducción de motion (prefers-reduced-motion)

Referencias prácticas de herramientas:

• axe DevTools para checks automatizados
• Lighthouse para auditorías base
• Stark (Figma) para checks de contraste

---

Demostrar ROI a los clientes (y a tu propio equipo)

Si quieres que los sistemas de diseño se conviertan en una palanca de margen, tienes que medirlos como tal.

No métricas de vanidad. Métricas de entrega.

Las tres métricas de ROI que importan

1) Cycle time (idea → entregado)

Registra:

• tiempo desde el handoff de diseño hasta dev-ready
• tiempo desde el inicio de dev hasta pasar QA

Los sistemas token-first reducen el cycle time porque se debaten menos decisiones y menos inconsistencias de UI requieren retrabajo.

Cómo medir rápido:

• usa timestamps de Linear/Jira
• etiqueta tickets como “system-based” vs “bespoke”
• compara medianas, no promedios

2) Defectos de QA (especialmente regresiones de UI)

Registra:

• número de bugs de UI por página/plantilla
• número de bugs de “espaciado/tipografía inconsistente”
• número de bugs de “layout roto con contenido del CMS”

Las restricciones de contenido deberían reducir notablemente el volumen de defectos—especialmente después del lanzamiento, cuando los clientes empiezan a publicar.

3) Velocidad de onboarding (rampa de nuevo diseñador/dev)

Registra:

• tiempo para que un nuevo miembro del equipo entregue su primera página/componente
• número de preguntas en Slack sobre “qué estilo usar”

Un sistema aburrido es una herramienta de entrenamiento. Si funciona, la gente deja de pedir permiso y empieza a entregar con confianza.

Convertir el ROI en una narrativa de cara al cliente

Los clientes no quieren escuchar “construimos tokens”. Quieren escuchar:

• “Tu equipo puede lanzar nuevas páginas sin romper el layout.”
• “Tu marca se mantiene consistente incluso cuando cambia el contenido.”
• “Reducimos el tiempo de QA estandarizando estados y variantes.”

Una forma simple de empaquetarlo:

1. Un entregable de una página “System Overview”
2. Un walkthrough corto en Loom de “Cómo construir nuevas páginas”
3. Un changelog vivo (aunque sea solo una página de Notion)

Callout: La mejor jugada de retención no es encerrar a los clientes. Es hacer tu trabajo tan mantenible que confíen en ti para la siguiente fase.

---

Conclusión: construye el sistema por el que tu yo futuro te lo agradecerá

El sistema de diseño más rentable para una agencia rara vez es el más impresionante.

Es el que:

• empieza con tokens para que las decisiones sean consistentes y reutilizables
• entrega componentes con restricciones para que el contenido del CMS no pueda destrozar layouts
• usa gobernanza ligera para que los cambios sean seguros y predecibles
• demuestra valor con cycle time, defectos de QA y velocidad de onboarding

Si estás liderando un equipo de agencia, este es el siguiente paso práctico:

1. Audita tus últimos dos proyectos por retrabajo: ¿dónde se fugó el tiempo?
2. Define un set mínimo de tokens y fija convenciones de naming
3. Elige 8–12 componentes core y documenta variantes, estados y reglas de contenido
4. Implementa una plantilla de solicitud de cambios + versionado
5. Haz seguimiento del cycle time y los defectos de QA durante un mes

Si quieres, comparte tu stack actual (Webflow vs React, elección de CMS, tamaño del equipo) y te sugeriré un esquema mínimo de tokens y una cadencia de gobernanza que encaje con cómo entrega tu agencia en la práctica.