Rebuilding Our Design System
Building upon Material Design 3 for physiotherapy
Role
Design system designer & Project Manager
Timeline
April 02 - June 04
Team
3
Introduction
A design system is a collection of design decisions that are shared across a product or organization, that grows organically over time. When I took ownership of our design system initiative, I stepped into a system that had grown organically over time. Our Figma library combined elements from Material Design 2 and 3, adapted by different contributors for evolving needs. Color usage varied because there wasn’t yet a shared semantic approach, and typography and layout conventions hadn’t been formalized. Most notably, our design decisions weren’t consistently mapped to Vuetify—the framework guiding implementation—so design and engineering sometimes worked from different assumptions. My goal was to simplify, align design with development, and establish a foundation that could serve as a single source of truth for both teams.
Challanges
As a team, we were navigating a library where about half of the components supported dark mode—useful in many contexts, but not a priority for our platform at this stage or for our primary users (physiotherapists working mostly in daylight conditions). Differences in typography, spacing, and grid usage reflected the absence of common standards, which made features in our platform look as if they were made by different teams. On the engineering side, Vuetify didn’t always align with our Figma components, leading to over-head as designer and developer had go back and forth. In Donella Meadows’ language, our design system was showing the behavior of a maturing system: subsystems optimizing locally, delays in feedback between design and engineering, and reinforcing loops of inconsistency. The work presented here was part of the process to define a shared understanding and stronger source of truth in across boundaries
Design System Audit
I began by reviewing the existing files and drafting questions for stakeholders to clarify intent and constraints. When something looked unclear, I treated it as a signal to validate assumptions early—surfacing questions quickly rather than assuming hidden context. This helped us form a shared understanding of what the library contained, which areas were still evolving, and where work had paused. This mindset encouraged a shift from compliance toward active inquiry—asking not just what things were, but why they were that way.
MoSCoW
Following the design system audit, the next step was scoping. To avoid feature creep, I used the MoSCoW method to focus on the essentials and set boundaries. This created alignment around a shared roadmap and reduced the risk of scope creep
Components
Based on the MoSCoW method, I focused on the most critical components first. This ensured we had a solid foundation while allowing for future iterations. Slots allowed us to reuse components across different contexts, based on the primitives that where idetifems such as cards, tables, modals and drawers.
Simplify
I consolidated variants and reduced bloat of the unused dark-mode components to set aside for later phases. Redundant variants were merged—e.g., sixteen versions of a component became four, then two—preserving flexibility while improving maintainability. This reduced the library size by about 66%, which not only improved performance but also made the system easier for designers and developers to navigate. Fewer variants mean less decision fatigue, faster handoffs, and more consistent experiences for our users.
Tokens
With priorities set, I rebuilt the foundations around semantic, reusable tokens mapped to roles (e.g., surface, on-surface, primary, state) rather than raw hex values. This made accessibility and theming more predictable. Previously, mockups lacked auto-layout (with deep nested groups making previous screens hard to maintain) and tokens, so screens quickly became outdated whenever colors changed, and spacing had no clear standards. To address this, I introduced a small set of global type styles (headings, body, captions, buttons), spacing tokens, and grids—replacing guesswork with predictable, consistent layout patterns.
Developer & Design alignment
As part of this project I ensured that each MD3 component maped directly to its Vuetify equivalent with clear naming and aliases. I aligned Vuetify configuration (colors, radii, spacing, component defaults) with Figma tokens so designers and developers reference the same source of truth. This reduced discrepancies and gave engineering confidence that designs would implement cleanly.
Structure
We reorganized our files for clarity and scalability with support from the UX team. Instead of one monolithic file, we now use separate files for foundations, layout, components, and style guidelines. We wrote clear guidelines for properties and slots, and we set up a Teams changelog to keep updates transparent. Weekly design huddles and regular syncs with our Software Lead ensure shared ownership across design and engineering.
Documentation
To enusre that knowledge was not lost, I created a documentation page that outlined the design system's structure, components, tone-of-voice and tokens. As well as common patterns and best practices for our user groups.
Reflection
Beyond the technical outcomes, this project deepened my relationship with engineering. By collaborating closely with our lead front-end developer, I gained a clearer perspective on how they viewed the Vuetify config file—essentially a parallel to our Figma library, a collection of pre-defined Lego pieces requiring no extra styling. Understanding this perspective helped me reduce trivial back-and-forth questions and instead focus on meaningful collaboration. The design system became more than a library of components; it became a bridge between disciplines, fostering trust, empathy, and shared responsibility.
Written in collaboration with ChatGPT-5