
Astro (not to be confused with https://astro.build/) was Magnetis' open-source design system. I joined Magnetis and the project after its first version was already established, initially working on improving the accessibility of the existing system and later leading the development of a new React-based version called Astro Galaxy.
The original Astro had been created alongside Magnetis' rebranding as a way to bring the company's visual language into a shared system that designers and developers could use across different products.
One interesting decision was that Astro wasn't tied to a JavaScript framework. Components were documented around HTML and CSS, with predictable classes and modifiers that could be used regardless of the web framework an application was built with. That made the system relatively easy to introduce into both newer and older parts of the product.
By the time I started working with Astro, the foundation was already there. My work started with a different question: how could we make those components more accessible?
Improving accessibility
A design system is a particularly useful place to work on accessibility because a change to one component can improve every place where that component is used.
Instead of relying on every product team to remember the same accessibility requirements whenever they built an interface, we could address some of those decisions directly in the system.
I worked on reviewing and improving Astro's existing components with accessibility in mind. That meant looking beyond how components appeared visually and thinking about how they behaved for people interacting with them in different ways.
There are limits to what a design system can guarantee, of course. An accessible component can still be used incorrectly by a product team. But the system can provide a better starting point and make the accessible implementation the easier one to reach.
From Astro to Astro Galaxy
Later, we started working on a new version of the design system called Astro Galaxy, and I led the development effort.
While Astro was intentionally framework-agnostic, Galaxy was built around React. Rather than giving developers styles and markup conventions to compose themselves, we could expose the design system through reusable components with APIs that were closer to the applications we were building.
A button, for example, was no longer just a set of classes and modifiers. In React, its variants, states and behavior could become part of the component API itself.
That gave us more control over how components were implemented and made the integration with our React applications more natural.

The cross-platform experiment
There was another reason we were interested in moving in this direction: Magnetis also had a mobile app built with React Native.
Since both environments used React, we wanted to explore how much of Astro Galaxy could be shared between our web applications and the mobile app.
On paper, that was an appealing idea. If the same design system existed across both platforms, perhaps we could share more than colors, spacing and typography. Components, APIs and some of the implementation itself could potentially move between web and native as well.
In practice, that turned out to be harder than we expected.
React and React Native share a programming model, but they don't share the same platform underneath it. The primitives available on the web are different from those available in a native application, and components that looked equivalent from a design-system perspective didn't necessarily have equivalent implementations.
Trying to hide all of those differences behind a single abstraction could also make the system more complicated rather than simpler.
We did manage to explore some reuse between the two, but it didn't work as completely as we originally hoped. I left Magnetis while Galaxy was still evolving, so I didn't get to see that experiment through to its final form.

Developer experience
One thing Astro already did well was treat developer experience as part of the design system.
The original system deliberately kept its API simple. Classes followed predictable naming conventions, variants and sizes followed the same patterns, dependencies were kept small, and the documentation covered not only how to use the system but also how to contribute to it.
That thinking carried naturally into Galaxy.
Changing the implementation to React didn't remove the adoption problem. If anything, having a component library made API design even more visible. Developers needed to understand what a component did from its name and props without constantly having to inspect its implementation.
There was always a balance between providing enough flexibility for real products and creating so many options that the system stopped being a system.
That was something I'd already encountered while working with design systems before Magnetis, but Astro Galaxy gave me another perspective on it. A design system isn't successful just because its components are technically reusable. They also need to be understandable, predictable and easier to use than rebuilding the same thing locally.
Lessons learned
Working on Astro and Astro Galaxy changed the way I thought about reuse.
With the original Astro, reuse mostly meant sharing design decisions, styles, conventions and documentation across applications. Galaxy pushed that idea further by trying to share actual component implementations, including across web and native.
Those aren't necessarily the same problem.
Sometimes sharing the design language and the API of a component is more valuable than forcing its implementation to be identical everywhere. Two buttons can belong to the same design system, expose similar concepts and behave consistently for users while still requiring different implementations on different platforms.
The accessibility work also reinforced why I think design systems are such a useful place to address accessibility. Product teams will always be responsible for how they put an interface together, but the design system can remove a lot of repeated decisions from that process.
Looking back
Astro Galaxy didn't reach every goal we originally had for it while I was there, particularly around sharing components between React and React Native. But that's also one of the reasons I still find the project interesting.
It was an opportunity to work on an established design system from two very different directions: first improving what was already there, and later exploring how it could evolve into something new. Even though I left before Galaxy was fully realized, the work we did on it remains one of the more interesting design system projects I've been involved with.
Magnetis Astro is no longer available due Magnetis being acquired by BTG Pactual, later in 2023: https://latamlist.com/btg-pactual-acquires-brazilian-fintech-magnetis/