Creating a Design System
CyberSecurity / Design System
The client was a cybersecurity company who recently shifted from a service-driven business model to software as a service. The goal was to build and implement a consistent design system to build trust in the product while simultaneously providing the client's UX designers / developers the ability to focus on solving more complex user problems. When I had finished my portion of the project, our team designed 50+ components all with established guidelines. Our client provided much positive feedback about our contributions.
I was one UX designer on a team of three other designers and a scrum master. I was responsible for requirement gathering, design explorations, writing usage guidelines, and closely working with development on specific components.
Methods & Skills
Nov 2021 - Jan 2023
At the time of the project kickoff, the company and product had been engineering-driven and their design team was less than two years old. Designers did not have any design standards to align on and not all of them had the same comfort level using Figma. Development did not always match what was designed. Components implemented were not developed the same way. There were lots of inconsistencies within design, within development, and between the two.
Contributions to the Design System
I officially joined the Design System team after foundations (colors, type, spacing) were established. I was on the project for a little over a year. During that time, I created and wrote guidelines for these components:
+ Filter Chips
+ Status Lights
+ User Avatars
+ Progress Stepper
+ Collection Cards
+ Sectional Containers
+ Inline Messages
+ Sectional Banners
+ Page Banners
+ Data Viz Illustrations
+ Logos (Branded + Third Party)
+ Key Value Pairs
+ Inline Fields
Research + Define
For each component, we would create a component narrative. The component narrative included all the component's instances and use cases in the product. We would record questions and opportunities and then meet with design and development to discuss business, technical, and user constraints. Furthermore, we determined the scope of the component and what to put in the backlog.
Defining Multiple Components
Component Narratives also helped aligned design and development on the definition of similar components. For example, below is a table I made to compare and define how we would use banners, snackbars, and inline messages. Each component includes a definition, examples from Material Design and IBM’s Carbon, opportunities of how each component can be used, and current design explorations.
The first step in designing components was to research best practices and create design iterations. Because development used Angular Material Design, we often looked at Material Design for guidance. However, we did reference other design systems like IBM Carbon and Atlassian's Design System.
Prototyping was critical for testing component interaction. We did a lot of prototyping to understand what different states would look like and test how the component would respond to changing viewport sizes.
Once a week, we would present our design options to the client, highlighting the pros and considerations of each design option. This meeting allowed us to collaborate with the client and determine the best design for each component.
Adding to Figma Library
Following the Atomic Design Methodology, we built our components by setting up atoms, base components (similar to molecules), and the main component (similar to an organism).
Because Figma was releasing new features for building components, adding components to the Figma library required some research, iteration, and testing. In the middle of our project, Figma introduced the Boolean Property. As a result of the boolean properties, there were endless possibilities for building components.
As a result, I would provide a few options for building the component and create whiteboarding spaces for my fellow designers to test each component option.
With each whiteboard space, I provided notes where my teammates would write what they liked, what could be improved, and any feedback/ ideas they had. It was a very successful way to get my teammates aligned on a direction when there were conflicting opinions.
With each component, I wrote a set of usage guidelines. These guidelines included variations, interaction states, anatomy, do's and don'ts, and more. For some of the more complicated components, I wrote instructions on how to use the Figma component.
The last step for each component was to create handoff specs for developers. The handoff included notes on spacing, text tokens, color, and interaction. We would present the specs to developers to make sure there were no technical limitations and to answer any questions.
Once developed, I would do a UI review and work with the developers on what needed to be updated. They would send us a Storybook link where I could inspect the element and do a QA test.
User Testing + Enhancements
As the Client's design team started to use the Figma components, we got a lot of engagement and feedback from them. The whole team was super open to feedback. We would record future enhancements and update each component to reflect their needs.
Filter Chips were the very first component I worked on. I thought it would be a super simple component. However because of user needs and technical constraints, I made enhancements to the component multiple times.
The product displayed almost all its feedback messages in a Page Banner. To bring consistency and meaning into those messages, I broke them down into four feedback components: Page Banners, Sectional Banners, Inline Messages, and Snackbars.
The biggest challenge with Collection Cards was figuring out how it would respond to different screen sizes. On top of that, there was ambiguity about future use cases for this component. As a result, I built the component to be as flexible as possible.
Key-Value Pairs were one of the last components I worked on. There was a multitude of inconsistencies, use cases, and technical limitations for this component. I managed to get it visually consistent and write some guidelines for responsiveness. Unfortunately, there were still some technical constraints I couldn't address deeper before leaving the project.
"Thanks for making my job easy!"
- Product Designer
"I love these simple changes. They make the UI way more uniform and make a better user experience"
- QA Engineer
"The component library and pattern guidelines have been excellent and cut down the decision making time to get a design moving forward. There is clarity when we don't have guidance, or a component/pattern is in the backlog and the work I do can inform the path for the Design System Team."
- Product Designer
"I'm just stopping by to say that the designs you all are making look amazing. I can't wait to get them all implemented. This is some of the best design/UX work I've seen in my career"
- Sr. Principal Engineer
By the time I rolled off the project, the team had created 50+ components for the design system, all with usage guidelines and development specs. In the end, the design system became a resource for all roles in the company to reference. This documentation was particularly valuable after the company reorganized its delivery teams, as teams without a dedicated design resource were able to look to the Design System for guidance on UI patterns.