ROI de un design system: medirlo como cuenta de resultados

Un design system es una biblioteca compartida de componentes, tokens y reglas de la que tira cada equipo de producto, y su retorno se lee en la cuenta de resultados, no en una presentacion de marca. Como partida de la cuenta, consigue presupuesto en las mismas condiciones que cualquier otra inversion: acorta los plazos de entrega, elimina el trabajo duplicado y baja el coste de la siguiente funcionalidad. Como activo de marketing, compite con las funcionalidades por los fondos y casi siempre pierde.

Esta diferencia decide si tu design system sobrevive al proximo recorte. Los founders, CTOs y responsables de diseno que lo cuentan hablando de coherencia y acabado reciben gestos de aprobacion en la sala y nada en el presupuesto. Quien sigue consiguiendo fondos ata el sistema a numeros que un director financiero ya vigila. Aqui vemos cuales son esos numeros y como medirlos con honestidad.

Por que contarlo como activo de marca hace perder el presupuesto

Casi todos los design systems se presentan sobre la coherencia. Los botones coinciden. Los espaciados cuadran. El producto parece un solo producto en lugar de seis. Todo cierto, y todo facil de dejar sin financiacion, porque la coherencia visual se lee como gusto, y el gusto es lo primero que se corta cuando la hoja de ruta aprieta.

El problema no es que la coherencia no valga. El problema es que ese valor es real pero invisible. Cuando falta un design system, nadie abre una incidencia que diga hemos vuelto a construir el mismo desplegable por cuarta vez este trimestre. El coste aparece como lanzamientos mas lentos, mas ciclos de QA y desarrolladores que reinventan en silencio componentes que ya existen en algun punto del codigo. Es un impuesto que se paga en cien sitios distintos, justo el tipo de coste que un discurso de marketing no sabe capturar.

Llevar el sistema a la cuenta de resultados cambia la pregunta. No queda mejor sino cuanto cambia de lo que gastamos en lanzar. Esa pregunta tiene respuestas con fuentes.

Que mueve de verdad un design system en la cuenta de resultados

Cuatro partidas. Tiempo de desarrollo, tiempo de diseno, coste de defectos y velocidad hacia los ingresos. Cada una se mide, y cada una se mueve en una direccion que un equipo financiero reconoce. Dos estan documentadas lo bastante bien como para llevarlas hoy a una reunion de presupuesto.

Tiempo de desarrollo y de diseno

Es la partida mas grande y mejor documentada. En un estudio controlado de Sparkbox, ocho desarrolladores construyeron dos veces la misma pagina con un formulario, una desde cero y otra con el Carbon Design System de IBM. Con el sistema, el tiempo mediano bajo de 4,2 horas a 2 horas, un 47% menos, incluso contando el tiempo de aprender el sistema (Sparkbox). Los equipos de diseno registran mejoras parecidas o mayores, porque un componente decidido una vez es un componente que ya no se vuelve a discutir.

Un estudio Total Economic Impact de Forrester sobre Dev Mode de Figma, que se situa en el paso del diseno al codigo, midio mas de 90 minutos de ahorro semanal por desarrollador y un aumento de la produccion de entre el 20 y el 30 por ciento (Forrester). Noventa minutos a la semana por desarrollador, en un equipo de veinte, equivalen mas o menos a la capacidad de un desarrollador a tiempo completo devuelta cada semana.

Coste de defectos y retrabajo

Un componente compartido se corrige una vez y la correccion se propaga. Un componente copiado se corrige en todos los sitios donde se pego, o mas a menudo se corrige en unos si y en otros no. Asi es como se multiplican los fallos de accesibilidad y los bugs visuales en el producto. El design system no elimina los defectos, pero cambia su economia: una correccion en lugar de muchas, y menos sitios donde el deterioro pueda esconderse. Menos defectos tambien significa menos lanzamientos de emergencia, y los lanzamientos de emergencia son los mas caros.

Velocidad hacia los ingresos

