El Sistema de Diseño de Hourly

El Problema

Cuando llegué a Hourly, ingeniería construía con lo que venía de fábrica: Material Design en web y Android, componentes nativos en iOS. Eso funcionó mientras el producto era pequeño. A medida que la marca tomó forma y el producto creció, esas librerías empezaron a quedarse cortas de dos maneras. No podían llevar la marca, y no cubrían los casos que de verdad necesita un producto de nómina y gestión de personal.

Sin una base compartida, el mismo patrón se veía distinto en distintos lugares. Cada pantalla nueva era una oportunidad para que el producto se alejara un poco más de sí mismo.

El Análisis

Hourly compite en un espacio lleno de productos que hacen cosas parecidas. Acordamos desde temprano que una buena experiencia de usuario sería uno de nuestros diferenciadores: lo que hace que la app se sienta intuitiva y no solo completa. Eso es difícil de proteger pantalla por pantalla. Necesita un sistema.

Se lo propuse al CEO y al líder de ingeniería. No fue difícil convencerlos. Ya confiaban en la gobernanza de diseño, y el beneficio de un sistema reutilizable era fácil de ver. Lo difícil vino después. Un sistema le cuesta tiempo a ingeniería la primera vez que se construye, y una startup en etapa temprana necesita lanzar rápido. Cada componente era un equilibrio entre construirlo bien y entregar lo que el negocio necesitaba ese mes. El argumento para pagar ese costo al inicio era la velocidad después: una vez que un componente existe, diseñar y mantener se vuelve mucho más rápido.

La Solución

Hice la investigación y definí la estructura que seguiría el sistema: tokens en tres niveles. Los primitivos fueron lo primero, porque todo lo demás hereda de ellos. Los primitivos guardan los valores base: color, tipografía, espaciado. Construí los colores como escalas de tonos en OKLCH, un espacio de color perceptualmente uniforme, para que las escalas aguanten a largo plazo, las capas semántica y de componente puedan flexionarse sin perder consistencia, y el contraste cumpla WCAG desde la base, antes de que exista un solo componente. Los tokens semánticos les dan un propósito a esos valores. Los tokens de componente van un paso más allá: el padding, la tipografía y el borde de un botón apuntan cada uno a un token con nombre, no a un valor suelto. Los componentes se construyen solo con esos tokens.

Con esa base lista, trabajé muy de cerca con una persona de diseño senior de mi equipo, y construimos los componentes juntos. La librería web se volvió la referencia para mobile: les enseñamos el proceso a los otros diseñadores, y lo siguieron para construir las librerías de iOS y Android sobre las mismas capas, con componentes nativos que heredan de la misma fuente. La guía para diseñadores vive en Figma junto a los componentes: cuándo usar cada uno, sus variantes y sus estados.

Los desarrolladores necesitaban la misma claridad. Hago sesiones frecuentes con el equipo de ingeniería sobre lo nuevo en el sistema y cómo les ayuda a ellos y a nuestros clientes, con consistencia y buenas prácticas. Durante los últimos años, ingeniería construyó los componentes en Storybook, y diseño revisaba y aprobaba cada uno.

Desde el año pasado lidero la migración a una nueva librería en código, y esa parte la construyo yo, porque el código es donde me muevo con más soltura. Mantiene las mismas capas: CSS para los primitivos, Tailwind para los tokens semánticos y shadcn/ui para los componentes, todo documentado en Storybook. Cada componente de Figma tiene hoy su equivalente 1:1 en código, con las mismas especificaciones. Uso Claude para construir sobre esa base, y para leer las especificaciones de un diseño en Figma y armarlo con nuestros propios componentes.

La accesibilidad es parte de la definición. Como ahora construyo y administro los componentes en Storybook, agregué validaciones que corren por componente: revisiones de WCAG y puntajes de accesibilidad, así que cada uno tiene que cumplir al menos AA antes de salir. Antes, los desarrolladores construían y probaban los componentes, y a veces la accesibilidad quedaba por fuera. Ahora viene incluida, y es responsabilidad de diseño.

Impacto

El primer cambio fue la claridad. Con las bases en Figma, los desarrolladores podían ver exactamente qué esperaban los diseñadores, con guías escritas en lugar de interpretaciones. Diseñar también se volvió más rápido, porque ahora armamos las pantallas con el sistema. Esa velocidad fue el centro de la propuesta original. Nunca la medimos con cronómetro, pero se nota en el trabajo: ya nadie tiene que decidir cómo debe verse y comportarse un componente o uno de sus estados. Se usa, y todas sus variantes ya están aprobadas por la dirección de diseño.

La librería ya tiene entre 40 y 50 componentes solo en web. Cada uno se multiplica en sus tamaños, estados y variantes: pequeño y grande; normal, hover, deshabilitado y cargando; primario, secundario, terciario, destructivo y ghost, cada uno sólido o con borde. La librería web es la base que siguen las librerías de iOS y Android, y cada componente de Figma tiene su gemelo 1:1 en código.

La librería en código cambió cómo trabajamos con los stakeholders. Podemos mostrar interacciones complejas y buen motion en un prototipo que funciona en lugar de describirlos, y probar flujos reales con usuarios. Cuando una funcionalidad es lo bastante grande para llevarla a la dirección, la presentamos juntos el director de gestión de producto, el director de ingeniería y yo. Los stakeholders que no son técnicos ahora recorren el flujo real en código, no una imagen. Las pruebas también se volvieron más rápidas. Con IA en el flujo de trabajo, validamos a nivel de componente mucho más rápido, un trabajo que antes estaba en manos de los desarrolladores y no siempre salía bien. Y como las revisiones de WCAG viven en cada componente, la accesibilidad es lo normal y no depende de quién construyó la pantalla.

Reflexiones

La lección más grande cambió cómo veo los sistemas de diseño. Un sistema nunca está terminado. Es un proyecto siempre vivo: tiene que seguir adaptándose a nuevas tecnologías, nuevos componentes y nuevos requisitos. Parte del trabajo es recordarles a los stakeholders y a los desarrolladores, una y otra vez, que construirlo una vez no significa que se sostiene solo.