Product Designer · Lepaya · 2023 – 2024
Design System for Client Branding Themes
Clients wanted the learning app in their own employer branding. The design system is what made it themeable.
Roles & responsibilities
- Timeline
- Product Designer · 2023 – 2024led the initiative; built with the app development team
- Team
- Cross-functional, with the app development team building itDesign team on principles and design language, the app development team and their tech lead on implementation, and the product teams working in the system
- Collaboration
- I led, planned, and executed the initiative.The design side and the change management were mine. Principles and design language were workshopped with the design team; the app development team and their tech lead implemented it.
- Responsibilities
- •Initiative leadPlanning and execution across the design work and the change management
- •InventoryComponents and styles in use, and where they had diverged
- •Principles and design languageFocus-group workshops with the design team
- •Governance and buy-inA small decision team; CTO on technical commitment, CEO and acting CPO on timeline and investment
Design system
The inventory didn't sell it. Whitelabeling did.
I took inventory of the product and found the same component living in several versions. That evidence did not persuade leadership to fund a design system. Whitelabeling did. Clients wanted the learning app to carry their own employer branding, and putting every learner into their company's brand needed shared foundations underneath.
The system ran in three places: Figma libraries for design, the code repositories we maintained with the dev team, and a Zeroheight reference the rest of the company could read without opening a design tool.
I trained for the work while doing it: an eight-week evening course in design systems with Memorisely, and Brad Frost's five-day Atomic Design workshop through Smashing Magazine.
Key decisions
Where the work went
1. Inventory before proposal
I audited the components and styles already in use and mapped where they had diverged. The first scope covered what the product had, not what a system might ideally hold.
Result: Scope came from the product rather than from a reference architecture.
2. Principles and design language, with the design team
Focus-group workshops with the design team set the system's principles and our design language. Both were settled before the first scope was drawn.
Result: The language came from the designers who would work in it daily.
3. A small decision team, open use
Decisions stayed with a small group. Teams used the system as they needed and surfaced what they wanted standardised, and those requests came back as candidates for the system. Where a surface could not adopt it fully, we built bridging templates instead of holding the line. The developers argued for moving documentation into Storybook, which is the kind of question that follows where people already work.
Result: Standardisation followed real use rather than a roadmap.
4. The business case, not the craft case
Framed as consistency, the system competed with product work for investment and lost. Framed as the way to deliver client branding, it became product work. I argued it in those terms to leadership, then kept arguing it in those terms, because the framing had to hold every time the roadmap was reviewed.
Result: Standardisation stopped being a design concern and became the way to ship something clients were already asking for.
5. Buy-in at every level
The technical commitments took negotiation with the CTO. Timeline and investment took approval from the CEO and acting CPO. Then came presentations to the tech teams and company-wide, and the case made again in any meeting where the system served what was on the table. Governance and maintenance ran next to new product initiatives, not instead of them.
Result: The system stayed governed and in use while product work continued.
Perspective gained
Neither half was the easy one
The components took as long to settle as the approvals behind them.
Governance and maintenance don't finish either. They ran beside every new initiative for as long as I held the system.