Cuándo contratar una agencia para el design system (y cuándo esperar)

Contratar una agencia para el design system es antes que nada una decisión de momento. Qué estudio eliges viene después. Lo que decide el resultado es si el producto ya se repite lo suficiente para que el sistema se pague solo: la misma tabla en cuatro pantallas, la misma lógica de formulario en dos codebases, el mismo botón rehecho por quien cogió el ticket.

Esto está escrito para quien firma la factura. Cuatro umbrales dicen ahora. Una lista más corta dice espera seis meses. Aquí van las diferencias y qué meter en el primer alcance cuando la respuesta es sí.

Qué devuelve un design system, y en cuánto tiempo

Hay dos estudios que ponen cifras al ahorro. El equipo de data science de Figma midió un ejercicio controlado: quien tenía un design system a mano cerró el mismo objetivo un 34% más rápido que quien partía de cero. Sparkbox probó el lado de desarrollo con Carbon, de IBM: con ocho desarrolladores, una página con un formulario sencillo costó 2 horas de mediana con el sistema frente a 4,2 horas desde cero, un 47% menos.

Son muestras pequeñas y miden una sola tarea. Léelas como orden de magnitud: un design system recorta alrededor de un tercio del coste de construir interfaz que el sistema ya cubre. Toda la discusión está en esa última frase.

La cuenta sale de la repetición. Coge un equipo que publica ocho pantallas nuevas por trimestre, unos cinco días de diseño y front-end cada una. Son 40 días de interfaz por trimestre, así que un ahorro del 35% devuelve 14. Supón unos cimientos más un primer set de componentes en 30 o 60 días de trabajo. El retorno cae hacia el tercer o cuarto trimestre, y a partir de ahí el sistema sigue pagando. Repite la cuenta con un equipo que publica dos pantallas por trimestre y el retorno llega mucho después de que el producto haya cambiado de forma.

Por qué esperar a que duela sale más caro

La regla por defecto en los equipos de producto es esperar a que la inconsistencia moleste. Para entonces la factura tiene dos líneas. Se paga construir el sistema y se paga migrar todas las superficies que se desviaron mientras tanto. La migración es la mitad cara: toca código ya publicado, compite con la hoja de ruta y exige QA sobre pantallas que nadie pensaba volver a abrir. Cómo se acumula esa deriva lo contamos en component drift.

Moverse pronto también tiene su fallo, y no está en la construcción. Los design systems mueren en la adopción, y la forma más segura de matarla es entregar una librería enorme de componentes que nadie pidió. Netguru describe bien los errores de adopción: se intenta cubrir todos los escenarios en el lanzamiento y los componentes que nunca salieron de una pantalla real se quedan sin usar. Una librería de 60 componentes entregada a un producto de 11 pantallas es una guía de estilo carísima.

Cuando la respuesta no está clara, una auditoría de cinco días da las cifras que hacen falta para decidir, por una fracción de lo que cuesta construir. La checklist que usamos es pública: cómo auditar un design system en 5 días.

Los cuatro umbrales que dicen ahora

1. El mismo componente existe en tres sitios

Cuenta duplicados reales, no previstos. Busca en el código el botón, el campo, el modal, la tabla. Tres o más implementaciones independientes del mismo elemento, o dos superficies que ya se han separado (web y app, consola de administración y producto de cliente), es la señal individual más fuerte. Un design system capitaliza la repetición. Sin repetición no hay nada que amortizar.

2. Más de tres personas tocan la interfaz cada semana

Un diseñador y un desarrollador de front-end mantienen la coherencia de memoria, y lo hacen más rápido que cualquier documentación. Deja de funcionar hacia las tres o cinco personas, o la semana en que entra el primer externo. El ritmo pesa tanto como el número: una release semanal genera en un trimestre más divergencia que una mensual en un año.

3. Alguien se ocupa de él el lunes siguiente a la entrega

