002 ensayo
Estado 1 · Clásico
El design system construido entre 2015 y 2025 para servir a equipos de producto humanos. Es la base sobre la que todo lo demás se apoya. Es también el inventario que un agente necesita antes de poder leerlo.
Hay algo tramposo en hablar del Estado 2 o del Estado 3 antes de reconocer qué hemos construido en el Estado 1. La última década de design systems (desde Material Design en 2014 y Lightning en 2015 hasta Primer, Polaris, Carbon, GOV.UK y los sistemas internos de casi todas las organizaciones medianas) ha producido un cuerpo de trabajo enorme. Lo primero es honrarlo.
Qué es
El Estado 1 es el design system que inventa la disciplina. Una colección estructurada de decisiones de diseño (tokens, componentes, patrones, guidelines, voz, accesibilidad) empaquetada de forma que varios equipos puedan usarla sin tener que redescubrirla. Lenguaje común. Economía cognitiva. Consistencia como valor de producto.
Sus piezas canónicas son conocidas:
- Tokens: variables de color, espacio, tipografía, radios, sombras, duraciones. Primero como JSON, después como Style Dictionary, hoy como Design Tokens Community Group (DTCG) format 2025.10.
- Componentes: Button, Input, Card, Modal, Dialog, Toast, DataTable. Implementados una vez, documentados con props estables, versionados.
- Documentación: Storybook o similar. Prosa editorial para el diseñador y el frontend. Ejemplos canónicos por componente.
- Contribución: RFCs, design reviews, versioning semántico, changelog.
- Governance: por convención humana. Pull requests, revisiones, aprobación manual. Basada en confianza dentro del equipo.
Qué hace bien
El Estado 1 resolvió problemas reales. Antes del design system, cada producto reinventaba el botón. Cada equipo discutía el mismo espaciado cuarenta veces al año. El rediseño de marca se convertía en un proyecto de dos años. El Estado 1 llevó esos costes a cerca de cero dentro de la organización que lo adopta bien.
También introdujo un principio editorial que no existía: el design system como producto interno con sus propios usuarios. Los diseñadores y frontend devs son los clientes del design system. Eso cambia cómo se construye, con roadmap, con research, con métricas de adopción, y distingue a los sistemas que funcionan de los que se convierten en zombi tras seis meses.
Dónde se queda corto
El Estado 1 asume un consumidor humano. Todo en él (los nombres, la
documentación, los ejemplos, la resolución de ambigüedades) está pensado
para que una persona con contexto complete lo no dicho. Un diseñador sabe
que button.primary significa “acción principal de la vista” aunque no
esté escrito. Un frontend sabe que space.4 es “ni tan pequeño como un
inset interno, ni tan grande como una separación de sección” aunque nadie
lo haya codificado.
Un agente LLM no sabe eso. O peor: lo infiere, y a veces infiere
correctamente, y otras veces infiere un variant="destructive-outline"
que no existe. La documentación implícita que hace viable el Estado 1 para
humanos es lo que lo vuelve frágil frente a máquinas.
La trampa del dark mode
Hay un síntoma reconocible. Muchos design systems pensaron que dark mode se resolvería duplicando paletas. Fue la primera gran señal de que las abstracciones no estaban suficientemente estratificadas: primitive, semantic, component. Quien tuvo esa jerarquía clara, añadió dark mode en semanas. Quien no, sigue peleando con ella en 2026.
Ese mismo patrón se repite ahora con los agentes. Quien tenga tokens canónicos, schemas estrictos, contract tests y documentación estructurada pasará al Estado 2 en meses. Quien no, dedicará trimestres a desenredar el ovillo primero.
La decomposición del sistema
El Método Mendeléyev desmonta el design system en seis capas nombradas. Cada una tiene su contrato y su dominio de variación. El Estado 1 bien ejecutado ya trabaja sobre cinco de ellas; lo que le falta al Estado 1 para pasar al Estado 2 no son capas nuevas, sino que las existentes se vuelvan auditables por máquina.
- Átomo = token primitivo (
color.red.500,space.4,duration.120). Valor sin intención. - Compuesto = token semántico (
color.action.primary,space.input.y). Primitivo más intención editorial. - Regla = convención humana en el Estado 1 (pull request, code review, design review). En el Estado 2 se vuelve contract test + OPA policy + schema.
- Pieza = componente con props estables (
<Button variant='primary'>). - Familia = conjunto de piezas emparentadas (Inputs, Feedback, Overlays).
- Estado = comportamiento temporal (hover, focus, loading, disabled).
Lo que falta al Estado 1 es la catalogación exhaustiva: que cada capa esté nombrada y auditable. Storybook cubre la pieza. Los tokens cubren átomo y compuesto. La familia vive en la documentación. La regla vive en la convención humana, no en código. El estado se testea desigualmente. La exhaustividad es lo que separa un Estado 1 maduro de uno frágil.
Qué hacer si estás en el Estado 1
Lo mejor: quedarte ahí bien. No saltes al Estado 2 porque sí. Antes de exponer un sistema a agentes, verifica:
- Estratificación real: ¿tienes primitive / semantic / component separados, o todo es una colección plana de variables CSS?
- Cobertura de documentación: ¿cada componente tiene ejemplos canónicos, estados cubiertos, constraints de uso?
- Contract testing: ¿tus tests fallan cuando un prop cambia? ¿O solo cuando el screenshot cambia?
- Telemetría básica: ¿sabes qué componentes se usan y cuáles no?
- Nomenclatura consistente: ¿un agente que lea tus nombres puede inferir intención, o necesita leer docs?
Si estos cinco puntos están sólidos, el Estado 2 es un salto de semanas. Si no, son años.
Draft 1 · Mayo 2026 · Continúa en Estado 2 · Agéntico