Resumen
Lideré la arquitectura e implementación de Root DS para la plataforma B2B de rápido crecimiento de Treez. La iniciativa abordó la fragmentación crítica de UI en web y móvil, transformando una deuda técnica significativa en un sistema unificado que redujo los ciclos de QA en un 30% y aceleró la entrega.
Contexto
Treez sirve como el sistema operativo de misión crítica para el comercio minorista de cannabis empresarial, manejando flujos de trabajo complejos desde el cumplimiento estricto hasta el procesamiento de transacciones de alto volumen.
Sin embargo, la rápida expansión del mercado expuso la fragilidad de nuestro frontend heredado. Mientras nos preparábamos para escalar de la web a un POS móvil nativo en 2024, la falta de un sistema unificado se convirtió en un bloqueador crítico. No solo lidiábamos con botones inconsistentes; enfrentábamos una base de código fragmentada que hacía que cada nueva funcionalidad fuera exponencialmente más costosa de construir.
En ese momento, la realidad operativa era frágil:
- Flujos Aislados: Diseño e Ingeniería carecían de un vocabulario compartido, llevando a soluciones divergentes para problemas idénticos.
- Activos Descentralizados: No existía una única fuente de verdad; las bibliotecas de Figma estaban desconectadas del código de producción.
- Puntos Ciegos de Cumplimiento: La accesibilidad se trataba como una ocurrencia tardía, creando deuda significativa para futuros requisitos empresariales.
- Entrega de Alta Fricción: Sin tokens estandarizados, los desarrolladores gastaban ciclos valiosos interpretando manualmente especificaciones de diseño.
En resumen: Estábamos pagando un ‘impuesto de reinvención’ en cada sprint.
El Problema
Treez enfrentaba una crisis de escalabilidad. El rápido crecimiento llevó a flujos de trabajo aislados, donde los equipos reconstruían constantemente la UI existente, resultando en bases de código infladas y experiencias de usuario inconsistentes en toda la plataforma B2B SaaS.
“Sin un sistema, estábamos reconstruyendo la misma UI — con diferente calidad — cada sprint.”
La fragmentación erosionaba la confianza del usuario y confundía los patrones de navegación.
Cero 'fuente de verdad' llevó a duplicación masiva de archivos y conflictos de versiones.
Diseño e Ingeniería hablaban idiomas diferentes, causando errores de implementación.
El producto estaba legalmente expuesto e inutilizable para usuarios de tecnología asistiva.
Estilos desalineados atrapaban al equipo en ciclos interminables de ajustes de píxeles.
Sin documentación, la incorporación dependía de transferencia verbal, costando semanas.
El equipo de diseño sabía que necesitábamos una solución que fuera más que solo una biblioteca de componentes — necesitábamos un sistema.
¿Por qué Root DS?
Nombramos al sistema Root porque representa la fundación debajo de todo lo que construimos — una estructura conectada de tokens, componentes y decisiones de diseño que respalda toda la experiencia del producto.
Como una red de raíces, es invisible para los usuarios, pero esencial para lo que ven, sienten y usan.
Objetivos
Nuestros objetivos eran claros e intencionalmente limitados a la plataforma web, con el entendimiento de que el soporte móvil (POS) vendría después:
- Establecer consistencia visual y de interacción en todas las superficies web
- Mejorar la accesibilidad por defecto mediante componentes compatibles y probados
- Reducir redundancia en Figma y código de producción
- Permitir incorporación más rápida y reducir el costo de entrega
- Crear un sistema lo suficientemente flexible para soportar futuros productos POS y móviles
Descubrimiento
Nuestro proceso comenzó con una fase exhaustiva de descubrimiento y auditoría:
Sobrecarga de Deuda Visual
Descubrimos años de deriva acumulada, incluyendo más de 20 estilos de gris no documentados y patrones de navegación fragmentados.
Escala de Redundancia
Catalogamos más de 100 patrones desconectados, revelando que ~60% del esfuerzo de frontend se gastaba reconstruyendo UI existente.
La Brecha de Traspaso
Identificamos falta de 'fuente de verdad' para Ingeniería, causando conjeturas constantes y regresiones de UI recurrentes.
Riesgo de Cumplimiento
Señalamos riesgos críticos: el 80% de las interacciones principales fallaban en WCAG 2.1 AA, amenazando contratos empresariales.
Cuello de Botella de Velocidad
Identificamos el obstáculo: La traducción manual de estilos de diseño a CSS añadía 2-3 días de overhead a cada sprint.
No asumimos lo que los equipos necesitaban — investigamos y escuchamos.
Principios de Diseño
Definimos 5 principios rectores para dar forma a cada componente, token e interacción:
Consistencia sobre personalización
Accesibilidad por defecto
Consciente de la plataforma, no limitado por ella
Tokens sobre estilos
La documentación es parte del producto
Estos principios aseguraron que Root no solo fuera escalable — sino sostenible.
Arquitectura del Sistema
Root fue construido sobre una base atómica estricta utilizando una estructura de tokens de múltiples niveles (global vs. alias vs. tokens de componente). Esto aseguró flexibilidad temática para futuro etiquetado blanco y allanó el camino para la paridad móvil.
Fundamentos
- Paleta de colores y tokens compatibles con contraste
- Escala tipográfica y sistema de espaciado modular
- Iconografía, cuadrícula y primitivos de movimiento
Componentes
- Botones, elementos de formulario, tablas, tarjetas, navegación
- Estructura responsiva para layouts de panel con muchas funcionalidades administrativas
- Estados de componentes: hover, focus, disabled, error
Patrones
- Grupos de formularios, validación de entrada, manejo de errores
- Estados vacíos, alertas, filtrado, modales
Documentación
- Biblioteca de Figma con tokens y auto-layout
- Zeroheight para guías de uso, ejemplos de qué hacer/no hacer
- Conectado a Storybook para paridad con desarrolladores
Colaboración y Lanzamiento
“Diseñado con ingeniería — no para ellos.” Reemplazamos los traspasos frágiles con un Modelo de Propiedad Compartida, asegurando la viabilidad técnica desde el primer día.
- El Puente (Portal): Co-desarrollamos un portal de referencia interno que mapeaba tokens de Figma directamente a variables CSS, asegurando paridad de implementación 1:1.
- La Gobernanza: Establecimos un modelo de contribución bidireccional, permitiendo que tanto diseñadores como desarrolladores evolucionaran el sistema responsablemente.
- La Cultura: Lideramos talleres de incorporación para cambiar la mentalidad del equipo de “adivinar estilos” a utilizar el sistema como única fuente de verdad.
Resultados
Root creó claridad y escala en todo el ecosistema de diseño y desarrollo de Treez.
“Es la primera vez que tenemos una verdadera fuente de verdad” — Sam, Líder de Ingeniería
Próximos Pasos
Root fue intencionalmente limitado a la plataforma web, pero su arquitectura fue diseñada para extenderse a móvil y POS — una prioridad del roadmap para 2024.
En progreso:
- Extensión de tokens para puntos de quiebre móviles y patrones de interacción
- Alineación de la aplicación POS con el lenguaje de diseño web
- Flexibilidad de temas de marca para funcionalidades de marca blanca
Objetivos futuros:
- Piloto de linting de accesibilidad automatizado en pipeline CI/CD
- Documentación versionada con changelogs automatizados
- Dashboard de operaciones de diseño para salud del sistema y métricas de adopción
Reflexión
Root no fue solo un proyecto — fue un cambio en cómo los equipos de Treez construyen, colaboran y escalan.
Pasamos de la artesanía individual a la propiedad compartida. Del caos de diseño a la claridad. De la reactividad a la intencionalidad.
Y lo hicimos escuchando, alineándonos y escalando con propósito.