Es el umbral que los compradores se saltan y luego lamentan. Leyendo las encuestas anuales de Zeroheight, NN/g apunta que la mayoría de equipos de design system son de 2 a 5 personas, que por encima de 5.000 empleados la media sigue entre 9 y 11, y que rara vez pasan de 20 o 25. Aquí importa más el suelo que el techo: el mantenimiento mínimo son un diseñador y un desarrollador con horas asignadas, no una página de wiki y buena voluntad. Si nadie tiene esas horas, aplaza. Un sistema sin dueño se degrada más rápido que el código que venía a arreglar.

4. Hay una fecha que no se mueve

Un rebranding, una migración de plataforma, una segunda línea de producto, un concurso enterprise o una fecha de accesibilidad. La European Accessibility Act se aplica desde el 28 de junio de 2025 con la directiva (UE) 2019/882, y lo que hoy piden los departamentos de compras (declaración de accesibilidad, pruebas de conformidad) se resuelve una vez en el componente o una y otra vez en cada pantalla. Una fecha fija convierte el design system en una dependencia de entrega, y eso pesa más que las cuentas de arriba.

Tres de cuatro es un sí. Dos abren una conversación sobre alcance. Uno es un no.

Cuándo esperar seis meses

Espera mientras el producto todavía decide qué es. Las señales concretas:

• El flujo principal cambió dos veces el trimestre pasado y el siguiente cambio ya está en el calendario.
• Una superficie, un diseñador, un desarrollador de front-end.
• Menos de 15 pantallas distintas y ningún segundo producto en la hoja de ruta.
• Nadie con nombre y apellidos al cargo tras la entrega.
• Caja por debajo de 12 meses y encaje producto-mercado todavía abierto.

Esperar no es quedarse quieto. La versión barata deja la puerta abierta: define los tokens (color, tipografía, espaciado, radios, elevación) y párate ahí, y mantén un inventario escrito de los componentes según aparecen. Una o dos semanas de trabajo, casi gratis de tirar, y convierte el futuro sistema en una refactorización en lugar de una excavación. El orden para construirlo después está en estructura de un design system.

Qué meter en el primer alcance cuando la respuesta es sí

El primer encargo debe terminar en unos cimientos, no en un catálogo.

• Tokens y temas, con modo oscuro si el producto lo va a necesitar algún día. Meter soporte de temas dentro de valores escritos a mano es el retrabajo más previsible de toda esta categoría.
• De ocho a doce componentes, elegidos contando lo que usan las pantallas actuales y no copiando el índice de una librería. En casi todos los productos ese grupo cubre la mayor parte de la interfaz.
• Una base de accesibilidad dentro de los componentes: estados de foco, contraste, recorridos de teclado, etiquetas. Se arregla una vez y lo hereda todo.
• Una política de versiones y de contribución: quién puede añadir un componente, qué cuenta como cambio incompatible, cómo se anuncia una release. La gobernanza decide si dentro de un año el sistema sigue vivo.
• Documentación pegada al código, no un sitio aparte que nadie actualiza.

El modelo de entrega que aguanta es híbrido. La agencia construye los cimientos a una velocidad que un equipo interno no puede sostener mientras saca producto, y el equipo interno se queda con el crecimiento. Dónde gana cada uno lo tratamos en design system interno o con agencia, y las fórmulas comerciales (proyecto, retainer, copropiedad) en cuánto cuesta un design system.

El mismo producto, dos respuestas opuestas

Coge un producto B2B con app de cliente, consola de administración y web. Tres botones en tres codebases. Dos diseñadores, cuatro desarrolladores de front-end, releases semanales. Hay una segunda línea de producto firmada para el trimestre siguiente y en las operaciones enterprise ya piden declaración de accesibilidad.

Cuatro umbrales de cuatro. La cuenta: unos 45 días de trabajo para cimientos y diez componentes, frente a 14 días por trimestre recuperados en interfaz nueva, más la accesibilidad que si no se repite en cada pantalla. Retorno hacia el tercer trimestre, y la segunda línea de producto arranca sobre el sistema en vez de bifurcar la primera.

Ahora cambia dos variables. Quita la segunda línea de producto y la consola de administración, deja un diseñador y un desarrollador de front-end. Ese mismo equipo debería dedicar dos semanas a tokens e inventario y volver al tema en seis meses. Mismo comprador, misma categoría de producto, respuesta contraria, porque los umbrales se movieron.