Guiding a new future for the product by design system migration

At the same time, parts of the product were still relying on the original component library implemented 15 years earlier. Together, these issues were creating an increasingly fragmented experience for our customers.

My mission was to understand why developers had stopped using the design system and find a sustainable way to restore consistency and scalability across the product.

I conducted this audit with another Product Designer, and together we documented more than 50 pages of examples where components had been implemented incorrectly or had broken after development.

With this evidence in hand, I scheduled a meeting with the development team to understand their perspective. This became a crucial step in uncovering the root cause of the problem.

Take a look below in some of inconsistencies with Falcon DS implementation.

Developers explained that they had stopped using the Falcon Design System because its components had originally been built with an overly complex structure, including too many props and constraints that made them difficult to use and maintain.

As a result, developers frequently detached the existing components and rebuilt them from scratch for new projects. The bigger issue was that several important parts of the product had already been migrated to Falcon, meaning that abandoning the existing system entirely would result in significant rework.

Based on these findings, I identified two possible approaches (neither of which was ideal...).

• Refactor the existing falcon components

  The first approach was to review and restructure the existing Falcon components. The goal was to preserve as much of the previous migration work as possible while removing unnecessary props and simplifying the component architecture. This would reduce the amount of rework required while addressing the technical issues that had prevented developers from adopting the system consistently.

• Recreate everything with a optimized strutured and remigrate what was done

  The second approach was to rebuild the component library with a more optimized architecture and then remigrate the parts of the product that had already been updated. I was initially reluctant to pursue this option because it would mean discarding a significant amount of work completed during the previous quarter. The proposed approach was to use shadcn/ui as a foundation and customize it using our primitive design tokens, aligning the resulting component library with Magazord's brand guidelines.

My response was straightforward:

“That part is on me. I’ll make the case for rebuilding the system and get stakeholder buy-in , even considering everything we've already invested in the previous migration.”

With the technical team aligned, I started designing the new system using shadcn/ui as a foundation. I removed unnecessary components and specifications, simplified the architecture, and established a new token structure based on primitive and semantic tokens.

One of my main concerns was avoiding the same mistake that had made the previous system difficult to adopt: creating components with too many constraints.

Instead, I designed flexible component structures with semantic slots that defined the type of content each area could accommodate without prescribing exactly how every component had to be used.

The header is a good example. Rather than creating multiple rigid variations for every possible use case, I defined semantic slots within the component where different types of content and actions could be placed. I applied the same principle across several components in the system.

This directly addressed one of the main complaints I had heard during the research: the same component often needed to accommodate different actions and information depending on the context, even when its underlying structure remained the same.

By creating these flexible structures, Product Managers and developers gained more freedom to adapt components to different product requirements while following a set of guidelines that preserved consistency across the system.

With the component set ready and published on Github, developers had the work to just review and tweak what was necessary, and this work in parallel with dev team, allowed us achieve solid results real quick.

While they were tweaking the components, I started to create a Storybook to document the components, behaviours, and to set the boundaries regarding the semantic components, as headers and product cards.

The Product Manager initially rejected the proposal because of the amount of rework it would require. I had anticipated this concern, given how much effort had already been invested in the previous migration.

As a final step, I proposed bringing the decision to the directors. My goal was to present the problem, the trade-offs between both approaches, and the long-term consequences of continuing with the existing system.

I was particularly concerned that preserving the previous migration simply to avoid rework would create larger UX and scalability problems in the future.

To prepare for the meeting with the directors, I created a presentation documenting the case and several design explorations demonstrating how the new system would behave across different scenarios.

The previous investment remained the main concern. Management questioned whether rebuilding the system justified discarding the development hours already spent on the migration.

I presented the new screens, interactions, and flows and made my position clear:

“If migrating to Falcon results in a worse experience than keeping the legacy system, then the migration itself isn't creating value. Our goal should be to improve the product. If achieving that requires rework, updated training materials, or additional support effort, I believe that's a necessary investment in building a stronger foundation for the company.”

The proposal ultimately received buy-in from all directors. An important factor in the decision was demonstrating that adopting the new design system would not require structural or back-end changes, significantly reducing the technical risk of the migration.

Thanks to clear documentation and practical do's and don'ts, it has been straightforward to communicate how the design system should be used and help teams adopt it consistently.

Together with the lead developer, I remain responsible for defining the next steps and evolving the design system.

The roadmap I created focuses on two main areas. First, I plan to expand the documentation and create reusable resources around the components, enabling Product Managers to build MVPs faster while maintaining a consistent experience.

Second, I want to refine the visual and interaction layer of the system through more polished micro-interactions, hover states, animations, colors, and textures. The goal is to move beyond consistency and create an experience that feels distinctive, polished, and enjoyable for Magazord's customers.