Singpass app design system


Create a design system that can support the needs of the growing team and growing product


Project Lead

System Design

Product Design

UI Design

Visual Design


Stakeholder Management


1 x Research Lead

1 x Design Lead

1 x Senior UI Designer

12 x Engineers


May 2021 - August 2021

(4 months)


The Singpass app was going through two major revamps — a complete overhaul of the visual design language and a newly revised information architecture.

I proposed and created the Singpass app design system in conjunction with the app's new user interface and information architecture to lay a solid foundation for the growing team of PMs, engineers, and designers to build the app's new features on.


The design system was built, used, and refined continuously between April 2021 and August 2021. It was officially launched in August 2021, and it is currently used by two product teams today.


Before the design system, components lived in component libraries. Newly developed features and screens were created by referencing and inferring patterns in the live app. There was difficulty navigating Figma files to find component specifications, and there was inconsistency between what was designed and what was shipped.


The design system focused on 3 big themes:

  1. comprehensive documentation
  2. enhancing collaboration between design and engineering
  3. creating a self-sustaining system that evolves with the growing team and product.


Ease of finding design files

I re-organized all the design files in Figma so that files can be located more efficiently. For each Figma file, I created a cover template with standardized text styles. Designers can decorate the background of these covers to their own preference.

Ease of finding components

I structured the design system to have 3 big sections — foundations, components, templates.

Within each of these sections, the frames that house components have both a global and local navigation menu that is linked to the respective frames within Figma.

Robust documentation of components

Every element comes with a comprehensive set of documentation. The design guidelines were agreed upon by the design team. Each component's technical feasibility were discussed with the engineering team.

Design tokens

I implemented design tokens to ensure consistency across Android, iOS, and design.

The naming convention of these tokens had to scale across similar properties (color-10 through color-100) and had to be feasible with the languages used by both Android and iOS (camelCase).

Easy-to-use components

Each component was created with a comprehensive set of variants and its corresponding state (base, loading, icon, width) and mode (light or dark).

All of these were created in Figma using auto-layout and its variants feature.

Shared language

The name of each component was carefully considered and documented so that designers, engineers, and PMs share a single set of vocabulary when discussing components.

Onboarding team members

This new design system was a lot of new content to take in. I conducted multiple sharing sessions with designers and engineers, separately and together throughout the months to share progress and receive feedback.

I also conducted workshops with designers to mentor them on how to better build components so that they can be more easily reused or modified.


As the team was transitioning between the component library to the new design system, I created an interim version 1.5. This interim version exposed many gaps and assumptions in my understanding of what a good design system was. I was able to prioritize my focus and efforts in the 4-month timeline to develop and iterate on the crucial aspects of the design system address the 3 goals listed above.

For this interim design system trial, all the work I did were focused on the design side of the house. These changes were not made known to engineers, so there was no changes to workflows, nor visible change to the product itself.

Learning & desk research

I had informal conversations with my teammates to learn more about their design workflows and how they were using design resources then (benefits and drawbacks).

I dedicated approximately one day a week to learn about design systems. I watched talks on design systems, analyzed well-established design systems (Lightning, Polaris, Thumbprint, etc.), and read "Laying the Foundations" by Andrew Couldwell (as my bedtime story).

Informal feedback sessions with my teammates.

Attended conferences and watched talks.

Scrutinized well-established Design Systems.

Read books.

Understand engineering

I held extensive discussions with both Android and iOS engineers to understand technical constraints, how their codebases were set up, and what they needed from design/me.

These started out from well-crafted presentation decks, but slowly became just Figma pages filled with content and questions.

Casual discussions with engineers through a Figma file with filled with content and questions.

Understand & support design

There was a range of experience levels of designers in the team. As I got to know them, observed how they worked, and working together on projects, I formed a deep understanding of what types of support provided by the design system or teammates would be most helpful.

I conducted workshops to mentor fellow designers on how to more effectively and efficiently use Figma to build components. I tailored my answers based on the individual's skill level, and tried my best to structure growth for them over the months that the design system was simultaneously being implemented. Additionally, I also emphasized that I really wanted to receive feedback to improve the design system for the team.

Prioritization & trade-offs

I deprioritized the section of “copywriting” due to the short 4-month timeline. This was an area that my team did not have expertise in, and would have had too little time to learn and implement it well.

Furthermore, we used the existing copywriting principles from the first component library. The principles were still applicable to our new context.

Iterative testing

I constantly seek feedback or observe how my teammates used the system in real time because the design system was being implemented and built simultaneously. Using these data points, I continuously tweaked the design system to better suit the needs of my team.

Onboarding & implementation

Learning how to use a design system can be overwhelming without proper onboarding processes.

I paid special attention to this and designed a range of structures and frameworks to gradually introduce the system to engineers and designers in parts.

Weekly discussions & workshops with engineers

I had weekly discussions with engineers to give them updates on the design system. I also had biweekly sprint reviews to discuss the components that the engineers had built.

My design lead and I decided to move the engineering team to Figma because it made discussions and developer handoff much easier. It was also cheaper to commit to Figma than to use a suite of products.

Contribution pipelines & rotating designer-of-the-week

Since Singpass app had no dedicated design systems designers, the responsibility of maintaining and improving the design system has to be shared across the team.

Each designer takes on a "designer-of-the week" role. This designer has to vet and approve new or revised components. I created this flow to empower each designer to confidently propose new components and/or patterns. The designers should advocate for their respective work streams that uses this design system.