Pain № 01
No standardisation.
Designers built components purely based on their use case. No usage guides, no rules on when and how components should be used, no enforced best practices.
Design System · Singtel · 2019
Ember Design
Language System.
Democratising design capabilities across Singtel — from the 'three button problem' to a system of shared components, interaction guidelines, and a language the whole team speaks.
Fig. 01 · Ember DLS — Team trailer at the 1-year mark Singtel
Watch on YouTube The Brief
01The three button problem.
In my first month at Singtel, I was asked to 'align which button we should use.' Three buttons existed — legacy, current, and proposed — and nobody could agree. It would take a year and a Design Language System to understand why.
“What we lacked was a system of working that allowed us to be disciplined in our documentation, open in our communication, and flexible in our collaboration.
80+
Engineers adopted Ember
30
Designers aligned
18
Months of development
The Problem
02Thirty designers, zero alignment.
The design team built projects in isolation. No usage guides, no visibility into what others had built, no shared naming conventions. Developers faced the same problem — variants of the same component existed without anyone knowing.
How might we create a process where development and design can work closely together to ensure consistency and alignment by both the development team and design team?
Pain № 02
No visibility.
Designers didn't know when others had already built a component. Developers faced the same problem — variants of the same component existed in parallel.
Pain № 03
No shared language.
Naming conventions differed across designers and developers. The same component had different names depending on who built it and when.
Pain № 04
No developer autonomy.
Developers built code based on existing designs with no say in how components should function. They wanted agency in the system too.
The Process
03Three phases, eighteen months.
We started with adoption, moved to communication, and ended with quality. Each phase taught us something about what it takes to build a design system that people actually use.
Step 01 →
Inception.
Curiosity & naivety
A 3-day workshop with designers and developers reveals the core tensions — no standardisation, no visibility, no shared language for components.
WorkshopNeedsAlignment
Step 02 →
Foundation.
Discipline & friction
Building the first components, publishing to Sketch, updating the usage guide each sprint. But pushback emerges — designers are opinionated, and that's a good thing.
ComponentsAdoptionFriction
Step 03 →
Collaborate.
Openness & trust
WIP boards, newsletters, and sprint showcases create transparency. The RACI model gives structure, but the 90-day retro reveals a need for more openness.
CommunicationFeedbackGrowth
Step 04 ◉
Scale.
Craft & ambition
Motion design, splash screens, copy guidelines, and interaction categorisation push Ember from functional to premium. Quality becomes the north star.
MotionQualityCraft
Phase by phase
Built for adoption, refined for craft.
01
Phase 01 · Foundation
Lay the building blocks.
Usage guide with aligned naming, visual specs, status indicators, and usage rules. Component library for both App and Web — distributing easy-to-use patterns with new releases each sprint.
02
Phase 02 · Communication
Open the doors.
WIP boards for async collaboration, sprint newsletters for visibility, and copy guidelines co-created with the Copy Chapter. The 90-day retro taught us that gatekeeping kills adoption.
03
Phase 03 · Quality
Push the frontier.
Animated splash screens, interaction guidelines categorised into 5 groups, card transitions, and motion design — pushing Ember from functional to premium while keeping adoption simple.
The Solution
04A system that speaks for itself.
Ember became more than a component library — it was a shared language, a process, and a culture of collaboration. Here are three of the key design deliverables.
Component Playground
Download Report
Feature 01 · Micro-interactions
Motion that feels right.
As an interactive designer, I defined the micro-interactions and motions incorporated into every component. Experimentation in After Effects and CodePen produced high-level prototypes that were refined to fit our design principles.
- A5 interaction groups. Auditing all components revealed patterns that could be categorised — making motion design reusable and consistent.
- BDocumented in the usage guide. Motion specs alongside visual specs helped designers understand component behaviour, not just appearance.
- CPlug-and-play. Other designers could add micro-interactions without designing from scratch — still compliant with Ember.
Insight Building components one-at-a-time led to inconsistent interaction patterns. Categorisation into 5 groups made motion design scalable.
Feature 02 · Splash Screen
Hello in every language.
The most challenging piece — an animated splash screen that communicates Singtel's brand when users open the app. "Hello", the universal phone greeting, bridges connection. Singtel's dot motif draws greetings in different languages — celebrating community.
- ABrand storytelling. The animation uses "Hello" to communicate the connection a telco brings — familiar, warm, multilingual.
- BLottie export. After Effects animation exported as Lottie for lightweight, cross-platform use on both Web and App.
- CCultural awareness. Greetings in different languages reflect Singapore's multicultural identity through motion design.
Insight The splash screen was designed but not integrated before the team transition. The technique and approach, however, set a precedent for branded animation in the system.
Feature 03 · Collaboration Tools
A system is a culture.
Ember wasn't just components — it was newsletters, WIP boards, RACI charts, and sprint showcases. The 90-day retrospective taught us that a design system lives or dies by how open it is to feedback.
- AWIP boards. Async collaboration spaces where designers shared ideas and discussed work-in-progress — creating a design history document.
- BSprint newsletters. Regular updates to keep the wider team informed, document progress, and build visibility into the DLS team's work.
- CRACI model. A charting system to clarify responsibilities — helpful for decision-making, but refined after feedback that it felt uncollaborative.
Insight Once, I spent 2 sprints trying to align the colour of a grey divider among 5 designers. Process frameworks help, but listening matters more.
