Embedded Files
CASE STUDY: DESIGN SYSTEM
Design Systems, Enterprise, DesignOps
Background
Sterling, a company specializing in performing pre-employment background checks had a variety of legacy products and platforms. Some of these platforms were developed internally over the years while others were inherited via the acquisition of other companies. None of these platforms had a consistent look and feel, creating confusion and usability issues for users. It was decided by upper management that we would re-brand to bring these products into alignment.
Scope
The company hired an outside consultancy to work with Sterling’s internal marketing team to come up with logo design, branding colors, and other assets to create a strong brand presence. These assets were then handed off to the UX Design team to create the look and feel of our applications.
Goals
The main goal was to unify the brand presence across marketing materials, sales sites, and external-facing applications. Sterling was a leader in the background screening space, but the styling and branding of our products were inconsistent and dated. Despite trailing Sterling in offerings and market-share, some of our competitors had superior branding that gave them a polished look and feel that our image lacked. There was a big push from senior leadership to unify our image and bring us into the current times.
What is a Design System anyway?
A Design System is simply a set of standards and styles. These are used to then create a standardized set of consistent components to be used across projects. It is a single source of truth that everything references when creating digital experiences.
Design System
The design system outlines the standards, styles, and branding of Sterling products. Components are built and maintained adhering to these guidelines.
Component Library
The component library is part of the Design System. Individual components are first designed to adhere to all branding and become the single source of truth for designers and developers
Where to Start?
Creating a new Design System is no small task. Our first step was to take a look around for some inspiration. Google has spent an incredible amount of resources developing their Material Design system. They have conducted extensive user research and accompanying documentation. We became heavily influenced by Material Design and used it as a source of inspiration when creating our design system.
Google's Material Design System was an initial source of inspiration.
First Steps
Using all the branding assets that had been created by the consultant, we began creating components and outline style guidelines that would work well for Sterling our products. These initial efforts were done in the Sketch and InVision ecosystem, but I have since migrated the library over to Figma. This initial work was divvied up among 3 designers with most of the component design being handled by me.
Meanwhile...
Our front-end architect discovered the Material-UI open source component library. This was a React based implementation of many of the Material Design components. At that time, there was a concerted effort within Sterling to push all platforms towards React. It was decided to fork this library to use as the base of our Sterling-UI design system. The styling and functionality of this base set of components could be modified to meet our specific needs without the need to spend lots of resources starting from scratch.
Challenges
Our primary challenge after rolling out Sterling-UI component library was adoption.
Our first version of the Sterling-UI component library was created using React. However, all the applications that we had in flight were created using a variety of disparate tech stacks.
While it was possible, it was tricky to include the components in a project created using Angular (for example). Developers (often saddled with aggressive timelines) did not have the time to spend learning a new tech stack, or the proper approach ingest the components. It was easier for them to style existing components in their applications to look like Sterling-UI components creating headaches later down the road.
Refactored Component Library
To solve for this, we re-factored the component library to use Web Components instead of React. This meant that the components were now tech-stack agnostic and could be easily used in all our applications.
WCAG Compliance
All the components were designed to be WCAG Compliant (accessible). Automated accessibility unit testing (using Scan with Axe) was built in at the component level. This saved engineering a lot of time as they got accessibility compliance for free when using the components.
Solution
Because Sterling started getting government and educational clients who required WCAG Compliance, there was a big push for accessibility within the company. Suddenly instead of making it slower for engineering teams to use the component library, it actually ended up saving them time! They could be assured of WCAG Compliance on the component level. They could include the library in their project and use it regardless of what tech stack it was developed in.
Current State
The component library now is used by all Sterling's applications. This has created a consistent user experience across multiple platforms, and ensures that updates and additions to the component library are easily managed simply by "versioning up" the project.
The library is constantly being updated to accommodate new functionality and new components. We have intentionally tried to be very future-thinking in the way it has been implemented in both the code base, and in Figma so as to easily handle potential rebranding efforts.
Artifacts
The Figma library was not only used as a repository for components, but also as a documentation site for other members of the design and engineering teams on how to use the components.
This single source of truth approach ended up working well for both the design and engineering teams.
An example of the documentation on how and when to user certain components.
Sometimes it was useful to "redline" certain components for engineers who weren't as comfortable getting specs directly from Figma. This library file became a living document, constantly evolving, with potential suggestions for future work or updates included.
Google Sites
Report abuse