When I joined the company, I was focused on learning how the products worked.

The more projects I worked on, the more often I ran into the same issues. Similar components existed in different versions. Developers interpreted Figma files instead of building from shared patterns. Small decisions kept being made more than once.

It simply made the work harder than it needed to be.

Around the same time, work on a new FXCM platform was starting. New backend. Native apps. Web. PWA.

It felt like the right moment to question how we wanted to build products going forward.

Instead of solving the same problems in every new project, my manager and I started discussing whether we could solve them once.

That conversation eventually became the Design System.

In every new project the conversations were the same. Wallet. Then Onboarding. Support. Reporting. New concepts for FXCM.

A button behaved one way in one product and differently in another.

Components were recreated because there wasn't a shared version to start from.

Developers asked the same implementation questions because every Figma file had to be interpreted separately.

Nothing was seriously broken.

The issue was that everyone was solving the same problems independently.

After a while, it became difficult to ignore.

Fixing individual screens wasn't changing the way we worked.

That was the point where I started looking at the system behind the separate projects.

Our first instinct wasn't to build a Design System from scratch.

My manager asked me to investigate existing solutions that we could buy, customise and expand over time.

As I went through the most common libraries, one limitation kept coming back.

Most systems were designed primarily for the web. They offered excellent React components, but our roadmap looked different. We were preparing a platform that would run on web, native iOS, Android and PWA. Reusing the same design language across all of them was more important than reusing the same code.

At the same time, I started exploring another idea on my own. Instead of adapting an existing library, what if we built the foundations ourselves and let every platform implement them in its own way?

I put together a small proof of concept and shared it with my manager. We reviewed it together, validated the approach with engineering and compared it with what I had learned during the investigation.

From that point on, the direction became much clearer.

We were deciding what would give us the best chance of building one shared product across four platforms.

The platform strategy became the deciding factor, not the component library.

I started with the foundations - establishing and building the token structure and creating the button component.

Once the button and its documentation were ready, I handed the file over to engineering. Together we tested whether Claude Code could understand the documentation, generate the component and match it to the design.

It worked.

That small test gave us confidence that the workflow made sense, not just the component itself.

From there, expanding the library became a much safer investment.

The first component validated the process.

Once the foundations were in place, building new components became much more predictable. Each one reused patterns we already trusted.

The documentation evolved alongside the library. It described behaviour, usage, rendering rules and platform differences, so designers, developers and AI-assisted workflows could all work from the same source of truth.

At the same time, we established the workflow between design and engineering. I managed tokens in Figma, pushed updates through Token Studio, and engineering reviewed and merged them before generating platform-specific components.

The component was finished when everyone could use it the same way.

When building the color system, I validated semantic combinations against WCAG across light and dark modes, compared the results with APCA to better understand the differences between the two models, and reviewed key screens through color-vision simulations.

Touch targets for iOS and Android were added directly to the variables used by designers, Claude Code and engineering. Each component was also documented with accessibility guidance, allowing those decisions to be inherited by new product work rather than reconsidered feature by feature.

The aim was was to make the accessible choice the default choice across design and implementation.

Once touch targets, contrast requirements and usage guidance were built into the system, accessibility no longer depended on someone checking it at the end.

Every component included its anatomy, variants, behaviour, rendering rules, platform differences and implementation notes. The goal was to remove as much interpretation as possible.

This became one of the most interesting parts of the project.

Documentation became a second design problem: what would someone need to understand the anatomy, variants, platform differences and accessibility requirements without asking me? Answering that question changed how I designed the components themselves.