Identifying the gaps

The system was originally maintained by a single designer, but due to other commitments, he could only seldomly update the component library after its initial release. This resulted in designers often detaching components to make modifications that met their needs.

I also learned that the designers leveraging the system were often frustrated by a lack of information and guidance for the components. There was either a lack of documentation, or the documentation that did exist was outdated and insufficient.

Managing updates

While I was a designer committed to the system full-time, I still had to consider the limited engineering resources at my disposal (as in one full-time engineer). Together, we had to be selective about system updates to make sure that our components were scalable and had broad reach. 

When a request came in, I would review it to determine if, A) it was a need that was not yet addressed by design system, and B) it make sense to integrate it into the system or leave it to channel teams to develop their own local component. If a new component was to be created, per Brad Frost’s atomic design methodology, I made sure to leverage existing atomic-level components as much as possible.

Education and governance

One of the first key tasks was to overhaul the documentation and make it a tool that actually benefitted its users. With the aid of research that had been conducted in-house as to what designers expected from the documentation, I created a template that covered key information for each component, such as best practices, variants, behaviors, and relevant accessibility details. I also collaborated with a content designer to include content guidelines for relevant components.

I also moderated weekly office hour sessions in which designers were encouraged to bring their questions and use cases to receive feedback and guidance in real-time. These sessions were well-attended by those with questions to ask, and observers who simply wished to gain more insight into the system. Lastly, I designed and facilitated several workshops to cover topics such how to successfully use the system and its tools (this was geared toward those onboarding onto the team), and how to create local components in Figma.

Building in accessibility

I was fortunate to work with a developer who took accessibility concerns seriously, as meeting WCAG (Web Content Accessibility Guidelines) requirements had become high priority within the firm. This helped me to become more familiar with WCAG and designing for digital accessibility, and thus it became a principle within the Story design system to factor in accessibility considerations as part of the initial design process, rather than an afterthought.

Some of the efforts included:

• Checking for sufficient color contrast for both text (4.5:1) and graphic (3:1) elements on different backgrounds

• Providing keyboard accessibility for interactions typically driven by mouse hover

• Including hidden ARIA labels for interactive elements, such as icon-only buttons, that lack visible labels for screen reader users

Theming

When Figma announced its new Variables feature as part of its annual Config conference in Summer 2023, the Story design system was quick to adopt the feature to support theming, which would allow the different products that leveraged the system to have their own distinct UI. This was done by creating modes for each theme, each mode linking to variables that originated in external theme files that were owned by each respective product team. Once the matrix of variables was created, designers were able to apply a designated theme at the page level, which would then update all relevant component instances automatically.

This use of variables greatly improved upon the previous method employed for theming, which involved an in-house plugin that had to applied manually to each component instance.