Tokens de diseño organizados en capas global, alias y componente para cada sistema que entregamos. Un cambio de color se propaga a todo el sistema en segundos, sin tocar un solo componente a mano.
Global · alias · comp.Style Dictionary
S · 08 / Sistemas de Diseño / Tokens · Componentes · Documentación viva
Un sistema que habla el mismo idioma en todos tus equipos.
Tokens, librería de componentes en Figma y código, guía de estilo y documentación viva en Storybook. Para negocios con varios equipos o productos que necesitan crecer sin romper la coherencia de marca: ni componentes dispersos en cinco repos, ni guías de estilo que nadie actualiza. Tratamos cada sistema de diseño como infraestructura viva: versionada, documentada, adoptada y mantenida desde el primer sprint.
M · 01
Manifiesto
Por qué este proyecto es distinto
Un sistema de diseño no es una Notion con colores en hex. Es infraestructura de producto — tokens con nombre y propósito, componentes funcionales en Figma y en código, documentación viva que cualquier diseñador o ingeniero puede usar mañana — y tratamos cada sistema exactamente así, desde el primer token hasta que tu equipo lo adopta sin fricción, trabajes con nosotros los próximos tres proyectos o no.
R · 02aRechazos
Seis cosas que rechazamos
Seis cosas que rechazamos
entregar — por principio.
- No · 01 Guías de estilo sin componentes funcionales Un PDF con colores y tipografías no es un sistema de diseño. Sin librería de componentes operativa en Figma y en código, es un documento que caduca en dos sprints.
- No · 02 Tokens sin nombre ni propósito semántico No nombramos variables por valor: no #0A84FF, sino color.action.primary. Un token sin propósito semántico no escala y obliga a buscar y reemplazar cada vez que cambia la marca.
- No · 03 Componentes desconectados de Figma y código Si el componente en Figma no refleja el componente real en producción, el sistema es una ficción. Nuestra entrega mantiene la sincronía entre diseño y código desde el primer día.
- No · 04 Documentación que nadie actualiza La documentación vive en Storybook, junto al código. No en Confluence, no en Notion, no en un PDF. Si cambia el componente, cambia la doc en el mismo PR. Sin fricción de sincronía.
- No · 05 Sistemas sin proceso de gobernanza Un sistema sin proceso de contribución y revisión se fragmenta en semanas. Entregamos el sistema y el proceso: quién puede añadir componentes, cómo se proponen, cómo se aprueban.
- No · 06 Accesibilidad como revisión final WCAG 2.2 AA no es una capa que se añade al final. Cada componente se diseña y construye accesible desde el primer token: contraste, navegación por teclado, roles ARIA correctos.
N · 02bEn cifras
Las cifras que un VP de producto
Las cifras que un VP de producto
pide en la semana uno.
Medianas de nuestras plataformas activas, refrescadas cada trimestre y firmadas por el responsable del proyecto. Nada de folletos comerciales: medido en producción real, sobre tráfico real, en los mismos dashboards de Datadog y Grafana que tu equipo puede abrir ahora mismo.
Librería de componentes atómicos en Figma y código, con todas las variantes, estados y propiedades documentadas. Accesibles por construcción: cada componente supera WCAG 2.2 AA antes de salir del sprint.
Figma + códigoWCAG 2.2 AATiempo medio desde la entrega hasta adopción completa del sistema por todos los equipos. El onboarding incluye sesiones prácticas, documentación viva y un período de acompañamiento en contexto real.
Adopción · realFormación incluidaUn solo sistema de diseño puede dar soporte a hasta ocho marcas o productos distintos mediante capas de tema. Un componente Button, ocho identidades visuales, cero código duplicado entre marcas.
Theming · multimarcaSin duplicar códigoCoherencia visual garantizada entre todos los productos que usan el sistema. Los tests de regresión visual con Chromatic detectan desvíos visuales en cada PR antes de que lleguen a producción.
Chromatic · PRRegresión visualLos equipos que trabajan con un sistema de diseño maduro construyen nuevas pantallas tres veces más rápido que sin él. El tiempo que antes se gastaba en decisiones de diseño repetidas ahora va a producto nuevo.
Dev velocityMenos decisionesDocumentación en Storybook junto al código, no en un PDF separado. Cada componente tiene sus props documentadas, ejemplos interactivos y guías de uso editorial. Si cambia el componente, cambia la doc en el mismo PR.
Storybook · inlineSiempre actualizadaSistema completo entregado en dieciséis semanas para un producto de alcance medio: tokens, sesenta componentes, Storybook y documentación editorial. Los primeros componentes llegan antes de la semana cuatro.
Comps. · semana 4Entrega completa
P · 02Enfoque
Cuatro principios
Cuatro principios
antes de diseñar un solo token.
Cada sistema de diseño que entregamos descansa sobre los mismos cuatro principios. No los cambiamos por proyecto: son la razón por la que los equipos de diseño e ingeniería adoptan el sistema en semanas y por la que la coherencia de marca se mantiene incluso cuando el equipo crece. Tokens primero. Código y Figma sincronizados. Documentación viva.
Pilar · 01
Tokens primero, componentes después.
Todo empieza por la arquitectura de tokens: colores semánticos, escala tipográfica, espaciado, bordes, elevación y movimiento. Con los tokens bien definidos, cada componente que viene después es coherente por construcción. Sin tokens bien nombrados, cualquier cambio de marca requiere tocar cientos de archivos a mano.
Pilar · 02
Figma y código siempre sincronizados.
El componente en Figma y el componente en código deben ser el mismo objeto, no dos artefactos que se intentan parecer. Usamos Tokens Studio + Style Dictionary para que los cambios en Figma se propaguen al código de forma controlada. Si el diseñador actualiza un color de marca, el desarrollador no necesita buscarlo: ya está en el token correcto.
Pilar · 03
Documentación viva que acompaña al código.
La documentación que no vive junto al código caduca. Construimos la documentación en Storybook, con ejemplos interactivos, props documentadas y guías de uso editorial por componente. Cuando cambia el componente, cambia la doc en el mismo PR. El equipo nunca trabaja con información desactualizada.
Pilar · 04
Gobernanza que escala con el equipo.
Un sistema sin proceso de contribución se convierte en un monorepo de componentes sin dueño. Definimos y entregamos el proceso completo: quién puede proponer nuevos componentes, cómo se revisan, cómo se aprueban y cómo se deprecan. El sistema crece de forma controlada, no se fragmenta cuando se incorporan nuevos diseñadores o equipos de producto.
I · 04Incluido
Seis entregables, de serie.
Seis entregables, de serie.
No módulos vendidos aparte.
Los mismos seis entregables viajan con cada sistema de diseño, dimensionados según el alcance del producto y el número de equipos. Sin tiers opcionales, sin módulos de upsell, sin sorpresas. Pasa el cursor sobre cualquier tarjeta para ver exactamente qué te llevas el día de la entrega.
L · 01 / 06
Arquitectura de
tokens.
Auditoría de marca, definición de la jerarquía de tokens en tres capas (global, alias, componente), nombrado semántico y exportación a cualquier plataforma mediante Style Dictionary. La base que hace que todo lo demás sea coherente por construcción.
L · 02 / 06
Librería de
componentes.
Sesenta o más componentes atómicos en Figma y en código React, con todas sus variantes, estados y propiedades documentadas. Accesibles por defecto, conectados a los tokens y con tests de regresión visual en Chromatic por cada PR.
L · 03 / 06
Guía de estilo
editorial.
Paleta semántica, escala tipográfica, sistema de espaciado, iconografía, fotografía y principios de voz y tono. Todo documentado con ejemplos de uso correcto e incorrecto, para que cualquier persona del equipo tome decisiones coherentes sin consultarte.
L · 04 / 06
Documentación
viva.
Storybook completo con ejemplos interactivos, playground de props, guías de uso y notas de accesibilidad por componente. Vive junto al código: si cambia el componente, cambia la doc en el mismo PR. Nunca desactualizada.
L · 05 / 06
Gobernanza y
proceso.
El proceso completo para que el sistema crezca de forma controlada: quién puede proponer nuevos componentes, cómo se revisan, cómo se aprueban y cómo se deprecan. Sin proceso, el sistema se fragmenta en semanas cuando llegan nuevos equipos.
L · 06 / 06
Formación y
adopción.
Un sistema que el equipo no sabe usar se abandona en tres meses. Incluimos sesiones de onboarding para diseñadores e ingenieros, acompañamiento durante el período de adopción y recursos de consulta rápida para el día a día.
05Método
Un proceso de cuatro fases,
ajustado en cada proyecto
hasta que el sistema funciona de verdad.
Cada sistema de diseño sigue las mismas cuatro fases: una auditoría que inventaría lo que ya existe, una fase de diseño que construye la arquitectura de tokens y los primeros componentes, una fase de construcción que completa la librería con demos quincenales y una fase de adopción que forma al equipo y asegura que el sistema se usa. Sin improvisación, sin sorpresas, con entregables concretos en cada fase—para que diseñadores, ingenieros y dirección sepan en todo momento dónde está el proyecto.
01
Fase 01 / Semana 1–2
Auditoría.
Saber qué tienes antes de construir.
Antes de diseñar el primer token auditamos lo que ya existe: identidad visual, componentes dispersos, inconsistencias entre productos y flujos de trabajo del equipo de diseño e ingeniería. La mayor parte de lo que una empresa cree que es su guía de estilo no está siendo usada por nadie. Sin esta fase, construimos sobre un diagnóstico equivocado.
- Inventario de identidad visual. Colores, tipografías, iconografía, espaciado—documentados tal como existen en producción hoy.
- Auditoría de componentes. Componentes existentes en diseño y código, inconsistencias entre ellos, grado de reutilización real.
- Análisis de flujo de trabajo. Cómo trabajan diseño e ingeniería juntos hoy, dónde está la fricción, qué falta en el proceso.
- Revisión de accesibilidad. Estado actual de contraste, navegación por teclado y roles ARIA en los productos existentes.
- Alcance y priorización. Qué componentes construir primero, qué migrar de lo existente y qué deprecar—con criterio de impacto.
Entregable 01
Informe de auditoría + plan de sistema
- Inventario completo de identidad visual + componentes existentes
- Mapa de inconsistencias entre diseño y código
- Análisis de flujo de trabajo actual con puntos de fricción
- Propuesta de alcance del sistema: componentes, tokens, fases
- Priorización de componentes por impacto en equipo
Formato PDF + Figma + Notion
Sign-off Head of Design / CTO
“La auditoría inicial reveló que teníamos doce versiones del mismo botón repartidas entre cuatro repos. Sin saberlo, eso era imposible de arreglar.”— Head of Design, SaaS B2B multiproducto
02
Fase 02 / Semana 3–5
Diseño.
Tokens y Figma antes del primer componente.
La arquitectura de tokens es donde las decisiones de marca se vuelven código. Definimos la jerarquía completa de tokens en Figma Variables y Tokens Studio, establecemos el nombrado semántico, configuramos Style Dictionary para la exportación y diseñamos los primeros componentes atómicos. Sin esta base bien construida, cada componente que viene después lleva su propia regla de estilo desconectada.
- Arquitectura de tokens en tres capas. Global (valores primitivos), alias (roles semánticos), componente (usos específicos).
- Figma Variables + Tokens Studio. Sincronización bidireccional entre las decisiones de diseño en Figma y la fuente de verdad en JSON.
- Temas y dark mode. Configuración de capas de tema por marca o producto, y dark mode automático desde los tokens alias.
- Primeros componentes atómicos en Figma. Botones, inputs, tipografía, colores—con todas las variantes y propiedades.
- Style Dictionary configurado. Pipeline de exportación a CSS Custom Properties, iOS, Android y cualquier plataforma que necesites.
Entregable 02
Arquitectura de tokens + primeros componentes
- 200+ tokens en Figma Variables y formato JSON W3C DTCG
- Style Dictionary configurado con exportación a CSS + plataformas nativas
- Temas de marca y dark mode listos desde tokens alias
- Primeros 10–15 componentes atómicos en Figma con variantes completas
- Guía de nombrado semántico para el equipo
- Repositorio base configurado con pipeline de sincronización
Formato Figma + JSON + repo
Sign-off Head of Design
“Cuando vimos los tokens bien nombrados por primera vez entendimos por qué los cambios de marca nos costaban semanas. En el sistema nuevo tardamos dos horas.”— Director de Producto, startup B2C multimarca
03
Fase 03 / Semana 6–14
Construcción.
Librería completa + Storybook.
Con los tokens y los primeros componentes aprobados, construimos la librería completa: los sesenta o más componentes que cubre el alcance acordado, cada uno con sus variantes en Figma, su implementación en código, su test de regresión visual y su documentación en Storybook. Los primeros componentes llegan antes de la semana cuatro. Sin semanas de caja negra.
- Componentes en sprints de dos semanas. Cada sprint entrega un grupo de componentes completos: Figma, código, tests y docs en el mismo PR.
- Regresión visual con Chromatic. Cada PR lanza tests de regresión visual automáticos. Un cambio visual no aprobado bloquea el merge.
- Storybook incremental. Cada componente entregado tiene su story, sus controls y su documentación de accesibilidad lista para el equipo.
- Accesibilidad WCAG 2.2 AA por componente. Contraste, navegación por teclado, roles ARIA y etiquetas—verificados antes de cerrar el sprint.
- Revisión quincenal con el equipo. Demo de los componentes entregados, feedback recogido en el mismo sprint, sin acumulación de deuda.
Entregable 03
Librería completa + Storybook desplegado
- 60+ componentes en Figma con variantes, auto-layout y properties
- 60+ componentes en React accesibles, conectados a tokens
- Storybook con playground de props y docs por componente
- Tests de regresión visual en Chromatic configurados por PR
- WCAG 2.2 AA verificado en cada componente de la librería
Cadencia Demos quincenales
Visibilidad Storybook público
“A la semana seis ya teníamos treinta componentes funcionando en producción y el equipo de diseño usándolos directamente desde Figma.”— CTO, plataforma e-commerce multimarca
04
Fase 04 / Continuo
Adopción.
Formación y acompañamiento real.
Entregar el sistema no es suficiente. Un sistema que el equipo no sabe usar se abandona en tres meses. La fase de adopción asegura que diseñadores e ingenieros entienden el sistema, saben contribuir a él y tienen los recursos para resolver dudas en el día a día. Es la fase que más impacto tiene en si el sistema sigue vivo en dos años.
- Onboarding para diseñadores. Figma, tokens, componentes y proceso de contribución—en una sesión práctica con el equipo real.
- Onboarding para ingenieros. Instalación, uso en proyectos reales, cómo contribuir nuevos componentes y proceso de revisión.
- Cuatro semanas de acompañamiento. Canal de preguntas dedicado, revisión de las primeras implementaciones del equipo en contexto real.
- Guías de referencia rápida. Recursos para el día a día: cuándo usar cada componente, cómo reportar un problema, cómo proponer uno nuevo.
- Revisión a los 90 días. Sesión de retroalimentación con el equipo para ajustar tokens, componentes o proceso que no encajen con su flujo real.
Entregable 04
Sistema adoptado + equipo autónomo
- Sesión de onboarding para diseñadores (Figma + proceso)
- Sesión de onboarding para ingenieros (instalación + contribución)
- Cuatro semanas de acompañamiento con canal dedicado
- Guías de referencia rápida para el día a día
- Revisión a los 90 días con ajustes incluidos
Plazo Incluido en el proyecto
Resultado Equipo autónomo
“A los dos meses el equipo de diseño estaba proponiendo nuevos componentes al sistema sin necesitar ayuda. Eso no pasa sin formación real.”— Head of Product, aplicación B2B con tres equipos
01/ 04
Método00%
06Cambios
Lo que cambia en tu equipo
con un sistema de diseño real.
Estos son los cambios que documentamos en los equipos que trabajan con sistemas de diseño maduros. No promesas de agencia: consecuencias directas de tener una fuente de verdad compartida entre diseño e ingeniería.
Sin sistema (baseline)
Con sistema (6 meses)
Basado en proyectos propios
Velocidad de entrega+3×
0123456701
% más rápido
Sin sistema
3 días
Con sistema
1 día
Tiempo medio para construir una pantalla nueva. Con un sistema maduro el equipo no toma decisiones de diseño repetidas: elige componentes y los compone.
Inconsistencias visuales−80 %
0123456780
% menos bugs visual
Sin sistema
40 bugs/mes
Con sistema
8 bugs/mes
Bugs visuales reportados por QA al mes. Los tests de regresión visual con Chromatic detectan desvíos antes de que lleguen a producción.
Componentes reutilizados42 %
012340123456789
% reutilización media
Sin sistema
8%
Con sistema
42%
Porcentaje de componentes reutilizados sobre el total de elementos en una pantalla nueva. Menos código escrito, menos código a mantener.
Adopción del sistema+99 %
01234567890123456789
% uso en producción
Sin sistema
0%
Con sistema
90+%
Porcentaje de pantallas nuevas construidas usando componentes del sistema. El acompañamiento y la formación son clave para llegar a este nivel.
Tiempo de cambio de marca−44 h
0123401234
horas vs semanas
Sin sistema
4 sem
Con sistema
2 h
Tiempo para propagar un cambio de color de marca a todos los productos. Con tokens bien definidos, un cambio en el token correcto se propaga automáticamente.
Revisiones de diseño−11 ×
0101
ciclos de review
Sin sistema
7 ciclos
Con sistema
1–2 ciclos
Ciclos de revisión por pantalla nueva. Con un sistema maduro las revisiones son sobre decisiones de producto, no sobre si el color del botón es correcto.
Fuente Proyectos Enjoy.Website, 2022–2026
Basado en datos reales de equipos
Contexto Disponible bajo petición
Metodología completa Disponible bajo petición
07Stack
Las herramientas que usamos
para construir tu sistema.
No tenemos lealtad de herramienta. Elegimos las que tienen mejor track record en sistemas de diseño maduros: estables, bien documentadas y adoptadas por los equipos que ya conoces. Cada herramienta de abajo está en uso activo en los sistemas que entregamos.
Diseño
Figma como fuente de verdad visual. Variables nativas sincronizadas con Tokens Studio para exportar a cualquier plataforma de forma automática y controlada.
Tokens y build
Style Dictionary transforma los tokens JSON en CSS Custom Properties, variables iOS, recursos Android y cualquier formato que necesite tu stack.
Componentes y docs
React o Web Components con Radix UI como base accesible. Storybook como documentación viva con Chromatic para regresión visual automática.
Proceso y calidad
GitHub Actions, ESLint, Prettier, tests Playwright y Axe Core en CI. Changesets para el versionado semántico y changelog por componente.
08Trabajo seleccionado
Dos sistemas,
ambos bajo NDA.
Casi todo el trabajo que hacemos va bajo acuerdo de confidencialidad. Lo que sí podemos compartir es la forma del proyecto—sector, alcance, resultado—y las referencias que los equipos de producto o diseño pueden solicitar en privado. Los dossiers completos se entregan en menos de 72 horas tras firmar un NDA mutuo.
Caso 01 / Bajo NDA
De doce versiones del mismo botón
a un sistema que los tres productos comparten.
Una empresa SaaS con tres productos distintos desarrollados por equipos separados. Cada producto tenía su propio Figma, sus propios componentes y sus propias reglas de color. El resultado: inconsistencia visible para los usuarios, decisiones de diseño repetidas tres veces y ningún equipo capaz de lanzar pantallas nuevas sin semanas de debate. Construimos un sistema de diseño con arquitectura de tokens en tres capas, 72 componentes en Figma y React, Storybook con documentación completa y un proceso de gobernanza que los tres equipos adoptaron en seis semanas. El tiempo para construir una pantalla nueva bajó de doce días a cuatro.
3×Aumento de velocidad en construcción de pantallas nuevas · 90 días tras la entrega
SaaS B2B multiproducto · 3 equipos
Un sistema, tres productos, cero código duplicado.
- Tiempo por pantalla nueva: 12 días → 4 días
- Inconsistencias visuales/mes: 40 → 6
- Componentes reutilizados: 8% → 48%
- Cambio de color de marca: 4 semanas → 2 horas
- Adopción del sistema: 90%+ a los 3 meses
Caso 02 / Bajo NDA
Ocho marcas, un solo sistema
y cero código duplicado entre ellas.
Un grupo retail con ocho marcas distintas, cada una con su propio frontend y sus propios componentes. Mantenían el mismo botón en ocho repos distintos: cuando cambiaba el radio o el color, alguien tenía que actualizar los ocho. Construimos un sistema de diseño con Web Components agnósticos al framework, capas de tema multimarca desde tokens alias y Storybook con las ocho variantes documentadas. Un cambio de color de marca ahora tarda dos horas, no cuatro semanas.
8×Marcas cubiertas por un solo sistema de diseño sin duplicar código entre ellas
Retail multimarca · 8 marcas
Ocho marcas, un sistema, cero duplicación.
- Cambio de color de marca: 4 semanas → 2 horas
- Repos de componentes: 8 repos → 1 sistema
- Revisiones de diseño por pantalla: 7 → 1–2
- Cobertura de accesibilidad: WCAG 2.2 AA, 100%
- Adopción a 3 meses: 88% de pantallas nuevas
11Voces
Lo que nuestros clientes
realmente dicen.
Las referencias identificables se entregan a petición. Las cuatro citas de abajo van anonimizadas a petición del contacto. Las puedes verificar directamente con ellos si llegas a propuesta.
01 / 04
12Modelos de colaboración
Tres formas de
trabajar juntos.
Tres modelos según el alcance del sistema. El precio se calibra contra el número de productos, equipos y componentes—se detalla tras la llamada de descubrimiento. Los precios de Esencial y Completo son orientativos; el de Multimarca va siempre a medida.
Nivel 01
Esencial
Para un producto único que necesita su primer sistema de diseño bien construido: tokens, componentes y documentación viva.
Inversión
desde 4.500 €+ IVA / proyecto
- Entrega en 10–14 semanas. Auditoría, tokens, 40+ componentes, Storybook y formación.
- Arquitectura de tokens completa. Global, alias y componente, sincronizados con Figma.
- 40+ componentes en Figma y código. Accesibles por defecto, con tests de regresión visual.
- Storybook desplegado. Documentación viva con playground de props por componente.
- Formación y acompañamiento. Sesiones de onboarding + 4 semanas de soporte post-entrega.
Ideal para: un producto, un equipo de diseño e ingeniería, primer sistema de diseño.
Nivel 02
Profesional
Para negocios con varios productos o equipos que necesitan un sistema que escale sin perder coherencia.
Inversión
desde 9.500 €+ IVA / proyecto
- Entrega en 14–18 semanas. Tokens avanzados, 60+ componentes, theming y gobernanza completa.
- Tokens con soporte a múltiples temas. Dark mode, theming por producto, tokens alias bien estructurados.
- 60+ componentes en Figma y código. Variantes completas, props documentadas, tests de regresión visual con Chromatic.
- Proceso de gobernanza formalizado. Guía de contribución, RFC de componente, flujo de revisión y deprecación.
- CI/CD del sistema integrado. Style Dictionary en pipeline, Chromatic en PR, versionado semántico con Changesets.
- Formación avanzada. Sesiones para diseñadores e ingenieros + soporte Slack 8 semanas post-entrega.
- Revisión a los 90 días. Auditoría de adopción, ajuste de tokens y nuevos componentes si hace falta.
Ideal para: multiproducto · varios equipos de diseño e ingeniería · necesidad de dark mode o theming.
Nivel 03
Corporativo
Para grupos con varias marcas o una escala de componentes que requiere arquitectura a medida y soporte continuo.
Inversión
Propuesta a medidatras descubrimiento
- Arquitectura multimarca desde cero. Un sistema con theming profundo para cada marca del grupo.
- Web Components o React según tu stack. Interoperabilidad entre frameworks, sin vendor lock-in.
- 100+ componentes documentados. Con variantes de marca, Chromatic en CI y WCAG 2.2 AA garantizado.
- Modelo de gobernanza a medida. RFC, comité de revisión, proceso de deprecación y changelog semántico.
- Monorepo y CI/CD completo. Turborepo o Lerna, Changesets automáticos, publicación en npm privado.
- Soporte de mantenimiento continuo. Revisiones periódicas, ampliación del sistema y evolución de marca.
- Formación para toda la organización. Onboarding por equipos, guías de referencia y revisión anual.
Ideal para: multimarca · grupos con varias líneas de producto · escala de sistema que crece con la organización.
Módulos que puedes añadir sobre cualquier nivel.
Los add-ons se contratan como proyectos a precio cerrado y tiempo acotado. Cada uno se entrega con su propio entregable y criterio de éxito—útiles de forma independiente, diseñados para encajar con el sistema base.
Dark mode completoArquitectura de tokens semánticos para dark mode real, sin hard-coded colors ni inversión de imagen.+ 4 semanas
Theming multimarcaExtensión del sistema base para cubrir 2-5 marcas adicionales con tokens alias y Figma Branching.+ 6 semanas / marca
Auditoría de accesibilidadAuditoría WCAG 2.2 AA por componente, correcciones, tests con Axe Core y declaración de conformidad.+ 4 semanas
Migración de componentes legacyInventario, refactor y adopción progresiva del sistema en código existente sin romper producción.+ 8 semanas
Storybook avanzadoPlayground de props completo, historias por variante, MDX docs, Chromatic en CI y design tokens integrados.+ 3 semanas
Zeroheight o documentación estáticaPortal de documentación del sistema con búsqueda, changelog y guías de uso para equipos externos.+ 3 semanas
Formación intensivaWorkshop de 2 días presencial o remoto para diseñadores e ingenieros sobre el sistema entregado.+ 2 semanas
Web ComponentsPublicación de la librería como Web Components estándar para compatibilidad con cualquier framework.+ 6 semanas
Revisión y evolución continuaRetainer mensual para nuevos componentes, ajustes de tokens y revisión de adopción a medida que crece el equipo.+ continuo
13Documentos
Seis documentos
que tu equipo conserva.
Cada proyecto deja atrás un set de documentos ejecutables, auditados y documentados. Son tuyos—cedidos en el contrato—y son lo que hace que el año dos salga más barato que el año uno.
Documento 01Diseño
Librería de componentes en Figma
Librería Figma publicada con Figma Variables, variantes completas por estado, documentación de uso en cada componente y tokens sincronizados con Style Dictionary. Actualizada en cada release.
Documento 02Código
Storybook y documentación viva
Storybook desplegado con historias por variante, playground de props, notas de accesibilidad y Chromatic integrado en CI para detectar regresiones visuales antes de mergear.
Documento 03Tokens
Arquitectura de tokens
Tokens en tres capas (global, alias, componente) exportados con Style Dictionary a CSS Custom Properties, JSON y Figma Variables. Con soporte a dark mode y theming desde el primer día.
Documento 04Proceso
Guía de gobernanza
Guía de contribución al sistema, plantilla de RFC de componente, proceso de revisión, política de deprecación y flujo de versionado semántico. Para que el sistema crezca sin caer en el caos.
Documento 05Identidad
Guía de estilo editorial
Paleta semántica con nombres de propósito, tipografía con escala modular, espaciado, iconografía, fotografía, voz y tono. El manual que diseñadores nuevos leen el primer día.
Documento 06Ingeniería
Librería de componentes en código
Paquete npm publicado con los componentes en React o Web Components, con TypeScript, Changesets para versionado semántico automático, Chromatic en CI y tests de accesibilidad con Axe Core—tuyo desde el primer commit.
14FAQ
Ocho preguntas
que hace tu equipo antes de empezar.
Las preguntas que escuchamos en cada discovery, contestadas sin paños calientes. Si tienes una novena, mándala—la incluiremos en la próxima revisión.
Una guía de estilo es un documento estático: colores en hex, tipografías, normas de uso. Útil para comunicar marca, pero no para construir producto. Un sistema de diseño es infraestructura viva: tokens con nombre y propósito semántico, componentes funcionales tanto en Figma como en código, y documentación que se mantiene en sintonía con lo que está en producción.
La diferencia práctica: con una guía de estilo, cada diseñador e ingeniero toma decisiones propias en el vacío. Con un sistema, esas decisiones están tomadas una vez y son accesibles para todos. El sistema reduce la fricción entre diseño y desarrollo, garantiza coherencia visual y acelera la construcción de nuevas pantallas porque los bloques ya existen.
- Guía de estilo: referencia pasiva, se desactualiza sola
- Sistema de diseño: infraestructura activa, evoluciona con el producto
- Tokens + componentes + documentación viva = el tríptico completo
Entregable claveTokens + Storybook + Figma
SincroníaFigma y código siempre alineados
PropiedadTuya desde el primer commit
Tú, desde el primer commit. Todo lo que construimos vive en tu repositorio, bajo tu cuenta de GitHub o GitLab, con tu propia organización de npm si publicas los paquetes. No hay lock-in de proveedor ni dependencia de ninguna plataforma propietaria nuestra.
La librería de Figma también es tuya: la publicamos en tu cuenta de organización de Figma, no en la nuestra. Los tokens en JSON, los archivos de Style Dictionary y toda la configuración de build también quedan en tu repo desde el principio. Si el proyecto termina mañana, el sistema sigue funcionando sin nosotros.
- Repositorio en tu cuenta: GitHub, GitLab o Bitbucket
- Librería Figma publicada en tu organización
- Paquetes npm en tu scope (@tuempresa/design-tokens)
- Sin dependencia de herramientas propietarias nuestras
PropiedadTuya desde el día 1
RepositorioTu cuenta, tu organización
Lock-inCero
Un sistema Esencial (un producto, 40+ componentes) tarda entre 10 y 14 semanas. Un sistema Profesional (multiproducto, 60+ componentes, dark mode) tarda entre 14 y 18 semanas. Para sistemas Corporativos (multimarca, Web Components, monorepo) el plazo se calibra en la discovery: normalmente entre 16 y 24 semanas.
En todos los casos, no esperamos a la semana 14 para enseñarte algo. Compartimos demos quincenales con componentes reales desde la semana 6. El proceso está dividido en cuatro fases: Auditoría, Diseño, Construcción y Adopción—cada una con entregables concretos y criterios de aceptación.
- Esencial: 10-14 semanas · 40+ componentes
- Profesional: 14-18 semanas · 60+ componentes · dark mode
- Corporativo: 16-24 semanas · multimarca · monorepo
- Demos quincenales desde la semana 6
Fase de auditoríaSemanas 1-2
Primera demoSemana 6
Adopción4 semanas post-entrega
Sí, y es la situación más habitual. En la fase de Auditoría inventariamos todo lo que ya existe: componentes, estilos, variables, patrones de uso. Lo que merece conservarse se refactoriza para seguir la arquitectura del sistema; lo que está roto o duplicado se consolida.
No empezamos desde cero cuando no hace falta. Si ya tienes un Button, un Input o un Modal que funciona bien, lo adoptamos, lo documentamos y le añadimos los tokens semánticos y las variantes que le falten. El resultado es un sistema coherente sin tirar el trabajo hecho.
- Inventario completo en las primeras dos semanas
- Decisión componente a componente: refactorizar, adoptar o reescribir
- Sin borrar trabajo válido sin motivo
- Compatibilidad con tu stack actual: React, Vue, Angular, Web Components
Fase de auditoríaSemanas 1-2
EnfoqueEvolutivo, no disruptivo
StackReact · Vue · Angular · Web Components
Esa es precisamente la ventaja de construir con tokens semánticos. Si cambias el color primario de tu marca, actualizas un token y el cambio se propaga a todos los componentes en Figma y en código de forma automática mediante Style Dictionary. Sin ir componente por componente, sin versiones inconsistentes entre equipos.
Para cambios más profundos (nueva tipografía, nuevo sistema de espaciado, rebranding completo), la gobernanza del sistema define un proceso: propuesta de RFC, revisión del equipo de diseño e ingeniería, rama de Figma Branching para prototipar el cambio antes de mergear y Changesets para publicar la nueva versión con breaking changes bien documentados.
- Cambio de color o tipografía: un token, propagación automática
- Cambios estructurales: RFC + Figma Branching + revisión
- Versionado semántico con Changesets en cada release
- Changelog público accesible desde Storybook
PropagaciónAutomática vía Style Dictionary
VersionadoSemver · Changesets
PrevisualizaciónFigma Branching
Sí. El sistema se adapta a lo que ya usáis. Si trabajáis con React, construimos la librería en React con TypeScript. Si el producto usa múltiples frameworks, publicamos los componentes como Web Components estándar, que funcionan en cualquier contexto sin dependencia. Si tenéis un monorepo Turborepo o Lerna, el sistema encaja en él sin imponer estructura.
Los tokens, además, son agnósticos de framework: Style Dictionary los genera como CSS Custom Properties (funciona en cualquier stack), JSON (para consumo programático) y archivos compatibles con Tailwind si lo usáis. En la fase de Auditoría analizamos vuestro stack antes de tomar decisiones de implementación.
- React con TypeScript: opción por defecto
- Web Components: para interoperabilidad entre frameworks
- CSS Custom Properties: tokens agnósticos de stack
- Compatible con Tailwind, Next.js, Astro, Vue, Angular
FrameworksReact · Vue · Angular · Web Components
TokensCSS · JSON · Tailwind
MonorepoTurborepo · Lerna · compatible
Es exactamente el escenario para el que están pensados los sistemas de diseño más maduros. La clave es la arquitectura de tokens: con una capa de tokens alias bien construida, un mismo sistema puede soportar múltiples productos o marcas con paletas, tipografías y estilos distintos sin duplicar ni un solo componente.
En escenarios multiproducto, cada producto tiene su tema de tokens; los componentes son los mismos pero se renderizan con los valores del tema activo. En escenarios multimarca, usamos Figma Branching para gestionar las variantes de marca en Figma y tokens alias para generar builds separados por marca desde el mismo pipeline de Style Dictionary. Hemos construido sistemas para hasta 8 marcas en un solo repositorio.
- Multiproducto: theming por producto con tokens alias
- Multimarca: Figma Branching + builds separados por marca
- Hasta 8 marcas gestionadas en un solo sistema (caso real)
- Un solo repositorio, cero duplicación de componentes
ThemingTokens alias · CSS Custom Props
FigmaFigma Branching por marca
Máximo probado8 marcas · 1 sistema
Sí, y no es opcional: la formación forma parte del proceso de Adopción de todos los niveles. Un sistema que se entrega sin formación tiene adopción cero. Hacemos sesiones de onboarding separadas para diseñadores y para ingenieros, adaptadas al nivel y al contexto de cada equipo.
Los diseñadores aprenden a usar la librería de Figma, los tokens variables, las variantes y el proceso para proponer nuevos componentes. Los ingenieros aprenden a importar la librería, a contribuir siguiendo la guía de contribución y a usar Storybook como fuente de verdad. Además, durante cuatro semanas post-entrega estamos disponibles en Slack para resolver dudas y hacer seguimiento de adopción. En el nivel Profesional, esto se amplía a ocho semanas.
- Sesiones de onboarding para diseñadores: Figma + tokens + variantes
- Sesiones de onboarding para ingenieros: librería + contribución + Storybook
- 4 semanas de acompañamiento post-entrega (8 en Profesional)
- Revisión de adopción a los 90 días incluida
OnboardingDiseño + ingeniería por separado
Soporte post4-8 semanas según nivel
Revisión 90 díasIncluida en todos los niveles
¿Una novena pregunta?
Mándala a partners@enjoy.website con asunto “Design System FAQ”. Respondemos en menos de un día laborable, por escrito, y añadiremos la respuesta a esta página en la próxima revisión.
15Siguiente paso
Un sistema que tu equipo usa de verdad y que crece contigo.
El siguiente paso es una llamada de discovery de 30 minutos. Tú traes el contexto de tu producto y tus equipos; nosotros traemos preguntas concretas y una evaluación honesta de qué nivel de sistema tiene sentido para vosotros. Si no somos el encaje correcto, te lo decimos y te apuntamos a quién lo es.