Background
In 2017, I landed my first design job at DivvyCloud, an early-stage cloud security startup. Not only was this my first design role, but I was the first designer there, period. I had no design files, no design team, and a super unclear job description...unclear to me at least.
I spent my first few years designing the brand experience. Once I was asked to focus on defining product experience, I thought step one should be to build a UI Library or something, but I couldn't articulate why other than it would help make my job easier and move more efficiently.
Luckily, DivvyCloud brought on Evan Samek, a highly experienced design manager, as I started the product design journey. He was a huge believer in design systems (a concept I was hugely unfamiliar with). He believed that our newly founded design team would be perpetually handicapped without a system in place. With his support, I started exploring the creation of a design system.
Do We Really Need a Design System?
Problem
As I mentioned earlier, my design manager and I didn't have too many problems articulated. Still, we predicted that the lack of a design system would result in several design challenges on top of the current issues with the design of the application. The thought of taking time out to create a design system without a clearly defined problem was understandably met with a lot of skepticism. We decided to use some time to research design systems and communicate any benefits we find through our research findings with the broader product team. Then we could ultimately decide to move forward or not.
Research
The biggest question I had was why other people had created design systems for growing applications and how? I started by doing some major research. I read case studies, articles, analyzed other companies' design systems, and learned a lot about Atomic Design. Here are some of the resources I found most helpful:
Benefits
Through my research, I found the most relevant benefits of a design system were the following. After communicating these benefits with the product team, we determined it was best to move forward, and I was given 2 sprints (4 weeks) to create a design system's beginnings.
- Ensuring UI consistency.
- Saving Time.
- Reducing complexity and ambiguity.
- Enabling and facilitating collaboration and consensus.
- Creating a foundation for further improvement.
The Process
Before I got started doing any work, I collected any materials that could help me understand the current state of product design at DivvyCloud; so I was thinking Figma files, sketch files, font files, anything. But there wasn't much of anything to collect. Other than one project completed by a contracted designer, every product project had no high-fidelity design files, wireframes, or style guides. Projects had unique definitions based on the developers working on them, with some slight overlap.
Inventory
With somewhat of an atomic strategy in mind and an understanding of what a design system was, I decided my next step was to inventory every UI element in the application. I took screenshots of every screen, modal, menu, button, etc., and pasted them all into Figma. Then, instead of recreating each of these screenshots' components, I found a premade UI Kit then edited its components to match those from the screenshots as closely as possible.
Screenshots of different parts of DivvyCloud
Audit
Once I felt like I had captured everything, design patterns, buttons, icons, and everything in between, I grouped them into categories, side by side. This exercise made it visually clear to me why we needed a design system. There were so many different button styles, incorrectly applied font color and weights, and several single-use icons everywhere.
A few of the category groupings of UI element
Edit
I used a combination of our existing UI elements and styles from the premade UI Library to define the design system's visual language. Then I had to make major decisions about naming conventions. I spent a lot of time determining how to name my Figma pages and frames so that the components were grouped in a findable way for our team. I'd recommend reviewing this with your team early and often to ensure the naming convention makes sense for the team's needs.
A screenshot of the Figma file of the design system
Evolve
Design systems are living things meant to grow, scale, and evolve. I set weekly reminders to update and review the system and had bi-weekly meetings with the design team to review and discuss the updates. I put this in place so that as the team and application grow, we'll have a process that keeps things organized when more than one person is contributing to the design system.
Results
Christening
The design system truly became a system when we created rules and principles to use each of the components and patterns. It was during this definition period that we created the name Nimbus. DivvyCloud is a cloud security company, so we love using cloud-related pronouns. A Nimbus cloud is a luminous cloud surrounding a supernatural being or saint. We thought this name was fitting for the design system we hoped would help us tremendously, so we dubbed it Nimbus Design System.
Sharing
We used Figma as the source of truth for the design system. It provided a way to share the system with the entire team and solicit feedback and promote collaboration. The engineering team also created a corresponding server where they created working versions of each Nimbus component.
A screenshot of the Figma file of the design system
What I learned
This project taught me a lot of things. It allowed me to study design systems, collaborate closely with product and engineering, and create a design system from scratch. This design system allowed me to create mock-ups and designs more efficiently than expected. And there was a lot less back and forth about UI styles and more emphasis on UX patterns.
I did not anticipate from the Design System's creation how much more definition the elements needed for the engineering team to implement the code for them. I needed to go into much more detail when defining out the interactions for each component and pattern. My lack of doing so resulted in many impromptu meetings and conversations with engineering where I had to answer any questions and make clarifications.
Additionally, I anticipate that we will turn away from Figma being the source of truth for the system and use a tool that allows for more documentation and intuitive navigation. Although Figma worked fine as our primary design tool, we had challenges with people outside of the design team not knowing how to use Figma and not having the space to document certain principles in the system.
All in all, the design system has been hugely benedictional and has acted as a catalyst for a redesign/refresh of the application.