How can I create a design system that is simple, scalable, and understandable by designers and developers?
When I joined SearchEye as the only designer on deck, I suddenly had huge responsibilities placed on my shoulders. I was my own senior. I got to call all the shots. Seeing the lack of parity between the designs and the actual code, it was high time for a concrete design system.
Many of the pains I encountered designing SearchEye’s platform was knowing how to address the inconsistency between my designs and the live application. Could it be that the developers were working with different assets? To validate my suspicions, I did a quick site audit. I discovered that not only were the assets widely different, there were so many variants of buttons, badges, and other components.
I wish I was born with the ability to create design systems. When I started, I had no idea how to organize all my components. Luckily many great companies like Shopify, Apple, and Google’s design systems are public for me to learn from. However, these design systems were huge and served more as an inspiration rather than a guide. What really helped me level up was incorporating Atomic Design principles.
Looking back at the original problem at hand – How can I create a design system that is simple, scalable, and understandable by designers and developers? – I realized that the needs of the developers were going to be just as important. I got a front-end designer to collaborate with me on the design system. With her help, we could included tokens, CSS class, and code snippets directly to the Figma file. This was a quick way for both of us to get educated on how we think and communicate.
Although I am the only designer, I knew the startup would house more designers in the future. The system will expand and be used by multiple people. What helped me keep elements scalable was sticking to atomic design principles, using nested components, and using component properties to simplify variants. It’s still an on going learning experience to identify which components will be needed for reuse and which elements are specific for edge cases.
The design system is still in progress, and constantly being iterated on. With the new components that were implemented, has it improved the overall product? My dev team gave me some insights into what was working and what wasn’t
As the design system grows, I hope to create more standardized assets that can be reused in many ways. I hope to break down the the components and document them with how the component behaves within the context of any frameworks that the developers are using (E.g. Bootstrap).
As the design team grows bigger, I hope to collect feedback from a designer’s perspective on how the system has improved their workflow and onboarding. And on the flip side, I’d love to collect feedback on how the design system can be improved to better serve the purposes of the design team (i.e. what’s the best way to document components and display guides and instructions).
As the design system slowly gets implemented, I look forward to seeing if it continues to keep the design consistent. I would love to implement a survey on how the team interacts the design system on a day to day, and how that has increased their work speed and productivity (or not).
