Contenido del curso

Guía de Estilos con Figma

Cómo construimos un design system en startup

Resumen

Crear un design system en una startup parece sencillo en teoría, pero la realidad implica iteraciones, negociaciones internas y mucha pasión por parte de quienes lo impulsan. Aquí te comparto cómo dos desarrolladores lograron convertir una idea personal en un proyecto formal con equipo dedicado, y qué aprendizajes pueden ahorrarte tiempo si estás pensando en hacer lo mismo.

¿Por qué una startup necesita un design system?

En una startup, los productos iteran rápido y los equipos terminan reinventando componentes una y otra vez. Esa fue la chispa que nos llevó a buscar una solución más ágil.

El problema concreto era la inconsistencia entre frameworks. Trabajábamos sobre un monolito en Ruby on Rails, pero también teníamos proyectos en Vue.js con JavaScript. En unos lados los botones se veían bonitos, en otros no tanto. Y aunque en Vue.js podíamos reutilizar componentes fácilmente, al saltar a Ruby tocaba volver a construirlos desde cero.

¿Qué es un design system y para qué sirve en una startup? Es un conjunto de componentes, reglas y procesos que unifican diseño y desarrollo. En una startup ayuda a evitar inconsistencias entre frameworks y acelera la creación de landing pages, productos y experimentos.

Empezamos con lo básico: un inventario visual donde documentábamos cómo lucía cada botón en cada pantalla. Ese ejercicio dejó al descubierto las inconsistencias y nos dio el argumento para avanzar.

¿Cómo arrancar un design system con recursos limitados?

La primera fase fue artesanal. Un amigo y yo, ambos del equipo de ingeniería, empezamos en nuestro tiempo libre a evaluar herramientas que nos permitieran unificar mundos.

Probamos bit.dev, una herramienta paga para gestionar componentes. Le presentamos la idea al CTO de manera casual y nos respondió: cárguenlo a la cuenta de la house y paguen eso mensual mientras experimentan. Ese pequeño gesto fue clave para empezar.

Con el tiempo sumamos a más personas de ingeniería. Llegamos a ser cuatro y nos dividimos los primeros componentes:

  • Un botón.
  • Una card.
  • Un modal.

¿Por qué no avanzaba el proyecto en el primer año?

Después de casi un año, solo teníamos cuatro componentes terminados. La razón era simple: lo hacíamos en nuestros tiempos libres y solo desde ingeniería, sin involucrar a diseño ni a producto.

Ahí entendimos algo importante: un design system no se construye desde un solo equipo. Necesita varias miradas para que funcione de verdad.

¿Cómo convencer al liderazgo para invertir en un design system?

La estrategia fue tratar a diseño como nuestro primer aliado. La idea era invitarlos al club y, desde ahí, vender la propuesta a CTO y CPO en conjunto.

Nos preparamos con disciplina. Hicimos varias sesiones para armar la presentación, pensábamos qué objeciones podía tener cada líder y cómo responderlas. Nos metíamos en la mente del CTO y de la CPO para anticipar dudas.

¿Cómo justificar un design system ante el CTO? Mostrando datos concretos: tiempo perdido en reinventar componentes, inconsistencias entre frameworks como Ruby on Rails y Vue.js, y proyección de ahorro al tener un equipo dedicado full time.

El resultado fue mejor de lo esperado. Conseguimos:

  • Un ingeniero full time dedicado al design system.
  • Dos diseñadores asignados desde el área de producto.
  • Un grupo externo de revisores que aprobaba pull requests y validaba decisiones de UX.

¿Cómo se organiza el flujo de trabajo entre diseño y desarrollo?

Con equipo formal, el reto fue diseñar procesos que conectaran a todos. El flujo incluye revisiones con el equipo de experiencia de usuario, validaciones cruzadas, handoff entre diseño y desarrollo, y QA.

Las personas externas, los que arrancamos por pasión, nos quedamos como avaladores. Aprobamos pull requests desde ingeniería y participamos en revisiones de UX. Es un proceso gigantesco, pero necesario para mantener consistencia.

¿Qué pasa cuando los equipos cambian?

Después de un año con el equipo consolidado, la empresa decidió reorganizar. Los procesos cambian y el design system se adapta. Hoy estamos reestructurando otra vez, buscando más agilidad y rediseñando flujos internos.

Y aquí viene lo interesante: un design system en startup nunca está terminado. Llevamos dos años desde la idea inicial, un año de construcción formal, y seguimos iterando.

¿Qué aprendizajes te puedes llevar para tu propio proyecto?

Si estás pensando en arrancar algo similar, estos son los puntos que yo tendría en cuenta desde el día uno:

  • Involucra a diseño y producto desde el inicio, no solo a ingeniería.
  • Documenta el inventario visual antes de escribir código.
  • Prepara una presentación sólida para el liderazgo con argumentos de negocio.
  • Pide recursos full time; el tiempo libre no rinde.
  • Diseña procesos de revisión con UX, QA y handoff claros.
  • Acepta que los equipos van a cambiar y los flujos también.

Cuéntame en los comentarios qué harías diferente si estuvieras arrancando un design system en tu startup, y qué procesos tomarías de esta experiencia para tu propio proyecto.