Modality Moment

At Compass, I’d been working with the Design System team to launch its new website. Documentation for design system components existed on wikis, in slide decks, on Figma sticker sheets, in Storybook, on GitHub, in Slack channels, and in the mental notebooks of our designers, engineers, and managers.

One of my first tasks was to draft a component page for “modals.” As I investigated the component, I discovered two sets of problems.

The problems

First, by using “modal” as a noun, we were obscuring “modality” as a property shared across a range of components. The design system lacked the vocabulary to talk about blocking and non-blocking experiences.

Second, modals generated a lot of questions from across the organization. Some designers relied on modals as a convenient container for a range of use cases, but were concerned about its interruptive experience for users. Others were frustrated by the limits built into the modal, wanting more real estate for complex tasks. And there were inconsistencies across the platform within similar use cases.

What I did

I brought together designers and engineers on the design system team. We came up with two solutions.

Rename the component from modals to modal dialogs. The new name ensures findability and recognition among design system users, while also clearing a path for “modality” as a component property.
Create a new pattern page on the design system website that provides practical guidelines for deciding between blocking and non-blocking components.

What this shows

I designed through definition. I surfaced an issue of naming that invited greater conceptual clarity. In the process, I helped reveal opportunities for increasing the design system’s coherence.
I allowed content to be a bridge amongst stakeholders. In the course of aligning on documentation goals, team members identified larger systems issues.
I demonstrated the storytelling power of documentation to anticipate and address design system user needs in a way that no other medium can.