DEVELOPMENT AND DESIGN
UI design and front-end development. Full system from foundations to components, in parallel with the technology stack migration.
Designed in Figma with design tokens. Built with Next.js, React, CSS and SASS. Migration from Ruby on Rails and Java to a unified modern stack.
BKOOL had an outdated and inconsistent design across its public web and SaaS, compounded by a fragmented technology stack. The solution required updating design and technology simultaneously.
BKOOL operated with two digital surfaces with different goals: the public web, focused on conversion and acquiring new users, and the subscription management area, focused on retaining existing users and making their lives easier, pausing, deferring or changing their plan, managing invoices, adding family members. The problem was twofold. On one hand, the design was outdated and inconsistent, visual patterns varied between sections and there was no coherence between the public web and the SaaS. On the other hand, the technology stack was fragmented: the public side mixed Java and React, while the private side ran on Ruby on Rails. That technological fragmentation directly limited design and experience possibilities. The decision was clear: update stack and design simultaneously, using the technology migration as an opportunity to build a coherent visual system from the ground up.
Unify the visual experience between public web and SaaS, and reduce friction in subscription management flows to improve user retention.
Without formal prior research, the process started from an exhaustive inventory of existing components. The library was reduced by half, foundations were defined from scratch and the system was redesigned always keeping the user at the centre of decisions.
Two profiles with different needs on the same platform. The new user arrives at the public web looking to understand what BKOOL is and whether it's worth subscribing, they need clarity, trust and a frictionless conversion path. The existing user enters the management area with a specific task: changing their plan, pausing their subscription, adding a family member. They need efficiency, control and the feeling that the platform is on their side. Both profiles share the same visual system but with different emphasis: conversion for the first, utility for the second.
Three flows defined the system priorities. The first: the conversion flow, a new user understanding the product and subscribing without friction. The second: subscription management, an existing user being able to pause, change plan or cancel without feeling trapped. The third: adding family members or friends to the plan, a flow with complex restrictions (maximum two added users, maximum two changes allowed) that required new components and very well-resolved edge cases.
The starting point was an exhaustive inventory of all existing components on the platform. The diagnosis was clear: there was no designed system, there were duplicate components, unnecessary variants and ad hoc solutions to problems that already had standard solutions. The decision was not to adapt what existed but to start from the foundations: first defining typography, colour palette, spacing and breakpoints, then building components from there. That order, foundations first, components second, discarded the faster alternative of reusing and cleaning up existing components, which would have perpetuated the underlying inconsistency.
The system was built in ordered layers. First the foundations: typography, colour palette, spacing, breakpoints and iconography. Then the inventory and audit of existing components. Then redesign, unification and removal, the library was reduced by approximately half. Finally new components for flows that didn't previously exist, such as the add family members module with its restrictions and edge cases.
Foundations before components. Inventory before redesign. And an add family members flow with complex restrictions that required building new components designed from edge cases, not from the happy path.
The temptation in any redesign is to go straight to the visible components, buttons, cards, navigation. We discarded that approach. Without solid foundations, any component you build inherits the inconsistency you're trying to solve. We first defined typography, colour palette, spacing, breakpoints and iconography. Only when that layer was complete did we start touching components. That order saved the system from becoming another patch on the original problem.
Before designing a single new component, we made an exhaustive inventory of everything that existed on the platform. The result was revealing: duplicate components for the same use case, unnecessary variants that didn't respond to any real need and ad hoc solutions that nobody remembered why they existed. The library was reduced by approximately half. That process of removal was not aesthetic, it was structural. Every eliminated component was one less source of inconsistency to maintain.
The flow for adding family members or friends to the plan was the most complex in the project. The business restrictions were specific: maximum two added users, maximum two changes allowed over the life of the subscription. Designing from the happy path would have produced a UI that works in the ideal case but fails at the edges. We designed from the edge cases: what does the user see when they've already used their two changes? How do you communicate a limit without the user feeling penalised? What happens if one of the added users cancels? Each restriction generated new components meticulously designed to communicate state without generating frustration.
The technology migration and the redesign were simultaneous and fed each other. When the previous stack was an obstacle to a UX decision, we changed the stack. When a design decision was technically unviable within the available time, we adapted the design without compromising the user experience. That constant negotiation between design and technology required the same person to understand both sides, and was exactly the type of work that a hybrid profile resolves naturally.
BKOOL's general visual system prioritises conversion and trust. Clear and readable typography, colour palette with the brand colour as emphasis element in calls to action, and components with sufficient visual weight to guide the user towards subscription. It is deliberately differentiated from the private area system, which prioritises data density and metric reading over visual impact.
The subscription management flow required the most edge cases: paused plan states, subscription with family members in different states, change limit reached, added user who cancels their account. Each state needed specific components and messages designed to communicate the situation without generating anxiety or frustration in the user.
The technology migration and the redesign happened in parallel. Every design decision was validated against its technical feasibility, and every technical limitation was resolved by prioritising user experience over the convenience of the previous stack.
The architecture followed the same order as the design process: foundations first, components second. Design tokens, colour, typography, spacing, breakpoints, were defined as CSS variables before writing any component. Atomic components were built on top of that base, and complex modules on top of those, such as the subscription management flow or the family members module. This hierarchy ensured that any change to a token automatically propagated to all components using it, without manual intervention. Reducing the inventory by half also radically simplified the code architecture, fewer components means less maintenance surface and less risk of inconsistency.
The biggest learning came from the family members flow. Edge cases that seemed rare in the design, the user who has already used both their changes, the added family member who cancels their account, turned out to be frequent situations in production. Each one required going back to the design and creating specific state components that the original mockup hadn't considered. There were also design decisions that had to be simplified due to previous stack constraints during the transition, in those cases, the criterion was always to preserve experience clarity above visual fidelity to the mockup.
A design system built from the foundations, with the component library reduced by half and a complete technology migration. The most valuable challenge: designing and migrating in parallel without losing coherence or compromising user experience.
The platform moved from an outdated and inconsistent design to a unified visual system covering both the public web and the subscription management area. The component library was reduced by approximately half, eliminating duplicates, unnecessary variants and ad hoc solutions that nobody remembered why they existed. The technology stack was unified under modern technologies, eliminating the fragmentation between Ruby on Rails, Java and React. Subscription management flows, including the family members module with its restrictions and edge cases, were designed and implemented with specific components for each state. The system never iterated beyond its initial version, the company was acquired and shut down before it could evolve.
I would seek more cohesion between marketing and product from the start. In this project, marketing and the UX/UI product team worked with goals that weren't always aligned, and that internal friction affected design decisions. A design system covering both conversion and product needs both departments to share criteria from the beginning, not negotiate them project by project. I would also have documented the system in more detail, without Storybook in this case, some component usage decisions ended up in informal conversations rather than in a consultable reference.
The natural next step would have been incorporating Storybook as the source of truth for the general system, just as was done with the private area system. It would also have been valuable to establish a formal contribution process for the system, a clear criterion for when a new component is added, when an existing one is modified and when one is discarded. Without that process, design systems tend to grow in an uncontrolled way and recover the inconsistency they were trying to eliminate.