El problema
Tres productos internos en mi trabajo anterior tenían cada uno su propio botón, input y modal, sutilmente distintos en padding, color y comportamiento de foco. Cada ajuste de diseño había que hacerlo tres veces y siempre se desincronizaba en pocas semanas.
Rol e impacto
- Proyecto individual, design systems.
- Reemplazó tres sets de componentes separados con un solo paquete versionado.
- Adoptado en 3 productos internos sin regresiones visuales tras la migración.
- Redujo a la mitad el tiempo de revisión de componentes nuevos gracias a defaults de accesibilidad compartidos.
Decisiones técnicas y desafíos
Cada producto necesitaba su propia paleta de colores y escala de border radius, pero no quería tres forks de los mismos componentes. Comparé publicar builds temáticos separados por producto contra un solo build controlado enteramente por custom properties de CSS.
Elegí custom properties de CSS resueltas a nivel del theme provider, porque permitía que cada producto consumiera exactamente los mismos componentes compilados y solo sobrescribiera un pequeño archivo de tokens, en vez de mantener builds paralelos que podían desincronizarse.
Reescribir la UI de los tres productos de una sola vez era demasiado riesgoso para lanzarlo con seguridad. Evalué un cutover directo por producto contra una migración gradual, componente por componente, detrás de la API existente.
Opté por un codemod que reemplazaba un componente a la vez, manteniendo compatible la API de props entre el componente viejo y el nuevo durante la transición, ya que permitía que cada equipo migrara en su propio horario sin un release de golpe que pudiera romper producción.
Stack detallado
| Capa | Tecnología | Por qué |
|---|---|---|
| Componentes | React, Radix UI primitives | Comportamiento accesible listo para usar, sin estilos para theming limpio |
| Estilos | Tailwind CSS, custom properties de CSS | Theming por producto sin mantener builds separados |
| Docs | Storybook | Documentación viva y baseline de regresión visual |
| Release | Changesets | Versionado independiente y con changelog por paquete |
Galería
Qué haría diferente
Invertiría en testing de regresión visual automatizado desde el día uno en vez de agregarlo después de la primera migración cross-product. Detectamos manualmente algunas regresiones de tokens de tema que una herramienta de diff visual habría señalado de inmediato.