build
Understanding existing design operations
At Config 2023 the previous summer, Figma announced the release of
variables—their native take on design tokens. Earlier in my internship, I explored the viability of variables to accommodate the various umbrella brands tied to existing projects within Enterprise Innovation. Needless to say, variables have proven to be incredibly powerful in automating design changes across themes and devices in tandem with components and variants.
Though I am unable to share examples of the completed design work done by my colleague and me, I've created illustrations to provide rationale for the structural decisions made using variables as a framework for this design system.
Spacing and radius variables
To accommodate the scope of this work and ongoing projects, this iteration of the design system is exclusive to mobile and tablet devices. Our work with variables began with establishing spacing and radius values as two integral properties. In discussion with my design mentor and a developer on my team, we decided to proceed with
Tailwind CSS' default sizing values to support modularity across device and component types.
Referencing existing syntax, we created two variable modes for mobile and tablet devices, with tablet values scaling larger to accommodate the greater screen size:
By referencing spacing and radius values with auto layout and the 'hug contents' property, components can now switch between properties according to their respective device variable mode—eliminating the need to create separate component variants or entire libraries for each device.
Grid variables
In defining a grid system aligned with our spacing and radius properties, we used number variables for screen width and vertical padding values. By utilizing variable modes, we created four configurations to accommodate both portrait and landscape orientations across mobile and tablet devices.
Now, spacing, radius and grid variables work can work in tandem. By applying these variable modes to any frame, designers can switch between screen orientations and device types while complying with respective spacing and radius values applied to components.
Colour variables
Establishing a colour system across various variable modes was a challenge that required additional context from my mentor and other designers on my team. The biggest blocker we faced was deciding how to create a colour system that used variables to accommodate different umbrella brands and their respective visual styles. A core takeaway from the previous workshop was that it is not uncommon for leading project stakeholders to want to see a TD-branded version of existing prototypes—and under tight deadlines, manually changing styling can become tedious and take away time allocated to other activities.
Initially, we considered an approach where colours would act solely as styles, which would require creating additional component variants for each theme. While switching between variants is a viable approach, it requires designers in pods to regularly update the design system.
Before: 16 variants, 12 colour styles
This approach to colour styling would not only lead to the creation of many additional variants but also inadvertently create the expectation that all design talent on Enterprise Innovation should know how to use a design system manually, excluding specialized roles.
After: 8 variants, 6 colour variables
The method we established takes full advantage of colour variables and adopts a brand colour system derived from Tailwind CSS's numerical suffixes. When implementing the styling of an umbrella brand, the only manual input required from designers is to retrieve values for an existing base colour using the
UI Colors generator and apply these values (ranging from 50 to 950) to a new variable mode.
Component styling
Component styling does not stop at colour. To add an additional layer of customization to the design system, I introduced a component radius collection, which allows designers to adjust the radius values of components based on the selected variable mode. This collection aliases values from the preestablished radius values and references base components using the '(BC)' prefix.
