Oasis: Inception of Safe Security’s design system
A design system is a reserve of reusable and consequently scalable components along with an assembly of robust design patterns that unifies and aligns all the teams for building exceptional products faster. Businesses all across the globe are instituting design systems for the powerful experience it helps provide their customers at diminished costs.
“A design system isn’t a project. It’s a product serving products.” — Nathan Curtis
I am putting together this write-up to chronicle the evolution and expansion of the design system at Safe Security which kicked off not long ago and has already given us an edge by bridging the gap between different product teams, chopping off our tech debt, and paving a smooth way for accelerated development 🚀.
Understanding and starting with the design system
Our product was strewn with inconsistencies and inescapable challenges as different teams owned different portions of the product without standardization. Add to that the inevitable new and customized designs that kept streaming in with ambiguities that were at odds with a consistent user experience.
“Once we get past the tedium of building the same thing over and over again we can focus our energy on more worthwhile tasks” — Micah Godbolt
This led us to establish Oasis, our very own design system earlier in the year where we wanted to eliminate any room for interpretation and discord within product teams. The major goal was to standardize the process of component development by normalizing the rules for directory structure, naming convention, and systemizing all the steps that are important for building error-free reusable components. Ergo, Oasis was born — a single, shared source of truth. A fertile habitat for our flourishing patterns and emerging components in the barren land of our old Safe 🏝.
Oasis chipped away the technical debt that we had incurred through ignored lint errors and non-reusable code patterns, thus adding to our maintenance overhead as the product matured. Through standardization, we were able to get rid of unused and clashing design tokens thus freeing up space for a more holistic library. Standardizing the process of building simple and complex components helped in faster iterations and experimentations where everyone could concentrate less on the design and more on providing a better overall user experience.
Building the design system
But understanding and building the design system were two different processes that involved multiple moving parts. From navigating the political waters of convincing and emphasizing the need for a design system to its actual fruition was nothing short of daunting 🤯.
The first moving part for us was assembling a dedicated team that would be central to creating the visual language we were aspiring for, which led to the formation of our very own SWAT team. SWAT had its core members coming from all the product teams, thus ensuring the right skill-set for equal stake and contribution. So, the journey began where each team started refining and implementing related user stories along with their sprint commitments.
The next step was taking a visual stock of the varying ranges of colours, font sizes, and font families that were fundamental to our product and creating our own palette for consistency and enhanced visual experience.
Now, that we had a basic visual setup in place, the next step involved an inventory of the most used and inconsistent components throughout the product for which we took the Atomic Design methodology that basically segregates the components into atoms, molecules, organisms, and layouts.
For us, unsurprisingly the most inconsistent component turned out to be the table. The product was littered with multiple variations of the same component.
Initially, we started documenting all the inconsistencies of the particular component and merging the different variants into one. Next was refining its structure, writing unit tests to give enough confidence, documenting the usage and best practices, and providing a coding playground for prototype iterations.
Continuous Process
An integral part of evolving and improving the design system at Safe Security is keeping the tests updated with each added functionality and handling breaking changes through versioning. We have also implemented a threshold for our packages’ size as overlooking increasing bundle size can land us in a heap of trouble for performance degradation.
The refactored, modular components in Oasis are more robust and have eliminated complexity by helping us cut down on hundreds of lines of code, opening better lines of communication between developers and designers, and establishing a system that is maintainable and scalable.
Oasis has helped align all the key players towards the same visual language which is of paramount importance for any successful design system. Ultimately, our journey towards building a sophisticated design system which is a continuous process has just started and will begin to take tangible shape through years of commitment and collaboration.
