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. 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 in the dev department
30
Designers on the experience team
3
Pioneer designers who built Ember
18
Months from inception to handover
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.
I became aware of it in my first month at Singtel when I was given the task to "align which button we should use" by my boss. Me, being overly optimistic and significantly naive, believed that all I needed was to have the designers sit down and talk.
Needless to say this did not go as planned.
We were presented with three buttons: one used in the legacy designs, one used in the current designs, and one that was being proposed as the new designs. It was only until a year later when my new Director came in and led us on the creation of our Design Language System, Ember, that I understood what it was that we were struggling with.
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.
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. We started with a 3-day workshop with designers and developers. Through the inception, we were able to learn about what their needs were.
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. We introduced a RACI model (Responsible, Accountable, Consulted, Informed) to clarify decision-making. It helped us focus on the needs of those whose projects were more urgent. But it also left some designers feeling like we were being uncollaborative, something we discovered from our 90-day retrospective.
03
Phase 03 · Quality
Push the frontier.
We wanted to move away from focusing on aligning the team and still be able to push our design capabilities. We split our design efforts: I focused more on pushing the quality of interaction while my co-workers focused on managing alignment, refining components, and updating usage. Animated splash screens, interaction guidelines categorised into 5 groups, card transitions, and motion design pushed Ember from functional to premium.
Overcoming decision friction
A lot of times we would face a lot of push back early on. Designers, even though they were on the same team, were highly opinionated (as they should be because they take pride in their job.) This did make it difficult to get buy-in from everyone as sometimes they would disagree with the choices we would make. Once, I spent 2 sprints trying to align the colour of a grey divider among 5 designers. It is not an experience I'd recommend.
The RACI model helped us illustrate the required action from each person and by doing so, empowered us to make the decisions in order to move our project forward. This worked for a little while but it also left some designers feeling like we were being uncollaborative.
90-day retrospectives
As part of our design team's practice, we would have a massive retrospective every 90 days to understand everything that the team is going through. All 30 of us from the Design Experience team would share our thoughts. One feedback we got for the DLS team was that the team wanted more collaboration. At that point all the components were decided and made by the Design Team and we ended up gatekeeping and holding back some designers who wanted more creative freedom.
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 and still have it be 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. A design collaboration space where designers could share ideas with each other as well as the DLS team. These discussions drove asynchronous communication and acted as a design history document. It also helped the designers to feel like they have a voice and platform to share their thoughts.
- BSprint newsletters. I suggested we design newsletters that help to ensure that designers are kept informed about what we did each sprint. These were released at the start of each sprint and they helped to document our progress.
- CRACI model. A charting system that helped us illustrate the required action from each person and empowered us to make decisions to move the project forward. 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.
Feature 04 · Cross-team Adoption
Introducing Ember to 80+ engineers.
The video trailer was made at our 1-year mark to introduce Ember to the development team, which consisted of a department of over 80 engineers. It was very well received and we managed to get more developers to help contribute to the Design Language System.
- AVideo trailer. A produced piece that communicated Ember's value proposition to the engineering department, driving developer buy-in and contribution.
- BCopy guidelines. I worked with the Copy Chapter to create copy guidelines. We collated all the use cases and identified common templates such as log-in, error messages, CTAs, dates and time, form placeholders. These templates created a visual reference for designers on where and what kind of copy should be placed.
- CPlayful categorisation. We wanted a language that was easy to understand by the whole team. Terms like "Atoms, Molecules" could be confusing to some. I suggested a more playful way to talk about our components and it allowed for easier conversations and clearer understanding among designers.
Impact Ember Design Language System was absorbed by the development team after a re-org. Many of the components are still being used across Singtel projects.
