Clover Design System
Building a scalable design system for a low-tech company
Clover is a multi-national financing company. In the midst of COVID, their operations struggled to transition to remote. To adapt to this new model, their management decided to build a suite of online apps. We are tasked to create a versatile design system that can be abstracted to their suite of applications across platforms.
My Role
I led the discovery process to understand the client's present and future needs for their suite of tools. I also worked with a junior designer to craft the design system and create mockups of different use cases for the design system. I assisted my junior designer in documenting the design system.
Project Team
Me, Design Lead
Karin, Designer
Jimmy, Product Manager
UI Audit without UI
The first step of building a design system is to take inventory of all the UI elements needed. However, because our client has not developed any tools yet, we have to start by defining the products and their major functions.
Without creating the actual product, we derived the main features of each product by writing user stories and designing rudimentary flows. By then, we could list the basic UI components user needed to interact with.
Major user stories of the three products outlined and discussed with client to build a common ground for the design system
Choosing Our Atoms
The suite of apps is cross-platform. Some even have components that are embedded in Microsoft Office and Google Workspace. We were also tight on schedule and engineering resources. Instead of building our own atomic system, we decided to build on existing systems.
Tailwind for Web, Native App, Desktop App and Google Extensions because it supports React; Fluent for Microsoft Office Add-in
But how do we make two systems look and feel the same to use? We only used atoms that exist in both systems, standardize the color palette and typographic hierarchy, and define common rules on how one might use the atoms on different platforms.
Each atom has a guide for what occasion to use the atom and important rules to implement the atom in design
Mocking our Molecules
We combined atoms to form molecules and organisms, or the UI components we outlined in our fictional UI audit. While there is still no concrete user flow for any of the applications, these UI component mockups show how the applications can look and feel consistent, even though they are under different products and across multiple platforms.
During this process, we also defined behaviors for components under different screen sizes and dimensions. Experimenting with responsive design of the components also help us modify our atoms to fit even more needs.
Documenting the difference in appearance for a molecule under different breakpoints
Documenting molecules that behave differently under different breakpoints
Constant Adaptation
When it is time to design our first product in the suite, a email management system, the design system sped up the process and gave us confidence of consistency. However, there were still many adaptations to be done and custom elements to design for a small number of features.
Modifying button layout that is originally for desktop to dropdown for better visibility in the mobile breakpoint
Because atoms can be mixed and matched to create molecules, there is infinite extensibility to cater for all UI components needed in the user flow outlined, or new user flow created later
Documenting for all
There are two types of users for this design system: developers for the suite of applications we are developing, and designers who will extend this design to other applications in the future. Because of their different needs, we created a Figma library for designers and a design guideline for developers.
🙌
Special thanks to Karin, our junior designer, who took lead on structuring the Figma library and compiling a technical guideline on all our atoms components
Design library for designers, with molecules and variants set up and expandable
Design guide, with annotated dimensions and redlines, and code handoff via Figma, for developers
Designers using our system to abstract to other applications tend to duplicate our components and create their own styles. But that will violate a single source of truth for the system and create many redundancies when more designers get involved. Instead, we chose a Master-variant structure to present our components
Other designers can edit the master and create new variants for their uses, avoiding creating molecules that are similar to each other
When others designers need to build on our system for their nuanced needs, they can stack new atoms on top of an existing Master component, and create instances to fit their needs. This retains flexibility while ensuring that the system scales minimally.
Other designers can expand the system by creating new variants of a master molecule
Developers using our system do not need extendibility. Therefore, we provide the technical guideline for our atoms in our system, along with the Figma code inspect function for reference. Each application will have a separate component library and technical guidelines to implement the application-specific component.
Each technical guideline includes the dimensions and implementation of the atom, plus states for the atoms
Outcome and Impact
Clover tasked us to create a design system that is versatile and extendable to multiple internal products. What we have created is the solid foundation of a constantly evolving organism that helps Clover thrive in this remote-first environment.
8 → 3
Weeks to design an internal application
3
Products created across 6 platforms
What I learned
Design abstractable, scalable systems to save time
Working on a design system from scratch made me realized the importance of thinking not only in features but in systems. Principles of system thinking such as abstraction, interoperability, interdependency, scalability, when used well, can reduce our work while also cater the dynamic needs of users.
Rather than thinking about how users will go through the product step-by-step, I now think of how user's actions and needs relate to each other, and how interactive elements in the product can relate to each other.
Design to communicate, not just to deliver
Much of our work in this project focuses on co-creation with our client because we did not have a clear project brief. Clients feel intimidated to raise concerns and feedback on polished designs. Hence when we start mocking up molecules, our clients were not happy with the results.
We moved back to low-fidelity designs like user flows and sketches. These empowered clients to tweak user flows, voice out suggestions, and even sketch their own wireframes with us. Co-creation with low-fidelity designs brings us to solid common ground to launch our work on the high-fidelity design system.