TL;DR

Problem statement: How might we make the design system more usable?

Impact: (Estimated) 10% faster workflow for 7 designers using new components built with Auto Layout.

My role: Planned and project managed the design system migration; redesigned and reviewed existing components.

Learnings: Estimation based on capacity is important to manage expectations and energy. Invest early in team-wide tools. Promote collaboration at every chance.

UX Design Skills

Context

When I joined StashAway, it already had a structured design system (DS) that clearly specifies:

• Colours (across 3 themes: light, navy and black)

• Spacing

• Typography

• Iconography

These building blocks were combined to form the various mobile app components. See below for visuals to get a sense of what the design system looks like. (Shoutout and kudos to Alvin our awesome OG designer)!

The design system is collectively owned and maintained by all the designers.

Pain Points

While the catalog of mobile app components was extensive, it wasn’t always easy to find the desired component among the choices. Discoverability 🔍 could be improved in both the naming and the layout onscreen.

Our components had been created before Figma released Variants and upgraded their Auto Layout features. This meant that designers still had to do annoying little manual adjustments to adjust for text length or alignment on components that really took up time. 😱

Secondly, the components had also been created with static colours that, while visually correct, weren’t able to be picked up and converted dynamically by our theme-switching workflow. This meant that it was again manual for designers to switch colour themes between light, navy and black. 🎨

Furthermore, the design system was not completely in sync across Product Design and Tech: there were small discrepancies in implementation and naming 🔥 when comparing the design system and codebase. We needed a solution to ensure a single source of truth from design through development, to work more efficiently together.

My Role

I led the product design team of 4 (including myself) on this project. The team has since grown to 7 designers.

I planned and project managed this design system overhaul alongside my other feature work (e.g. StashAway Plan for financial planning tools, Habits, etc which you can check out as case studies.)

All the designers including myself were involved in working on components and reviewing other designers’ contributions to the design system.

Timeframe

The project from the initial planning to publication of the new components took approximately 6 months. All the designers were juggling design system contributions alongside squad-level feature delivery work, so we were generally devoting 5% to at most 10% of our individual capacity to this.

This project is still ongoing since we are always adding to the design system when there are new use cases.

Project Planning

How to approach a big project? I began by creating a rough project plan and breaking down the approach into 4 stages.

1. Information architecture and naming of components

2. Convert existing components to new auto-layout and variants

3. Update working design files & master files

4. Updating patterns in Design system guide

Carving up the project into chunks helped me work backwards from the desired outcome for better estimation. I was also better able to manage the team’s expectations about what was in store.

Information Architecture

After I shared my high-level project plan, the team was pretty excited to get going. However, I wanted to ensure that the effort was organised and would actually address our pain points. Hence, we started from how the components were organised and named in order to be able to split up the work logically.

Discoverability was one of the main pain points for both designers and developers and it made sense to start by relooking the information architecture of the components. I did an audit of all the components and proposed a modified information architecture and naming to the team.

We had also wanted to improve documentation of where and how each component was used. Hence, I proposed that in the new DS each component should have its own page where we would have ample space to compare the variants, and also showcase actual examples. See below for an example page (Badges).

Prioritisation

Since there was a long list of components, I also proposed a prioritisation of which components were High, Medium or Low in importance so that we focused our attention where it mattered most.

Communication

To keep everyone aligned, I created a Notion page for the project plan and documentation. This was the source of truth to keep the team and also any interested parties (e.g. product managers, developers) informed. I also captured meeting notes here in the doc for reference.

I also organised biweekly Design System 2.0 meetings where we could discuss our ongoing work, figure out solutions to roadbumps, or propose process improvements. Since everyone was still working from home, it was good to have synchronous discussions where we could *feel* like we were working on this together as a team and banter a little, share our respective thought processes and challenges. (I enjoyed this the most about this project!)

Asynchronous communication took place through Slack, I also set up a dedicated Slack channel #design-system-2 and created a workflow form to make the review process more efficient. To minimise repetitive questions, I also proposed a design system submission checklist ✅ to help everyone consider standard criteria before submitting their components for review.

See below for the visuals.

Impact

10%

Estimated 10% improvement in designer efficiency through the adoption of more discoverable and more powerful components.