A single source of truth for a growing platform
BuildingMinds builds software for smarter, more sustainable buildings. As Design System Manager, I turned a drifting, inconsistent component library into a trusted foundation — one that keeps design and engineering in sync, while still leaving designers room to think outside the box.
Role
Design System Manager
Timeline
2024 — 2026
Scope
Design tokens, components, docs & process
The context
When I joined BuildingMinds, the platform and the design files didn't always match, and components drifted from screen to screen. But the bigger cost was hidden in conversations: the team spent huge amounts of time debating things a design system should already answer — Tooltip or Dialog? Which button variant? What spacing?
I started by listening. Designers said component names were confusing, old components lingered, states were missing, and design and platform often didn't match. Developers said the system felt outdated, documentation lacked real examples, there was no clear feedback process, and they needed variables for color, spacing and text. Two principles guided everything after that: a roadmap aligned with development, so no component ships in design before it can realistically be built; and never blocking designers, so the system defines the basics but still leaves room to think outside the box.
01 — Foundation
One shared language: design tokens
The foundation had to come first. I moved the system off hard-coded values and onto design tokens — variables for typography, color, spacing and text — which answered the developers' biggest request. We standardised on Poppins as the single house font and built a full type scale — Display, Headline, Copy, Annotation and Link — with clear, predictable names like sys.Typography.Display.lg. Every token references base tokens, so one change updates the whole system consistently. For the first time, design and code spoke the same language.
02 — The update flow
A flow that frees designers and keeps code in sync
To make the two principles real, I designed one clear flow for how any component gets updated. A designer pulls a component and asks: does it fit as-is? If yes, they keep working — no meetings. If not, they open a branch in Figma, change it there, and write a short note on what changed and why. So designers are never blocked. A developer then reviews whether the change is realistic to build; developer approval is required, which stops the "changed in design now, buildable only two sprints later" gap. After that it comes to me to check design, consistency, tokens and naming. If something is off it loops back with comments; if it passes, the branch is marked Ready to merge. I review Ready branches daily, merge them into the main system, update the changelog, and only then does the developer build it in code — aligned with what was approved.
03 — Component standards
An example: Tooltip vs. Popover vs. Dialog
Beyond the daily flow, I ran regular presentations whenever a component needed to be created or updated — aligning everyone on the definition before the work was built. One recurring debate was the perfect example: the team kept using a heavy Dialog for a simple question, or a Tooltip for content it couldn't hold. So I introduced a simple decision framework — P-C-I. Purpose: why are we showing this? Closure: what must the user do to close it? Information: how much and what type? From that, each component got a clear rule. A Tooltip is brief and passive — hover, read-only, short text, no links or buttons. A Popover is rich and contextual — click, dismissible, holds lists and links, for context that doesn't stop the workflow. A Dialog is critical and focused — it interrupts and forces a decision, for high-stakes actions, with defined types and a sizing rule. A recurring argument became a documented standard.
Reflection
The most important lesson: a design system is not a rulebook that limits people. It is a shared foundation that frees them to do better work, faster. The hard part is balance — define the basics clearly, but leave space for designers to think beyond them; move fast in design, but never faster than development can follow. When those two things are in balance, the design system stops being a source of friction and becomes the single source of truth it was always meant to be.