ASTRA was already established when I joined Fluxys, but it was primarily design-led. Many decisions remained implicit, the library covered mostly basic components, and implementation required closer coordination with engineering. My role was to make the system more explicit, capable and usable across disciplines.
Audit existing design decisions and translate recurring patterns into reusable guidance.
Extend the Figma library with complex, configurable components.
Create audience-specific documentation for designers, engineers and product owners.
Connect design decisions with engineering implementation.
We were a team of three designers: two worked at product level, while I worked at system level. We reviewed complex patterns together, combining the product designers’ contextual knowledge with a system-level perspective. Product work exposed real constraints and emerging patterns. Through our shared design reviews, we identified which solutions were reusable and fed them back into ASTRA. This created a two-way relationship: product needs informed the system, and the system gave future product work a stronger foundation.
ASTRA’s primary and secondary colours had been defined as primitives, but their intended use across components was undocumented. The system did not yet have a formal design-token architecture.
Rather than treating colour as a collection of hex values, I worked with it semantically. I audited the complete component library and tagged each colour application according to its role, state and component context. I then used a pivot table to compare usage across the library.
This revealed the implicit relationship between primitive values and roles such as text, fill, border and icon. Although the work was not implemented as design tokens, the underlying method was token-like: it separated raw values from their semantic purpose, exposed recurring patterns and made legitimate exceptions visible.
Colour applications tagged by component state and semantic role, then analysed through a pivot table.
Beyond foundational components, I designed more complex and configurable patterns such as this details-page header. Nested variants allowed designers to combine headings, actions, tabs and edit states without multiplying separate components or bloating the library.
The component API balanced flexibility with guardrails: designers could configure the states required by their product while retaining a consistent structure.
A configurable details-page header built with nested variants for view, edit and tabbed states.
Much of my role involved translating design decisions between designers, engineers and product owners. I tailored each ASTRA update to the decisions and level of detail each audience needed, rather than publishing one generic explanation.
For engineers, that meant concrete implementation guidance. The example below documents the CSS configuration required to align a PrimeNG loading spinner with ASTRA’s colour tokens.
Engineering documentation for applying ASTRA colour tokens to a PrimeNG loading spinner.
ASTRA evolved from a primarily design-led library of basic components into a more explicit and capable system. Its implicit colour logic was captured semantically, the Figma library supported more complex product states, and documentation connected design decisions more directly with engineering implementation.
The collaboration model also created a clearer path from product problem to shared pattern. Product designers brought contextual needs into joint reviews, while I identified reusable decisions and translated them into system-level patterns.
The work did not replace the existing system; it made the decisions already embedded within it easier to understand, extend and implement.
STEFANOS MONASTIRIDIS
0032485654553 STEFANOS@STMN-DESIGN.COM
LINKEDIN