DESARROLLO Y DISEÑO
Diseño del sistema y desarrollo de Storybook en solitario. Dentro de un equipo de producto con developers y marketing.
Diseñado en Figma. Desarrollado con Next.js, React, CSS y SASS. Sistema de componentes documentado en Storybook como fuente de verdad para diseño, desarrollo, marketing y dirección.
El diseño general de BKOOL no cubría las necesidades de un dashboard deportivo. Los usuarios tenían dificultades para encontrar e interpretar sus métricas, acceder a leaderboards y comparativas con otros deportistas.
BKOOL es una plataforma de ciclismo virtual con una base de usuarios activa y comprometida. El área privada, donde los deportistas gestionan sus entrenamientos, métricas y comparativas, compartía el mismo lenguaje visual que el área de marketing y conversión. El resultado era un dashboard con exceso de ruido visual, jerarquías poco claras y componentes no optimizados para la lectura e interpretación de datos deportivos. Las quejas de usuarios eran concretas: no encontraban sus métricas, no entendían los leaderboards y las comparativas con otros deportistas eran difíciles de leer. El detonante para arrancar el proyecto fueron esas quejas directas. La decisión estratégica fue clara: el área privada necesitaba su propio sistema visual, diferenciado del diseño de marca general, centrado en los datos del usuario y no en la conversión.
Reducir la fricción en la lectura e interpretación de métricas deportivas y mejorar el acceso a leaderboards y comparativas.
El proceso partió de entrevistas reales con usuarios incentivados. Los hallazgos definieron las prioridades del sistema: jerarquía visual clara, métricas legibles y navegación sin fricción hacia leaderboards y comparativas.
El usuario del área privada es un deportista activo que accede al dashboard para revisar su progreso, compararse con otros ciclistas y tomar decisiones sobre su entrenamiento. No es un usuario casual, tiene motivación intrínseca y expectativas altas sobre la legibilidad de sus datos. Su frustración no era estética: era funcional. No encontraba lo que buscaba, y cuando lo encontraba, no podía interpretarlo con rapidez.
Tres flujos no podían fallar: acceder y leer métricas de entrenamiento de forma inmediata, navegar hasta leaderboards y comparativas sin perderse, e interpretar el propio rendimiento en relación al de otros deportistas. Todo el sistema de jerarquía visual se construyó para servir a estos tres flujos.
La primera exploración fue adaptar el sistema de diseño general de BKOOL al área privada, ajustar colores, tipografías y componentes existentes. Se descartó porque el sistema de marca estaba pensado para conversión: llamadas a la acción, impacto visual, persuasión. Esos principios son opuestos a los de un dashboard donde el usuario necesita concentración, legibilidad y acceso rápido a datos. Crear un sistema diferenciado no era un capricho estético, era una necesidad funcional.
La arquitectura del sistema se organizó en tres niveles: fundamentos (tipografía, color, espaciado, iconografía), componentes atómicos (botones, inputs, badges, tags) y componentes complejos (tarjetas de métricas, gráficas, leaderboards, módulos de comparativa). Cada nivel documentado en Storybook como fuente de verdad única para diseño, desarrollo, marketing y dirección.
La regla 60-30-10 como sistema de énfasis, no de decoración. El color primario reservado para métricas y acciones importantes. Los colores semánticos usados exclusivamente para su función, nunca como recurso visual.
En un dashboard con alta densidad de información, el color es la herramienta más poderosa para dirigir la atención. Aplicamos la regla 60-30-10: el 60% del espacio en color neutro y secundario, el 30% en elementos de soporte, y el 10% en color primario reservado exclusivamente para métricas clave y acciones importantes. Esto garantiza que el usuario sepa en todo momento dónde mirar primero sin que el diseñador tenga que decírselo explícitamente.
Success, warning y error se usaron de forma estricta y exclusiva para su función semántica. Nunca como recurso decorativo ni para destacar elementos que no implican un estado real. En un dashboard deportivo donde el usuario interpreta datos constantemente, contaminar los colores semánticos con usos decorativos destruye la legibilidad del sistema, el usuario deja de saber si un verde significa "bien hecho" o simplemente "elemento destacado".
La mayoría de componentes interactivos secundarios se construyeron como outlined, sin relleno, con borde. Esto reduce el peso visual del dashboard y reserva los componentes con relleno y color primario para las acciones y métricas que realmente importan. En un entorno con alta densidad de datos, cada decisión de peso visual cuenta.
Storybook no se preparó solo para developers. El objetivo era que diseño, desarrollo, marketing y dirección tuvieran acceso a la misma referencia actualizada del sistema. Cada componente documentado con sus variantes, estados y criterios de uso. Esto eliminó las conversaciones recurrentes sobre qué componente usar en cada caso y redujo la inconsistencia entre lo que diseño entregaba y lo que desarrollo implementaba.
El sistema visual se construyó con una identidad propia diferenciada de la marca general de BKOOL. Tipografía optimizada para lectura de datos, paleta cromática reducida con énfasis controlado, iconografía consistente y espaciado sistemático. Todos los fundamentos documentados en Storybook antes de construir ningún componente complejo.
El sistema de diseño y el código vivían en el mismo entorno. Cada componente diseñado en Figma tenía su implementación directa en Storybook, sin intermediarios, sin pérdida de criterio en el handoff.
La arquitectura siguió una estructura de tres niveles. El primer nivel son los fundamentos: tokens de color, tipografía, espaciado e iconografía, definidos antes de construir ningún componente. El segundo nivel son los componentes atómicos: botones, inputs, badges, tags, tooltips, cada uno con sus variantes y estados documentados en Storybook. El tercer nivel son los componentes complejos: tarjetas de métricas, gráficas, leaderboards y módulos de comparativa, construidos exclusivamente a partir de los componentes atómicos del segundo nivel, sin excepciones. Esta jerarquía garantizaba que cualquier cambio en un token o componente atómico se propagara automáticamente a todos los componentes complejos que lo usaban.
El mayor aprendizaje fue en los componentes de gráficas. En Figma, las gráficas se diseñan como elementos estáticos, puedes controlar exactamente cómo se ven. Al implementarlas en código con datos reales, aparecieron situaciones que el diseño no había previsto: métricas con valores extremos que rompían la escala, etiquetas que se solapaban con datos densos, estados vacíos cuando el usuario no tenía actividad registrada. Cada uno de esos casos obligó a volver al diseño y tomar decisiones que el mockup estático nunca había forzado. Esa iteración entre diseño y código fue el proceso más valioso del proyecto.
El handoff dejó de ser una conversación para convertirse en una referencia. Cualquier developer, diseñador o persona de marketing podía abrir Storybook y ver el componente, sus variantes, sus estados y sus criterios de uso, sin necesidad de preguntar. Esto redujo drásticamente las inconsistencias entre diseño e implementación y eliminó las reuniones de alineación recurrentes sobre qué componente usar en cada caso.
Un sistema de diseño completo, documentado en Storybook y adoptado por diseño, desarrollo, marketing y dirección. El proyecto quedó en desuso cuando la empresa fue adquirida y cerrada, no por fallo del sistema, sino por una decisión externa al producto.
El sistema unificó el lenguaje visual del área privada de BKOOL bajo una referencia única. Los developers dejaron de tomar decisiones visuales por su cuenta, tenían Storybook. Los diseñadores dejaron de repetir las mismas explicaciones en cada entrega, estaban documentadas. Marketing y dirección podían consultar el estado del sistema sin necesidad de involucrar al equipo de producto. La fricción de coordinación se redujo de forma significativa. El sistema no llegó a ser reemplazado por uno nuevo, la empresa fue adquirida para obtener su base de usuarios y posteriormente cerrada.
Si lo repitiera hoy, no trabajaría solo. Un sistema de diseño construido por una sola persona es frágil, depende demasiado del criterio y la disponibilidad de esa persona. También buscaría contar con un equipo de producto con capacidad de decisión real desde la dirección de la empresa. En este proyecto, demasiadas decisiones estratégicas recaían sobre el departamento de UX/UI sin el respaldo organizativo necesario para ejecutarlas con consistencia. Un buen sistema de diseño necesita patrocinio desde arriba, no solo ejecución desde abajo.
El siguiente paso natural habría sido migrar el sistema a design tokens conectados directamente al código, eliminando la capa manual de traducción entre Figma y Storybook. También habría sido valioso incorporar pruebas de accesibilidad automatizadas en el pipeline de Storybook para garantizar el cumplimiento de contraste y navegación por teclado en cada componente.