As Design Manager at GoodWorker (Temasek JV), established design coherence across Worker and Employer apps by building a token-based system from zero. Created shared components, documentation, and processes that reduced design inconsistency and cut time-to-hire by 25%.
Liked this project?
Let's talk about what we can build together.
About GoodWorker
GoodWorker is a joint venture between SchoolNet and LemmaTree, a Temasek subsidiary — India's attempt at a full-stack platform for blue and grey-collar workers. Jobs, learning, finance, insurance, housing. Two apps. One workforce. Real social stakes.
When I joined, we had two apps in active development and two designers who understood them. That's it. One senior, one junior. All of it lived in their heads: what components existed, where they lived, why decisions had been made. Nothing else was legible.
What existed on paper was a sticker sheet. Components with no naming conventions, no documentation, no structure. Multiple Figma files with no hierarchy between them. The Worker app and the Employer app were already drifting from each other visually because there was no shared reference stopping them.
We were about to scale.
What was my role?
Startups have a standard objection to building a design system early: we're moving too fast, we'll rebuild in six months, it'll slow us down. GoodWorker was exactly that environment. New features every month. Plenty discarded. No settled product direction. The experiment hadn't resolved yet.
The objection wasn't wrong. Design systems done badly do slow teams down. A six-month build for a product that might pivot doesn't make sense.
But there was a problem with "we don't need it yet."
The entire design context of a two-app product lived in two people's heads. We were hiring. Every new designer we brought in would join a system only two people could read — no documentation, no named components, no shared library, Figma files that made sense if you already knew the answers. That's not a design problem. That's a knowledge infrastructure problem.
I made the case for building the system not because it was best practice, but because it was the only way to scale. Without it, every new hire would either slow down while learning through osmosis or make independent decisions and add to the chaos. Either way, we lose.
The case landed. We built.
The challenges we faced
As Design Manager, I built the design system from zero across the GoodWorker Worker app and the GoodWorker Employer app. Token architecture, a shared component library, naming conventions, documentation, a review process, and getting a team of seven designers to actually use it consistently.
The structure followed atomic design — four tiers, each with a defined scope:
Foundational Elements — Colors, typography, spacing, grids. The shared token set both apps drew from. This came first because everything downstream depended on it. One source. No duplication, no drift.
UI Components — Forms, alerts, modals, buttons. Every component built in states, documented, reviewed before it went into the library.
UI Modules — Complex, function-specific kits assembled from components. Navigation, job cards, application flows.
Templates and Concepts — North-star direction work. Concept explorations for new flows, tested before committing to production direction.
Tokens were the foundation that made the rest possible. When both apps draw from the same token set, a brand color change is a single edit, not a hunt-and-replace across two libraries. Same for spacing, radius, typography. The system scales because the decisions live in one place.
How did we go about it?
The craft problem was manageable. Token architecture, atomic structure, component naming — these have playbooks. The harder problem was coordination.
Seven designers. Two products on potentially different product tracks by Wednesday than they were on Monday. Every designer making reasonable local decisions. But no shared reference. Components got recreated from scratch. Naming was inconsistent. Developers were getting different specs for the same element depending on who'd worked on it. What looked like individual design quality problems was a systems problem.
Governance under shipping pressure breaks in a specific way. Reviews fall behind because shipping doesn't. The backlog of unreviewed components grows. The process gets abandoned the first time a deadline tightens. If it has any friction, it won't survive.
So the process had to be lightweight enough to survive a sprint, and tight enough that things didn't slip through.
Ways of Working
Daily huddles and weekly design reviews. The process we landed on gave each designer ownership of their product area while keeping the system clean.
The rules were simple:
We also documented the boring stuff: how to name and structure Figma files, how to share work with dev, how to handle version history. Named snapshots at system milestones. Branching for component proposals before they hit the main library — same logic as a code pull request. Propose, review, merge.
Document hygiene rules aren't interesting to write. They're worth writing.
Design Document Rules
Both apps shipped from a single token set. Dev handoff was consistent because naming, structure, and component states were shared across both products. A developer looking at a Worker app spec and an Employer app spec was working from the same vocabulary. No translation step. No back-and-forth to clarify which button is which.
The library went from 1,000+ scattered, inconsistent components to 130+ reviewed, production-ready ones. That reduction wasn't just cleanliness — it was an adoption move. When designers can find the right component in under 30 seconds, they use the system. When they can't, they build their own.
The review gate cut dev-side rework significantly. Components that previously came back for revision multiple times shipped correctly on the first handoff once they'd gone through review. Shared token names meant specs were unambiguous at the point of handoff.
Seven designers worked from one source. Onboarding a new designer to the library took roughly a day — not weeks of shadowing and tribal knowledge transfer. The system solved the knowledge infrastructure problem it was built to solve.
Time-to-hire on the employer side dropped 25% after the hiring flows were redesigned. That work was enabled by the system — the foundation wasn't being rebuilt every sprint, so we could move fast on product design without re-litigating decisions that should have already been made.
The governance process worked, but it was heavier than it needed to be. A better version would have async review for straightforward components and reserved synchronous time for anything structurally new. Not every component needs the same gate.
The backlog of unreviewed components was always the risk. We managed it. A cleaner rule would have been: if it's not reviewed, it doesn't ship. Enforcing that would have required more product buy-in than we had early on. We eventually got there, but later than we should have.
The clearest lesson: a design system for blue-collar job seekers across India doesn't need to be clever. It needs to be consistent enough that a worker in Bihar and an employer in Bangalore are looking at the same product, not two apps that happen to share a logo. Every shortcut under deadline pressure is a shortcut away from that consistency. The system isn't a nice-to-have. It's what makes the product trustworthy at the edges where nobody's watching.
UI Design System: Our design system is based on the atomic design theory, meticulously divided into four key parts for a comprehensive approach: Foundational Elements, UI Components, UI Modules, and Templates.
Foundational Elements: Establishing the core principles and visual language of our design system, these elements form the foundation of our UI design approach.
UI Components: Providing reusable building blocks, these components ensure consistent and cohesive user interfaces throughout our digital products.
UI Modules: Enabling seamless integration of components into larger functional units, these modules enhance the scalability and flexibility of our design system.
Templates and Concepts: Offering pre-designed layouts, these templates facilitate efficient and consistent design implementation, streamlining the design process.
Harmonious Design Experience: Our systematic approach ensures a scalable and harmonious UI design experience, promoting a unified look and feel across all our digital products.
Comprised of basic essential elements, like colors, typography, grids and spacing, the building blocks for an uniform approach
Building blocks for app design, simpler individual components like forms, alerts, modals and buttons, mostly in variations of states.
These are the defined UI modules, specific kits of complex blocks for the app design, designed for a specific function.
Concepts for better user journeys, refreshed look, scalable variations, optimised flows and an overall “North-Star” direction.
Style Guide and UI Library
Our Style Guide and UI library serve as essential resources for maintaining consistency and coherence in design. They provide guidelines, components, and UI modules that empower designers to create visually cohesive and user-friendly interfaces across our digital products.
Concepts+Templates
UI Templates and Concepts provide pre-designed layouts and visual frameworks that streamline the process of creating consistent and visually appealing user interfaces. These ready-to-use templates offer a foundation for designing intuitive and user-friendly experiences.
