Creating a New Product Design System to Match Our Rebrand

As a growing startup, things are constantly changing. From our booming customer base to expanding product lines, Abnormal Security is quickly becoming familiar with the idea of scaling. For the design team, building at scale means providing a consistent and delightful experience across our features, and thus a design system is key.

Historically we've built ad-hoc styling on top of the Ant-d component library. As a result, we faced several challenges as we attempted to manage multiple variations of our system, untangle bespoke components, and hand off our work to the engineering team—who had their own style guidelines.

So we set off as a team to create a central design system where components are consistent, variations are clear, and usage is documented. We ambitiously set our deadline for three weeks but compounded with a company rebranding, there were added layers of complexity and ambiguity. New colors? New shape language? New visual identity? How can we create a design language that’s in line with our new brand?

Before we dove deep into the weeds of buttons and font sizes, I wanted to take a step back and look at the goal direction. If we’re in a completely ideal situation, what would interface look like?

As a team of three, much of our time is spent creating solutions for the present moment. But if we took a step back, what could our product look like in a year? Or two years? My goal was to create product visualizations that captured the essence of our product brand so that we could discuss and iterate before getting into the nitty-gritty pieces.

Some early explorations looked to Crowdstrike for inspiration, since they were a great example of an enterprise look and feel that spoke precision, rigor, and sharpness. Much of our interface revolves around data and tables, so we took the time to explore unique variations on the experience.

A big question was how do we incorporate the new brand? We had the first inklings of a brand palette at the time—a few fonts and a sample webpage. V1 of the ‘North Star’ designs incorporated more of the brand vibe: straight edges, serious colors, lots of lines and grids, which you can see here.

Our V2 was a more rounded, modern style. With the input of our stakeholders, we decided to move forward with the more rounded and friendly, but still professional style. Unlike traditional enterprise email products, we wanted to take the approach away from serious and gray to friendly, usable, and modern.

According to atomic design principles, a design system starts off with its most basic units: typography and color.

Typography was fairly straightforward to set—a quick audit showed that we had specific fonts to use for headers, subheads, and body text. The main task was finding similar groups and picking a representative option for the entire use case. We ended up with the following set:

There are multiple ways to a color set for a design system, and we went through a few iterations to make the perfect decision. Some explorations are shown here, where you can see we struggled to determine if the perfect blue purple, or burple, even exists.

After a few revisions, seeing how some colors didn’t work within the application, we decided on the following set under the mixed convention of usage and color family. In addition to our main colors, we have a variety of reds, oranges, yellows, and greens that we use for alerts.

While we chose a slightly different look from our marketing brand, we wanted to be sure to tie the product in with similar colors. Drawing close inspiration from the marketing color palette, we defined our secondary set of colors for graphs and data visualizations. We set the following criteria for the palette: easily discernible from one another, colorblind (red-blue) friendly, and on-brand.

In a team session, we tried and validated different combinations to arrive at our final accessory color set, which looks like the following.

With the color and typography foundations set, moving on to more complex pieces involved a few steps:

1. Capturing all existing variations from the live product.
2. Categorizing and organizing into different types, when applicable.
3. Componentizing and determining how to incorporate it into our existing Figma library schematic.
4. Documenting and sharing across the team.

And rinse and repeat. With some components, the process was relatively quick and painless, particularly if they were simple in construction and few in variations. However, with the more complex pieces, it wasn’t rare to start work on a component and realize that it required the definition of other, smaller pieces before we could proceed. For example, with the modal component, we realized we first needed to define spacing, font, and button conventions.

While we've launched most of these changes within our product, the design team is still building out the system. We’ve moved on to the more complex components, like tables and page templates, and we'll continue to roll out these designs within the Abnormal portal.

As the main driver of this project, I use a Slack channel to share any updates or changes to components, whether it's new designs, new naming conventions, or a change in structure and how we use pieces. Our future work entails collaborating closely with engineers to bring this system to life and define how we’ll use it cross-functionally, while formalizing when and how we’ll add new components.

The design system is very much a complex entity that is alive and growing. As designers, our role is to carefully nurture and prune, and add to the system to support our product creation process. As we do so, you'll continue to see changes within the product UI, and we hope you'll love them.

For more information about our product and to see how these elements live in the final design, request a demo of Abnormal Security today.