Design System

Driving product consistency, increasing design workflow and reducing engineering workload

my role

Product thinking
Design System
Visual Design


Myself - Design Intern
Brad - Mobile Product Design Lead
Raf - Visual Designer
Ryan - Interaction Designer
Jenn - Design Intern


Sep 2019 - Oct 2019




To give a little more context to the Mobile team’s history with design systems, when I joined, the team was in the process of migrating from Sketch + Zeplin to just Figma. The SMB team was the first team to try out Figma just to test out the water as it seemed like a better tool for collaboration amongst designers and developers.


Create a collaborative design system with documented components that can be understood and used by both designers and developers.


The main problem with our existing design tools is the insufficiency from design to development handoff and the lack of product consistency.

Below is an example of what part of our design system looked like on Sketch. Each component has a name and is categorized with similar components. However, components weren't properly used by designers due to the lack of proper documentation, designers weren’t given enough context as to when/how to use them. Although different states of a component were listed, developers had trouble building components and didn’t know how individual parts of a component would scale between a smaller and a larger screen.

My role

My main contribution was to design the structure and variation + style sections of the documentation.

the old design system

Understanding Design Systems

Since this was my first time help build a design system, I chatted with Brad our product design lead (also my mentor) and did some research to wrap my head around design systems.

I started with a quick read of the Design System Handbook by InVision and learned that having a scalable design system not only allows teams to design consistently, it also allows for faster prototyping and iterations, improve usability, allow the team to scale and build accessible products. These findings really helped me appreciate the impact a well-structured design system can make on teams and helped me understand how it can help solve our problems at RBC.

While coming up with a solution for our own design system, I analyzed the Shopify Polaris and Atlassian Design System as both seem to have the level of detail we were looking for at RBC.


The intended users for this design system were both designers and developers. From conversations with the team, we broke our design system down to the following sections (I focused on component structure and variation + states)

Initial Design

Since designers could simply drag or copy and paste components onto their screen in Figma, the initial thought of documenting the components was to utilize development language. The hypothesis was that using words such as “enum”, “boolean”, “true” and “false” would make it easier for developers to understand the component build and interactions.

first iteration of documenting the structure and states of the component

Although the RBC banking app can be used on both phones and tablets, designers only design for mobile which means there’s a lot of back and forth communication between developers and designers for tablet versions.

To solve that problem, we started by laying out paddings and margins for each part of the component and showcased how they would react when stacked or enlarged. Additionally, we specified maximum dimensions demonstrating the component’s constraints.

examples of what the component looks like in various situations

Self and Team Testing

Due to the nature of an internal tool, the best way to test this product was for our team members to interact with the design system and talk through their experiences. This included trying to design screens using documented components and document new components.

While I tried it myself and asked other people to use it, I made sure to look out for several things:
- How was the component used
- Were the constraints flexible and easily understood
- Was the component documentation easy to follow

And to understand how approachable the documentation style is, I observed the following:
- How long did it take to document a new component
- Were they able to document everything they needed
- Where did the designer get stuck on


After a few rounds of trying to use the design system and documenting new components, we quickly realized:
- documenting in coding language was hard to learn and replicate
- developers had trouble understanding how each component would scale along with their limitations

As a member of the team, I wanted to ensure that the documentation style is easily replicable and understood so that current designers can understand and document components at a faster rate while future hires can easily onboard.


After a few rounds of iterating, I landed with a documentation style that was straight forward and can be applied to any component.

Here are the key result of the final design:

1) Developers are able to properly build components and thus increasing product consistency and reducing development workload

2) By forgoing the tech-y terms and simply use words and sentences to explain the constraints, Designers were able to quickly adopt this documentation style and increase design workflow

Overall, the developers and designers have found the documentation style easy to understand and replicate, allowing the design system to scale for future components.

"Ur work is immortalized in RBC forever" 
 - Raf, Senior Visual Designer (2020)
a component broken down to three parts with a description on how each part scales

Reflection and Learning

One of the big takeaways I gained from this experience was the importance of having a functional design system. Design systems not only define quality and consistency across a product, but it also provides designers with the confidence and time to focus on solving user problems by abstracting away many ambiguities. I find that nowadays, it’s hard to design without the thought of having a good design system 😅.

Another thing I learned is that designers solve problems, which can range from consumer facing products to internal tools. This was my first time designing for an internal use case which meant there was a smaller user group. However, it was important to keep in mind of future users and design for scalability.

Looking back, I’d love to involve PMs, accessibility experts, content writers and more developers throughout the process. I think it would’ve been beneficial for everybody aside from solely designers to understand the value and importance of having a design system.