Summary

Plainsight allows you to collect data, build datasets, train, and deploy high-performing models all in the same platform. Shortly after I joined as the Director of UX, I uncovered an opportunity to drastically improve the efficiency for how we build mockups and achieve a consistent look and feel in our product.

The end result was a new design system consisting of robust documentation, 30 interactive components and 67 color and type styles that took full advantage of Figma's updates to components, properties, and variants.

My goal was to build a flexible and efficient system for designers that maintained parity with our front-end tech stack and brand identity.

Early learnings

We have a design system?

Plainsight had been operating without a product designer for a few months, and I didn't have the luxury of a smooth handoff from the previous designer when I joined back in August of 2022. I set up 1:1s with various stakeholders at the company during my first few weeks to get to know the team, gather context, and understand how I could make an impact.

One of the themes that emerged from my conversations was that we were not consistent with how we surface errors in our platform. I dug a bit deeper with our front-end team and learned they would often times build one-off bespoke UIs for things like modals and card views. This was strange, because the team had a working design system, however it wasn't being used to its full potential. I also learned that the front-end engineering team was not a part of the creation of the design system and only 1 of 4 engineers knew it existed!

Our existing components were brittle

I spent some time exploring the existing system to get familiar with what was in place. After using the existing design system in Figma to build a few mockups, I quickly realized the system was very brittle and not set up for efficiency.

This isn't a knock on the previous designer, however, Figma has invested quite a bit in design system feature improvements over the past several releases that simply weren't being taken advantage of.

Designers need to spend unnecessary extra time formatting buttons, tabs, banners, and more to fit the copy.

Conducting research

Auditing our platform

I had been at Plainsight for just a few weeks at this time, and I wasn't very familiar with the existing platform. I spent some time learning core workflows while also keeping an eye out for inconsistencies and opportunities to standardize. For example, I learned we had over 12 unique looking modal UIs!

I learned we had over 12 unique looking modal UIs!

As a one-person design team, I needed to be ruthless with my prioritization to make sure we targeted the components that had the biggest ROI. Through my own research and conversations with Product and Engineering, I populated a list of UX patterns and components to target and organized them in a rough priority order.

Researching other systems

I knew I would be laying the foundation for the company's design system and it was important to me to make sure I did it in the best way possible that set the design team up to scale as soon as we were ready to bring in additional designers. I looked to YouTube and the Figma Community to find how other well-known designers and companies organize, document, and approached building, presenting, and maintaining their design system.

Key takeaways

Many of the systems I reviewed felt drastically overcomplicated. They were jam packed with color and type styles (why do you need 16 shades of gray?) and dozens of component configurations.
I was able to take inspiration for the IA of the system but made some tweaks based on what I felt we needed. I broke the system into 5 sections: Foundation, Layout, Components, UX Patterns, and Utility.
I liked how one system combined various input types like search, text, date, and select into a single page called "Input" to reduce the complexity of the system.

Laying the foundation

The front-end engineering team had not been a part of building the original design system and I believe it was important to bring them along on the journey in order for the system to be successful. I set up a weekly check-in for us to discuss progress and next steps related to the new design system we were building.

Color & typography

During our first check-in I began by starting with one of the most foundational components to a design system – color and typography. We reviewed the existing color palette together, answered some key questions, and identified several issues. Were we using all of the colors and type options in the system? Where? How? Did the colors and type in Figma match what was in production?

In many cases, the hex codes in Figma were not matching up with the exact hex codes in the front-end codebase.
There was a separate color palette from the marketing team that was stuck to the side of the file, but not being used in the design system.
I'm generally a big fan of simplicity, however, the existing system colors and typography options were much too restrictive when it came to semantic and background colors. This led to bespoke implementations in the UI.
The existing system was missing guidance for how these colors and type options were to be applied in the UI.

What it looks like now

After eliminating excess colors and identifying areas to expand, I reviewed the revised palette with the marketing team to ensure alignment with the Plainsight brand. We ended up adding a few additional brand colors as a result.

The complete palette lists the core color component, followed by when it's used, the specific name in our front-end library, and the hex code. I found this layout helped both design and engineering understand the meaning of the color, how to find it, and what it should be used for.

