Foundations

Developing a UI Kit and theming with Material UI

challenge

The digital learning platform was full of visual inconsistencies, UI bugs and implemented far from original design specs. After some conversations and spelunking into the front-end code, we found several culprits:

  • The “hand off” process was loose and lean. Devs often didn’t have the information they needed to implement a component properly, and ended up making many (wrong) assumptions.
  • It wasn’t easy to derive what you had to code from figma files. Many developers were creating custom components instead of reutilizing existing ones, or they would import Material UI components and add one off overrides.
  • Most of the design system (in figma and in code) was referencing raw values (33px, 1em, 80%, 10vh) without tokenization, leading to a lot of inconsistency throughout the design system (in figma and in code).
  • Some devs weren’t very passionate about the finest details of UI implementation. They felt that UI work was tedious and stood in the way of more rewarding work.

This foundation was ripe for future problems: this unnecessary bloat and fragmentation in the component library meant more code to upkeep, thus increasing the likelihood of future visual bugs and inconsistencies (as the world around us keeps changing).

I was charged with taking lead of the UI Kit project. I started closely working with the dev team (as a UX engineer myself contributing to the flow through code) to turn this fragmented and inconsistent implementation into a lean, cohesive and reusable design system. One that scales with the product.

scope
Design Systems
UX/UI
process

After diving deep into the implementation of the designs, it was obvious that the team was operating on partial information & losing time creating things from scratch. We needed to reduce the number of components that were being utilized. We needed leverage MUI’s global theming capabilities, create set global components, and reduce styling in future implementations.

The more I digged, I realized that we also needed a shared language between design and engineering. Tokens in Figma needed to match tokens in the front-end. We needed a global design system and to use atomic design principles, not just in code but also as a design team.

Through this close design <> engineering collaboration, we started executing on the UI Kit project together:

  • We audited all designs to reduce design variations and minimize number of components. We made sure that all deviations from existing components were adding value for us to incur the cost and our users the cognitive burden.
  • We exorcised one-off overrides and custom components from our process — in our entire refactoring of the application’s design system, we didn’t come across one single use-case for creating a true custom component from scratch.
  • Parametrize almost everything: we leveraged figma variables to create tokens which we would then reference in code using the same naming conventions.
  • We created a global theme for colors, typography, spacing, widths, using MUI’s theme provider .
  • We created global component overrides using MUI’s createTheme, enabling atomic styling of the components through color, type, and spacing tokens. We set default properties so future implementations of a given component followed our standards.

After diving deep into the implementation of the designs, it was obvious that the team was operating on partial information & losing time creating things from scratch. We needed to reduce the number of components that were being utilized. We needed leverage MUI’s global theming capabilities, create set global components, and reduce styling in future implementations.

The more I digged, I realized that we also needed a shared language between design and engineering. Tokens in Figma needed to match tokens in the front-end. We needed a global design system and to use atomic design principles, not just in code but also as a design team.

Through this close design <> engineering collaboration, we started executing on the UI Kit project together:

  • We audited all designs to reduce design variations and minimize number of components. We made sure that all deviations from existing components were adding value for us to incur the cost and our users the cognitive burden.
  • We exorcised one-off overrides and custom components from our process — in our entire refactoring of the application’s design system, we didn’t come across one single use-case for creating a true custom component from scratch.
  • Parametrize almost everything: we leveraged figma variables to create tokens which we would then reference in code using the same naming conventions.
  • We created a global theme for colors, typography, spacing, widths, using MUI’s theme provider .
  • We created global component overrides using MUI’s createTheme, enabling atomic styling of the components through color, type, and spacing tokens. We set default properties so future implementations of a given component followed our standards.

We added color tokens for text, background, foreground and borders to our Figma workspace.
We added integer tokens for spacing, border-radius, heights, and widths
We added the same tokens in the front-end code. Enabling designers and developers to speak the same language.
We styled components at a global level, making them reusable across the whole platform.
We wrapped the theme around the whole platform, so all current future implementations inherit the design system.

lesson & insights
  • Design artifacts (ie figma files) should match what we are expecting to see in code. Nobody can keep hundreds of variable values in their mind. Speaking the same language enables us to communicate better.
  • Design “handoff” as a term should potentially be killed. Designers and engineers should be working in consistent close collaboration to build stellar front-ends; ideally, designers and engineers are equally aware of component costs and code complexities around the implementation of the UI Kit.
  • Flexibility is essential when creating components. Creating variants  can help serve the most important use cases in a product. The number or variants can grow in parallel with a product needs. This provides flexibility for future implementations while keeping the component library small.
  • If a team doesn’t have visually passionate and design-minded developers, working with a UX engineer to fully deliver UI Kit components for devs to implement into the front end should significantly speed up development.
  • Design artifacts (ie figma files) should match what we are expecting to see in code. Nobody can keep hundreds of variable values in their mind. Speaking the same language enables us to communicate better.
  • Design “handoff” as a term should potentially be killed. Designers and engineers should be working in consistent close collaboration to build stellar front-ends; ideally, designers and engineers are equally aware of component costs and code complexities around the implementation of the UI Kit.
  • Flexibility is essential when creating components. Creating variants  can help serve the most important use cases in a product. The number or variants can grow in parallel with a product needs. This provides flexibility for future implementations while keeping the component library small.
  • If a team doesn’t have visually passionate and design-minded developers, working with a UX engineer to fully deliver UI Kit components for devs to implement into the front end should significantly speed up development.
  • Design artifacts (ie figma files) should match what we are expecting to see in code. Nobody can keep hundreds of variable values in their mind. Speaking the same language enables us to communicate better.
  • Design “handoff” as a term should potentially be killed. Designers and engineers should be working in consistent close collaboration to build stellar front-ends; ideally, designers and engineers are equally aware of component costs and code complexities around the implementation of the UI Kit.
  • Flexibility is essential when creating components. Creating variants  can help serve the most important use cases in a product. The number or variants can grow in parallel with a product needs. This provides flexibility for future implementations while keeping the component library small.
  • If a team doesn’t have visually passionate and design-minded developers, working with a UX engineer to fully deliver UI Kit components for devs to implement into the front end should significantly speed up development.

Say hello

Let's connect and collaborate to make great things happen! Use this form  or drop me some lines at copy

copied!

Send
feather
Thank you! I'll be reading your message soon.
Oops! Something went wrong while submitting the form.