Cedar - Canopy Design System

The Project

Iterate and build upon Cedars Design System, Canopy; a system that gives designers and developers the frameworks they need to create engaging product experiences. Optimize processes and craft to increase velocity, create consistency, and improve the quality of design work at scale.

While the foundations of the canopy (color, typography, expression, etc.) are rooted in similar principles, the users that use our apps have different needs. Currently, our users are broken into two main groups: Providers (i.e., call center reps) and Patients.

Process

The design team consists of 16 designers. My design manager and I make up the design ops team; our goal is to scale design within the organization by creating a source of truth with the design system that developers, designers, and product managers can refer to.

Prioritization

To build effectively and efficiently, I helped implement a dot voting exercise we use each quarter to help design ops prioritize roadmap and not build blindly. It allowed designers from product teams to think on a system level about what can be a component and what they believe can apply in other areas of the product line while considering what is on their roadmap and what design ops can do to support them. Though we may prioritize it this way, we still allow for flexibility when there are ad-hoc requests.

Starting point

Like any project, documentation is essential to keep tabs on what we are doing and allow us to refer back to it when we iterate upon it. Therefore, throughout our process within DesignOps, we implemented a brief template that gave us a starting point whenever we built a new component. In addition, it allowed us to involve our cross-collaborative partners early on and act as that source of truth to keep us within the scope of what we need to do.

Iterative process

While I diverge outwards to gather resources through audits and explore variations of a component, I always bring in the stakeholders to go through a design review, either through one-on-one conversations or in a group.

There are times when components are pushed out as a pilot before we publish them in Storybook to get further insight into how it performs in a live context.

Storybook execution

With storybook, our goal is to create components that currently don't exist in the system and aren't reusable, update all to spec according to Figma, do unit testing for all, and meet accessibility standards.

Unfortunately, design systems don't have dedicated developers, so we used a federative model approach. To do this effectively, I worked closely with developers to create a process that is extendable to all developers who might be building components for their products.