Design Systems for Cornerstone Ondemand
Cornerstone Design Systems is based on an atomic design system structure and was built with two of my design colleagues and a small team of front-end engineers.
Problem
Over the years, as the product team grew and turnover became shorter, the UI became a mess. Different product suites had quietly established their own UI schema, and this resulted us in having various versions of the same components, designed and built by different individuals. Ultimately this was causing inconsistent experience for the users, more work for the developers, and thus slowing down the whole production process.
Solution
In a team of three, we set our OKR (Objective & Key Results) for design systems enablement, and worked towards our transparent and measurable goals. We worked closely with the engineers and established standard operations for creating our source of truth.
↑ We utilized "Abstract", a product similar to github, but for designers to manage their "Source of Truth" Sketch files.
↑ Let's take a look at the "modal prompt" component in our library and how it's built, documented.
↑ We organized all our symbols in a systematic and intuitive way, so any designers can link the Sketch library and find what they're looking for.
↑ Text styles & layer styles are also organized systematically, allowing designers to quickly switch between the color options given to the component.
↑ Text & Background Styles is a dedicated section for listing out all text styles & background (layer) styles we use for the component. Contrary to a typical style guide, these styles are component-specific, and is often independent from the rest of the component text & background styles.
↑ "modal prompt" Design Documentation.
↑ Visual Specification is where we provide most of the crucial red lines as well as the dimensioning configuration option we support for the component.
↑ Our source of truth stays within Abstract server. Here we have the capability to inspect our design as well as view changes/updates made from the previous version.
↑ We upload these spec to Invision and allow our internal collaboration and reviews. Invision is also our way of handing off design spec to developers. Then we conduct Design QA, and once approved, the component will be merged into our library
↑ React component library. Front-end UI team utilized Storybook for React to build a sandbox environment to demo the component for all stakeholders.
↑ Source code. We UI design & the front-end UI design team always try to stay aligned so the source code structure, naming conventions, configurations correspond to the design specification.
↑ Section of "Read Me' for the React component.
↑ Every single one of our components go through the same process to be built and documented into our Design Systems.
Contact for More Info
