DEVELOPMENT AND DESIGN
Solo design system authorship and Storybook development. Within a product team including developers and marketing.
Designed in Figma. Built with Next.js, React, CSS and SASS. Component system documented in Storybook as the single source of truth for design, development, marketing and leadership.
BKOOL's general design language didn't meet the needs of a sports dashboard. Users struggled to find and interpret their metrics, access leaderboards and comparisons with other athletes.
BKOOL is a virtual cycling platform with an active and engaged user base. The private area, where athletes manage their training, metrics and comparisons, shared the same visual language as the marketing and conversion area. The result was a dashboard with excessive visual noise, unclear hierarchies and components not optimised for reading and interpreting sports data. User complaints were specific: they couldn't find their metrics, couldn't understand the leaderboards and comparisons with other athletes were hard to read. Those direct complaints were the trigger for starting the project. The strategic decision was clear: the private area needed its own visual system, differentiated from the general brand design, focused on user data rather than conversion.
Reduce friction in reading and interpreting sports metrics and improve access to leaderboards and comparisons.
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.
The private area user is an active athlete who accesses the dashboard to review their progress, compare themselves with other cyclists and make decisions about their training. This is not a casual user, they have intrinsic motivation and high expectations around data readability. Their frustration was not aesthetic: it was functional. They couldn't find what they were looking for, and when they did, they couldn't interpret it quickly.
Three flows could not fail: accessing and reading training metrics immediately, navigating to leaderboards and comparisons without getting lost, and interpreting personal performance relative to other athletes. The entire visual hierarchy system was built to serve these three flows.
The first exploration was to adapt BKOOL's general design system to the private area, adjusting existing colours, typography and components. It was discarded because the brand system was built for conversion: calls to action, visual impact, persuasion. Those principles are the opposite of what a dashboard needs, where the user requires focus, readability and quick access to data. Creating a differentiated system was not an aesthetic choice, it was a functional necessity.
The system architecture was organised in three levels: foundations (typography, colour, spacing, iconography), atomic components (buttons, inputs, badges, tags) and complex components (metric cards, charts, leaderboards, comparison modules). Each level documented in Storybook as the single source of truth for design, development, marketing and leadership.
The 60-30-10 rule as an emphasis system, not decoration. Primary colour reserved for key metrics and important actions. Semantic colours used exclusively for their function, never as a visual resource.
In a high-density information dashboard, colour is the most powerful tool for directing attention. We applied the 60-30-10 rule: 60% of space in neutral and secondary colour, 30% in supporting elements, and 10% in primary colour reserved exclusively for key metrics and important actions. This ensures the user always knows where to look first without the designer having to tell them explicitly.
Success, warning and error were used strictly and exclusively for their semantic function. Never as a decorative resource or to highlight elements that don't imply a real state. In a sports dashboard where the user constantly interprets data, contaminating semantic colours with decorative uses destroys the system's readability, the user no longer knows whether green means "well done" or simply "highlighted element".
Most secondary interactive components were built as outlined, no fill, with border. This reduces the visual weight of the dashboard and reserves filled, primary-coloured components for the actions and metrics that truly matter. In a high data-density environment, every visual weight decision counts.
Storybook was not prepared just for developers. The goal was for design, development, marketing and leadership to all have access to the same updated system reference. Each component documented with its variants, states and usage criteria. This eliminated recurring conversations about which component to use in each case and reduced inconsistency between what design delivered and what development implemented.
The visual system was built with its own identity, differentiated from BKOOL's general brand. Typography optimised for data reading, reduced colour palette with controlled emphasis, consistent iconography and systematic spacing. All foundations documented in Storybook before building any complex component.
The design system and the code lived in the same environment. Every component designed in Figma had its direct implementation in Storybook, no intermediaries, no loss of design intent in the handoff.
The architecture followed a three-level structure. The first level is foundations: colour tokens, typography, spacing and iconography, defined before building any component. The second level is atomic components: buttons, inputs, badges, tags, tooltips, each with their variants and states documented in Storybook. The third level is complex components: metric cards, charts, leaderboards and comparison modules, built exclusively from second-level atomic components, without exception. This hierarchy ensured that any change to a token or atomic component automatically propagated to all complex components using it.
The biggest learning came from chart components. In Figma, charts are designed as static elements, you can control exactly how they look. When implementing them in code with real data, situations appeared that the design hadn't anticipated: metrics with extreme values that broke the scale, labels overlapping with dense data, empty states when the user had no recorded activity. Each of those cases required going back to the design and making decisions that the static mockup had never forced. That iteration between design and code was the most valuable process in the project.
Handoff stopped being a conversation and became a reference. Any developer, designer or marketing person could open Storybook and see the component, its variants, its states and its usage criteria, without needing to ask. This drastically reduced inconsistencies between design and implementation and eliminated recurring alignment meetings about which component to use in each case.
A complete design system, documented in Storybook and adopted by design, development, marketing and leadership. The project fell into disuse when the company was acquired and shut down, not due to system failure, but due to a decision external to the product.
The system unified the visual language of BKOOL's private area under a single reference. Developers stopped making visual decisions on their own, they had Storybook. Designers stopped repeating the same explanations with every delivery, they were documented. Marketing and leadership could check the state of the system without involving the product team. Coordination friction was significantly reduced. The system was never replaced by a new one, the company was acquired for its user base and subsequently shut down.
If I were to do it again today, I would not work alone. A design system built by a single person is fragile, it depends too heavily on that person's judgement and availability. I would also seek to have a product team with real decision-making authority from company leadership. In this project, too many strategic decisions fell on the UX/UI department without the organisational backing needed to execute them consistently. A good design system needs sponsorship from the top, not just execution from the bottom.
The natural next step would have been migrating the system to design tokens connected directly to code, eliminating the manual translation layer between Figma and Storybook. It would also have been valuable to incorporate automated accessibility testing into the Storybook pipeline to guarantee contrast compliance and keyboard navigation across every component.