Construir mas rapido significa lanzar antes, y una funcionalidad que sale en marzo ingresa dos meses mas que la misma funcionalidad en mayo. Esta partida es mas dificil de atribuir con precision, asi que tratala como orientativa y no como exacta. Los modelos de ROI publicados colocan el retorno total muy por encima del punto de equilibrio: un modelo muy citado mostraba una inversion de 646.000 dolares que devolvia cerca de 1,5 millones en tiempo ahorrado, un retorno del 135% (zeroheight). Toma ese numero como una ilustracion del orden de magnitud, no como una promesa. Tu retorno depende de una variable que el modelo da por hecha: la adopcion.

Por que el calculo de ROI mas obvio engana

El calculo estandar multiplica el tiempo ahorrado por pantalla por el numero de pantallas. Es limpio, y es falso en el momento en que tu equipo no usa el sistema de verdad. Un design system que nadie adopta devuelve cero, por muy buenos que sean los componentes.

La adopcion es donde la mayoria de los sistemas fracasan en silencio. La investigacion sobre el tema es tajante: la baja adopcion suele ser un problema de diseno, no de comunicacion, y las ordenes de arriba abajo de usar el sistema rinden menos que un despliegue hecho junto a los equipos (DesignSystems.one). Si el sistema es mas incomodo que copiar un componente que ya existe, los desarrolladores copian. La biblioteca se queda ahi, financiada del todo e ignorada del todo, y el ROI que habias previsto no llega nunca.

Por eso la cuenta de resultados tiene que incluir tambien una partida de coste, no solo una de ahorro. Un design system tiene un coste corriente: mantenimiento, documentacion, versionado y la persona o el equipo que lo cuida. Esconde ese coste y tu ROI parece inventado. Ponlo por escrito y el numero aguanta, que es el unico numero que merece la pena llevar a una reunion de presupuesto.

Como llevar un design system a la cuenta de resultados

Cuatro pasos, ninguno de los cuales necesita un equipo de analitica dedicado.

1. Fija un tiempo de desarrollo de referencia. Antes de la adopcion, o al principio, mide cuanto se tarda en construir una pantalla representativa sin el sistema. Es tu numero de control. Sin el, cada afirmacion posterior es solo una opinion.

2. Mide la adopcion, no solo la existencia. Cuenta la parte de la nueva interfaz que usa componentes del sistema frente a los hechos a medida. La adopcion es el multiplicador de cualquier otro numero, asi que es la metrica que decide si el sistema se paga. Un sistema atrapado en la baja adopcion necesita un plan de rescate antes que mas componentes.

3. Pon el coste corriente en la hoja. Uno o dos desarrolladores de mantenimiento, o una fraccion del tiempo de varias personas, es un numero real. Escribelo. El ROI honesto es el ahorro menos ese coste, y el ROI honesto sobrevive al trimestre siguiente.

4. Atribuye el ahorro a una partida que finanzas ya gestione. Capacidad de desarrollo devuelta, ciclos de QA evitados, tiempo de lanzamiento reducido. Asocia cada ahorro a un centro de coste que ya existe. Un equipo financiero financia lo que ve en sus propias categorias.

Como se traduce en la practica

Toma un equipo de diez desarrolladores y tres disenadores. Supon que el sistema devuelve un prudente 30% del tiempo de desarrollo front-end, por debajo del 47% que midio Sparkbox. Si el trabajo front-end es un tercio del tiempo de desarrollo, eso es mas o menos la capacidad de un desarrollador devuelta a todo el equipo. A un coste totalmente cargado de entre 120.000 y 180.000 dolares por esa capacidad, solo el ahorro cubre a un responsable de mantenimiento y sobra.

Frente a eso, el coste corriente de un responsable a media jornada y una herramienta de documentacion. El sistema pasa el punto de equilibrio dentro del primer ano, y el segundo ano es donde el retorno se acumula, porque el tiempo de desarrollo de referencia sigue bajando a medida que crece la cobertura. Ese es el caso que un director financiero financia. No es coherente, sino que devuelve la capacidad de una persona por el coste de una fraccion de persona. La primera frase es gusto. La segunda es una partida.

Nada de esto funciona si el analisis de partida esta mal. Si no sabes lo que tienes, no puedes poner precio a lo que ahorra. Una auditoria del design system es la forma mas barata de fijar el numero de referencia antes de construir el caso economico.