I led the design of and maintainence of the design system. I created assets, wrote documentation, and assisted other designers in contributing to the DS.
Design system
18 months
Caitlin Roach (Lead)
Lucas Artusi
Missy Yarbrough
Stephanie Ji
Ulrich Schroeder
When I joined RapidDeploy, one of the first things I noticed was that the usage of components was all over the place. Components from at least three different pre-made libraries where being used, without design guidance on when and where to use the various elements. On top of this, RapidDeploy did not yet have a clear brand within the suite of products.
Creating a design system was a high impact way to make a difference relatively quickly. This served to get our hands on the products in a short amount of time, as well as allowing us to start gaining a good reputation by bringing consistency and a uniquely RapidDeploy look and feel to our product suite.
Note: I cannot link or show the entire library here, but I am happy to show the Figma file and it’s setup in and interview or design conversation.
Before jumping into creating any components, I set about auditing all the different components that were currently being used in Nimbus, our largest product, and any variations of each type of component, as well as the colors used. This allowed us to have a better idea of how much change would be needed, and gave us evidence to prove the need for the design system.
Because we were starting from a point where there was not yet an established style for product within the company, we began visual design explorations, using two of our products as examples. We began with the colors and look and feel that had been defined at a brand and marketing level, but quickly realized that the colors selected would not allow our product to meet accessibility minimums, and we felt that they didn’t lend themselves to the more modern aesthetic that we wanted to achieve in product to stand out from existing products that tended to look dated.
As our explorations continued, we started to pull back on the use of color. Because of the implications of various colors in the emergency dispatching world, we needed to be very intentional with the colors we used and how we used them.
RapidDeploy’s main brand color was red, but were were concerned about the implications of red showing up in places where we were not indicating an error or other emergent state. So we moved to using the red in the logo, but reducing the rest of it’s usage to only be used in circumstances where we needed to indicate that something was wrong.
When we went back to the brand colors, we decided that we could take the blue that was the secondary color and modernize it by making it a brighter, more vibrant blue and pairing it with a primarily neutral palette.
Before any component building occurred, I started by defining the foundational elements of the design system. These included:
- Design Principles
- Page structure and grid
- Spacing
- Typography
- Color
- Iconography
In some areas of the system, we knew we would not have the bandwidth to generate everything from scratch. One of these areas was iconography. Instead of creating our own library of icons, we chose to use an open source icon library called Remix.
Once we had a set of solid foundational elements, we moved onto building components. We did this alongside a redesign of RapidDeploy’s flagship product, Radius (see more about that project here). This gave us the opportunity to start with a core set of components that we knew were immediately needed, and we could grow the components organically over time as we added to Radius or worked on any of the other products.
For each component and its variations, we wrote documentation to accompany it, for both designers and developers who would be working with or building components. This documentation spoke to usage of components, capitalization, etc.
We named each of the variants of our components in a way that reflected the naming conventions that development would use. This, combined with the written documentation, allowed our development team to go directly into the Figma library file to find names and the associated styling, reducing our need to annotate and redline components.
In addition to components, we had a section of our design system dedicated to recurring patterns of components. This included things like combined color and icon selection, modals, etc. that we used frequently throughout the products.
Due to the nature of the work our users did, and the, oftentimes, very dark environment that they worked in, we wanted to ensure we would be able to provide a dark mode option. We did not make dark mode the only option, as we heard from users that about 50% wanted light mode, and 50% wanted dark mode.
We designed the two modes at the same time, ensuring that colors maintained the same naming, and that they would be able to be switched one to one, without any accessibility or legibility issues.
Note: This is not a comprehensive view of all of the color styles used. If you'd like to see a larger portion, I am happy to show on an interview or design conversation.
We also added a section of colors that we called Universal Colors. These color styles were used for elements that did not change when switching between light and dark mode. An example of this was our navigation bar, which kept the same styling regardless of the mode a user was viewing.
While I led and was the main contributor to the Design System, I knew that it would not be sustainable long term for me to be building all of the components and writing all of the documentation alone. In order to get other designers up to speed on how to build components and their variants in Figma, I ran several sessions where we all built the same set of components, and helped them work through problems when they got stuck. I also built a file with these lessons that could be used with any future additions to the team who needed to be brought up to speed.
Unfortunately our role on this design system ended when a round of company layoffs affected the entire design team in December 2021. By that point, we had extended the library to include a set of mobile components, and local components for each product.
In the main system, we had a total of 669 components (including all base components and their variants, states, etc.). These components has nearly all been build into a coded library by our development team, and were in use in product. Those components continue to be used in RapidDeploy’s flagship product today.