For typography, the existing system was much closer, however, I added a few additional options like Body Emphasized and Body Small text for captions and key phrases. Additionally, line spacing and usage text were applied to each font style to give users extra context when applying that style in their designs. Lastly, I included rationale that connected our chosen typeface to our brand identity.

When testing this out when building mockups and prototypes, I found we had just the right balance between simplicity and flexibility. Each color and type option had a purpose in the UI and not a single color or font style got unused!

Examples of key components

We couldn't afford to boil the ocean. As a one person design team with three front-end engineers, it was extremely important to focus our efforts on the areas in the product that had the most ROI and build out from there.

Buttons

Buttons are everywhere, and they weren't being applied consistently in the existing product. Some pages had as may as 4 primary buttons. Others had some link buttons with icons and others without.

Additionally, the existing button component didn't scale well with text and there weren't flexible variations for icons or menus. This added extra time when building mockups and often resulted in a detached component to accommodate changes to the button's appearance. Detached components are the enemy of an efficiently managed design system because they don't automatically update when you make a change to the primary component.

The new button component shown above takes full advantage of Figma's component property and variant features. Basic hover states are hooked up by default which makes prototyping with buttons a snap.

Now, when a designer adds a button to their mockup all they have to do is interact with the sidebar to make quick updates to the appearance. This is also a much more friendly approach for PMs or Engineers who may be less familiar with Figma.

Icons

I wasn't worth the ROI to build our own custom icon library, so I chose to import over 2,100 icons from Google's Material Design instead. In a matter of 5 minutes, we had a fully searchable and accessible icon library. This library was also what our front-end team had access to, thus achieving icon parity.

Now, when a designer toggles on the icon option for a button, they can search through an entire library of ready-to-use icons for their button!

Inputs

Many of the design systems I reviewed overcomplicated things when it came to input components, often times resulting in too many variants, properties, and states. The existing system's input components didn't take advantage of auto-layout or component properties so I decided to start fresh.

I used nested master components for inputs to make sure it was super efficient to update styles that should be shared, such as the gray border around the edge of the input or the size and color of the placeholder text. No need to change these values per component!

I arrived at 4 separate input components in total: text, search, select, and date pickers. Each component has their own toggle-able states for default, hover, focus, error, and disabled.

Error states take in custom error text that wraps nicely to the size of the input field. Some components, like select or date pickers, have a unique state to toggle a menu open that scales appropriately with the number of options you desire.

I won't bother covering each component in this case study, however, I took this exact approach when building out all of the other components to increase the efficiency and usability of the system.

Utility components

Often overlooked in design systems, utility components offer designers a consistent and fast way to communicate exactly what they're after with a given mockup or design file.

For example, the annotation component gets used frequently to explain what changed on a screen and explain the expected user interaction and system behavior. This approach received extremely positive feedback from our engineering team.

Here's an example of the annotation component in full action!

Another example of a utility component I added is the cursor component which gives designers a super fast way to toggle between all of the possible cursor states for a given interaction. This helps to make sure interactions are clear and user feedback for a given interaction is considered.

Adding documentation

After getting the primary set of components in place and in working order, I started to work on documentation for UX patterns in the platform. Through my earlier conversations, error handling was top of the list in terms of priority so that's where I started.

I wrote confluence articles for the various patterns identified earlier that contain UX principles, "Do" and "Don't" examples, supported methods, and copywriting best practices.

Here's an example of what some of the content looks like.

I recognized Confluence may not be as good of a solution to provide designers with "in the moment" documentation when designing in Figma. For that, I was able to leverage Figma's component documentation features. Now, when you hover over a component in the design system, you get a brief explanation for what the component is and some quick tips on how to use it.

Final results

50%

Less time spent building mockups

Components with variants

Color and typeface styles

90%

Parity with front-end codebase

The migration over to using the new Figma design system has been quite smooth. I've had to go in and make minor adjustments to components to make them work a bit more efficiently, but overall the team has greatly benefited from more durable and flexible components.

Next, I'll be focusing on building out documentation for a few additional UX guidelines and figuring out a more structured approach to maintaining and updating the system over time as we add new designers to the team.

Summary Early learnings Platform research Foundations Components Documentation Results

HOW MIGHT WE...

Create a flexible & consistent design system?