2022 – present
Lessons learnt building design systems in small teams
Last updated Jul 2026
Why I wanted to share this?
⚠️ Warning: It's a long read.
I thought of putting the design system as a part of the digital transformation project since that reflects my latest skills. But deep down, I want to remind myself how far I've come—from self-learning local variables in isolation to structuring a scalable design system alongside a team. That's the story worth telling.
Not sure where to start?
Skim the images if you want the short version.
Jump to Chapters 2–3 if you want the nitty-gritty of managing a design system solo.
Read Chapter 4 to see how I scaled from working solo to collaborating with a team.
Start from Chapter 1 if you're genuinely curious about the full learning arc.
My journey concluded in 5 images
The image style is inspired by Spirited Away, a Japanese animated movie produced by Studio Ghibli that I've watched more than a couple of times since childhood.
✨ Thanks to Flux.2 Max AI for visualising each stage.
01 / 05
Chapter 1: Consumer mostly; occasionally the creator
Chapter 1
Consumer mostly; occasionally the creator
(Jun 2022 – Dec 2023)
My first encounter with design systems came in 2022 whilst designing a credential sharing platform across website and mobile apps.
We used an off-the-shelf design system for the website—think of it as a locked template. We could change the brand identity (colours, fonts, border radius), and it came with nearly every component we'd ever need. For the developer team, implementation was straightforward: minimal tweaks, ready to ship.
For the apps, the situation was different. We duplicated community files (iOS kit, Material Design) as a starting point. But those kits were never completely up to date, so I manually built components as we went—creating what we needed, when we needed it. I took care of the Android app design alongside this.
But there was a catch across all of it.
Whenever we needed to design a new feature, we were constrained by existing components. Sometimes we could tweak them to fit. Other times, we'd build something from scratch and hand it to developers with a shrug: "Here's how it works."
The frustration
The real annoyance came when I had to update the same component—same behaviour, same purpose—across different contexts: the website system, the iOS files, the Android files. I'd go through each one manually and update it one by one. Repetitive. Error-prone. A waste of creative energy.
And I kept thinking the same question over and over: Can we have just ONE design system that consolidates all the brands and platforms? Could we minimise maintenance effort and apply components with ease?
02 / 05
Chapter 2: Playground—first time being the creator
Chapter 2
Playground — first time being the creator
(Jan – Jun 2024)
In early 2024, I discovered local variables—Figma's new feature for managing component properties systematically.
The pitch was simple: declutter component library maintenance. Introduce a systematic way to organise component properties. Save time. Be more creative.
Working in a small design team, I kept thinking: What if local variables could be THE fix?
The learning curve
I watched Figma tutorials. Rewatched them. Rewatched them again.
Things seemed to make sense. But not quite. I couldn't map the tokenisation concepts to our existing component libraries by myself. And all the tutorials implied this should be a collaborative team effort—something I couldn't rally the whole team around yet.
I hit a roadblock.
So I decided to take a step back. Instead of trying to solve the whole system at once, I decided to start small and controllable. Why laser-focus on transforming the entire design ecosystem? Why not just... learn?
I pivoted. I followed some YouTube tutorials step-by-step. My first attempt on local variables was a simple interactive component: users could drag across different themes and watch everything swap in real-time. Colours changed. Language changed. Button shapes changed.
I became more confident throughout the process. I understood how variable features worked, which level to set up tokens, and how to link them to component properties.
What's next?
I was ready to experiment on the real products.
Our company managed approximately 12 university application portals for high school students—portals that had been around for 20 years, predating any design system effort. Structurally, they looked nearly identical. Logos, buttons, colours, fonts—all different based on university brand guidelines. But the bones were the same.
From a business perspective, it was inevitable: we needed a centralised library to house all these portals.
Since barely any design files existed around them, I laser-focused on one landing page as a proof of concept. My goal: showcase 2 things:
How local variables saved designers time maintaining the library
How they gave developers a source of truth to build from
And I did it. It was amazing. Colours changed by theme. Custom text swapped. University ABNs updated. Buttons adapted. When I shared it with the tech team, their reaction was instant: "Wow. We need this at scale."
The designer team was looking forward to expanding it. But then a bigger, more pressing digital initiative came down the pipeline. The project stopped there.
What shifted for me
I'd proven to myself that local variables worked. But I also hit the ceiling of what I understood.
I discovered restrictions:
Figma variables couldn't take percentage values—only numeric ones. This could cause issues with responsive breakpoints.
Boolean values confused me. I understood how to apply booleans to components, and I theoretically knew they could show/hide details (like university logos). But I couldn't figure out how to actually use them in local variables.
The 3-level structure (primitive, semantic, component) felt abstract. I'd done 2 levels—primitive and tokens—and it worked fine already. Did I really need three levels? When would I need them?
I had the confidence to build. But I didn't have the depth to scale.
I needed to learn more before I could go bigger.
03 / 05
Chapter 3
The sole creator and consumer — steep learning curve
(Dec 2024 – Oct 2025)
I started working for Teachers Mutual Bank Limited as the sole designer. Within weeks, I realised: I need a multi-brand design system, and I need it fast.
The bank had 4 retail brands back then. Every time I updated a website interface, I had to do it 4 times. It was time-consuming, repetitive, and completely unrealistic to maintain as a one-person team. I decided to build a system from scratch—but this time, it wasn't a proof of concept. It had to serve 4 retail brands at scale.
With prior experience, I had more confidence and a solid understanding of how to start from the very beginning.
The build
I created all components required for one retail brand first, then:
Website audit: Cross-checked UI with developers and graphic designers to ensure consistency across digital and print materials
Variables setup:
Primitives: all colours applied across 4 retail brands
Typography: 4 retail brands × 4 themes
Static info: names, custom intros, phone numbers
Component tokens: buttons, hero banners, menus, product cards, tags, etc.
Honestly, I did feel overwhelmed by the scale. But I was grateful for the collaborative support from teams across the business—they showed up whenever I needed help.
In the end, it worked. Typography swapped by retail brand theme. Colours swapped by retail brand theme. Component traits swapped by retail brand theme.
At one point, it even supported 5 retail brands when 1 brand got a visual identity update for accessibility reasons (preparing for the website transformation coming mid-2026). For that transition period, the retail brand had 2 themes running in parallel.
What shifted for me
I'd gained a better understanding of how to organise and structure tokens. To tackle responsiveness, I created 2 sets of text styles—1 for desktop/tablet, 1 for mobile. I also leveraged component variants strategically: "mobile size" vs. "desktop size" to make components responsive, "retail brand logo" variants to ensure the right brand appeared.
But I was aware of something: I could make this system more seamless. Responsiveness could be embedded directly into the tokenised system, not reliant on component variants. But how?
I had a feeling it involved understanding the boolean concept in local variables. I just didn't know it yet.
04 / 05
Chapter 4: Co-creator with a unicorn—steep, steep learning curve
Chapter 4
Co-creator with a unicorn — steep, steep learning curve
(Nov 2025 – Jun 2026)
As mentioned in earlier chapters, a website transformation was planned. We were going to build a design system from scratch—new look and feel, new brand identities, all 5 brands in parallel.
Before the wider design team joined, I conducted research and an internal audit to map out must-haves, should-haves, and could-haves components. Then I facilitated lunch-and-learns with stakeholders to share findings and validate assumptions.
The scope was massive. We needed extra hands across page templates, component design, UI prototypes, user flows, etc. Suddenly, I went from a one-person team to collaborating with multiple designers, each bringing different expertise. I'd be lying if I said I didn't love that shift. 🙂
Building the system: familiar ground, then deeper
We followed a similar approach to what I'd done before:
Audit: Cross-checked UI with developers and the lead graphic designer to ensure consistency between digital and print
Tokens: Set up primitives (all brand colours), typography (4 brands × themes), static info (names, phone numbers), and component tokens (buttons, banners, menus, cards, tags, etc.)
Colours: Fine-tuned with the graphic designer to guarantee visual alignment across media
This part felt familiar. But then came the next phase.
The unicorn moment
Guided by a design system expert—a senior UI designer who also codes—we elevated the system to something I hadn't imagined possible. We moved beyond basic token swapping into what I call multi-dimensional responsiveness.
What does multi-dimensional responsiveness mean?
How I think about token placement and why it matters
The alert component deep-dive
When to split vs. consolidate: the footer case study
What shifted for me
The advanced understanding of tokens finally unlocked my confusion around booleans. I went from "I theoretically know booleans exist" to "I use them to conditionally show/hide content based on state, brand, or breakpoint."
One moment that crystallised this shift: early on, we didn't have access to Figma's "slots" feature. So I learned from our senior UI designer—the coding-fluent one who guided the whole system —that we could work around this by building patterns as breakable components. We'd maintain consistency by design, but stay flexible when needed.
It was a pragmatic workaround, but it taught me something deeper about systems thinking: constraints force you to architect better. Now that slots are available, I can see how much cleaner and more performant the maintenance layer will be. Components won't need to be broken as often, page loading will be leaner, and refactors will be simpler. That's what excites me about this work —watching the tooling and thinking evolve together.
The system now supports 5 brands, 8+ mode variations—all within Figma, no plugins. More importantly, it's structured so we could add a 6th brand tomorrow and it wouldn't break a sweat.
But here's what blew my mind the most: this freed us up. We weren't constantly tweaking component variants or manually updating five versions of the same button. We could focus on the actual design problems.
We also leveraged AI to generate component documentation and usage guides — something that would've taken weeks to document manually.
What this means
For stakeholders right now: Designers spend less time on maintenance work and more time solving your problems and hitting business outcomes.
For future designers joining the team: They inherit a system that's scalable, sustainable, and actually fun to use. Less design debt. Faster prototyping. More time on research, testing, brainstorming.
All in all, I'm genuinely proud to be one of the core members who made this system happen. Not because it's perfect—no system is—but because we built it thoughtfully.
05 / 05
Chapter 5: What's next
Chapter 5
What's next
(Jun 2026 onwards)
I've used Copilot to generate documentation for components. It cuts documentation time from hours to minutes. It works.
But here's what keeps me up at night: if AI handles documentation, do I still need to understand tokens deeply? Do the months I spent architecting token hierarchies and thinking through breakpoint logic actually matter anymore?
The fear was real. Then I remember: the machine is only as good as the prompt.
Right now, I can give Copilot a vague brief and it generates decent documentation. But to give it the right brief—to know what questions to ask, what edge cases matter, what will actually help developers—that requires understanding the system deeply.
That's the skill AI can't replace. Not yet, anyway.
This is what excites me about the next phase: it's not about doing the work faster. It's about thinking smarter, asking better questions, and knowing when to trust the system and when to break it strategically.