Safe Software Internship

Context

When I first joined the team, I noticed the lack of a properly maintained design system. Finding information about updated features often forced me to search through numerous Figma files, as finalized designs were not organized into a dedicated repository. This made it difficult and time-consuming to track down past information.
‍

Problem Space

In addressing the previous design system problem, I identified several key issues that were hindering the effectiveness and usability of our design assets. The primary challenges included:
‍

What's the Goal?

My main goal was to build a system that covered most components and design patterns that are commonly used to create high-fidelity mockups for desktop application design. These design assets would be organized to ensure they are easy to maintain and straightforward to understand. With this in place, the design system not only streamlined our workflow and made mockup creation more efficient but also provided our team with a reliable, up-to-date repository for all design assets.
‍

Methodology

I explored various principles and frameworks to determine the most effective way to separate components into distinct parts. After discussing it with the team, I decided to follow the Atomic Design methodology, as it offers a clear and structured approach to building and organizing the design assets.
‍

Breakdown

To create a more structured, scalable, and efficient design workflow, the design system will be divided into three distinct parts. This decision came after a team-wide discussion to identify which areas of the program are frequently updated or require significant time to create mockups.
‍

Audit

The audit process consumed a significant portion of the project timeline, primarily due to the complex structure and the numerous variations in each component. With the help of my group members, we collaboratively summarized all the audits to ensure that each component included all the necessary variations and properties.
‍

Audit Feedback

Comparing Sizes to Actual Build

To ensure that the component sizes are accurate, I need to choose an anchor that can be used to set the size of the reference screenshot as close to the actual build as possible.

This can be done by creating a rectangle with a slightly transparent fill, setting the rectangle to 16x16 pixels, and positioning it at the chosen anchor point. By doing this, we can resize the screenshot until the anchor icon fits the actual build, and use it as a reference for other UI elements.
‍

The Slots

Considering that some components could have different layouts, the team proposed using a slot-based method that combines the instance swap and preferred values approach. This method allows for the creation of reusable components that can be easily swapped or replaced within a predefined structure.

Color Tokens

To maintain consistency in the colors used within the components, I collaborated with another team member experienced in creating design tokens. These design tokens were then assigned specific color codes and organized into a centralized color library. By leveraging design tokens, we were able to standardize color usage, and simplify future updates.
‍

Building Components

With all the resources prepared, I began building the components. Throughout the process, different team members tested the components to ensure that all properties, including states and variations, were correctly implemented.

The images below illustrate how the components are structured within the layout. The design system encompasses additional elements beyond what is displayed here.
‍

What We Identified...

Nested Instances

While using nested components is a standard approach in Figma for building complex designs, it can introduce challenges as the component complexity increases. Specifically, when components are nested within each other, the list of properties associated with the component can become quite lengthy and repetitive.

To address the challenges posed by nested components, we've opted to display properties only at the high level components (parent components). By doing so, we ensure that the list of properties is more manageable and not overlapping.
‍

Extra Slots

The team also agreed that extra slots should be included in the component to allow for future replacement or customization. This approach ensures that the template remains future-proof, enabling updates or additions to be made without the need for a complete rebuild of existing components.
‍

Adding Filled Variants

Variants of a component with pre-filled content should also be provided. This allows designers the option to either customize the content according to their needs or use the predefined content as it is. Offering these options ensures efficiency while creating mockups that don’t require specific context.
‍

Documentation

In addition to creating the components, I also created documentation outlining the methods and processes I used to build them. This documentation ensures that other team members responsible for maintaining the design system can seamlessly continue updating existing components and creating new ones as needed by the team.
‍

The Impact

The design system significantly enhanced the quality of the mockups generated by the team. Instead of relying on screenshots of product interfaces, all mockups could now be created directly in Figma, allowing for easy modifications. One team member even shared that she managed to complete 14 days' worth of mockups in just 2 days, enabling her to finish all her work ahead of her holiday trip to Korea!
‍

Lessons Learned