Design System Management

Objective: take a design system for a startup that makes case management software for social workers and grow it to scale with us as we added more functionality and flexibility to our product.

Getting the team on the same page

Before I joined the team, there were no shared design assets beyond a few neglected sketch files in Google Drive. Designers were starting from scratch each time they started a new design file, wasting time and introducing a lot of small inconsistencies between designs.

Moving from Sketch to Figma

I made a case to senior leadership to move our design team from Sketch to Figma, enabling us to work faster and share library resources. Figma was relatively new at the time (2018) so I trained the other designers on it.

Figma offered some key features we needed:

• we could create sharable interactive prototypes without using other apps
• we could share library assets between design files
• product managers and developers could comment on our design files and access the most up to date designs in real time

The move to Figma allowed us to eliminate a few other subscriptions like InVision and Zeppelin and made our design process more repeatable.

Building out the initial component library

After getting everyone working in Figma, I built out and published an initial component library file, incorporating the text styles, colors, and components we already had. I worked with the other designers on retrofitting these new components into their existing design files to get them consistent and up to date.

Establishing our process

With an initial library in place, I led the team in establishing the design system processes and governance that are still used today.

Identifying new components

We started by identifying emerging patterns in new design work, reducing duplicate design effort and increasing consistency.

The process I established for adding a new pattern to the DS was:

1. Move it into the DS library file
2. Use the library colors and text styles
3. Add any necessary variants (hover states, disabled versions, empty states)
4. Name it consistently
5. Publish a new version of the Figma library

Channels and rituals for communication

Throughout this process of standardization, I facilitated communication between designers and developers by ensuring each team was using the same names for colors, text variants, and components. Moving forward, I needed to make sure everyone had ways of contributing and keeping up to date on the latest changes.

Meetings

In addition to our weekly design critique sessions, I implemented a weekly meeting to review possible design patterns.

To breakdown siloes in the organization, I instituted monthly Design System open houses, where I gave a brief DS update and anyone in the company could ask questions. I was pleased to find that people from our sales team were regular attendees. These DS open house sessions were a chance for them to get an inside look at our design process, and share feedback and new user needs they were hearing in sales calls.

Asynchronous communication

I created a #design-system channel in our company Slack. I posted about updates in our design system in that channel and encouraged anyone with questions to ask it in that channel, so that both the question and the answer could be available in a shared space.

User testing

Casebook's users, social workers, are a specialized group, with unique challenges: while not especially technical, they must process very detailed information about their clients and the services they provide, and must follow very rigorous documentation and process standards.

When new components were added for new design work, I made sure questions geared to assess their efficacy were included in the user research sessions for that design work, to make sure the patterns we were adding and spreading within our app were intuitive and worked well.

Improving documentation

The existing documentation page was limited, difficult to navigate, and hard to maintain.

I replaced it with an interactive Storybook docs app, so that designers, product managers and developers could browse our components and learn how to use them. Moving to Storybook also enabled me to provide documentation for designers and developers in a single place.

Adding flexibility to future-proof our design components

As we tackled more complex problems in our product, we needed our design system to become more flexible and expressive over time.

On the design side, this was somewhat easy; as long as we used our standard set of colors, typefaces, spacing units and shadows (our design tokens), a design would work within our system.

On the developer side, building those designs without writing custom CSS would require creating a large set of cumbersome, manually-maintained style options on every component, which isn't very DRY. To make this more maintainable and extensible, I built a generalized way of allowing our developers to specify design tokens on a black box component.

This approach allowed our developers to build any design that adhered to our design system, simply by specifying style attributes that looked like CSS-in-JS.

I had previous experience working with the Emotion style system, and based the general pattern on their @emotion/styled library.

Impact

In growing our design system at Casebook, my goal was to add flexibility, consistency and expressiveness. I achieved this by moving the design team to Figma so we could work more efficiently and share design assets, creating and maintaining a set of shared design assets, ensuring our shared design components were working well for our users, and building flexibility into our shared components so they can rise to the challenge of future design needs.

You can see the live documentation site I created here: https://casecommons.github.io/cbp-undercase-lib/, or browse it in the embed below:

The Figma component library I created is browsable at https://www.figma.com/file/Ge3Kwh7ArK5O4ZxcfzNs58?type=design.

Other articles:

Building an automation engine for social work

Bringing co-founders' vision to life by iterating on an MVP