Discovery

A similar interaction already appeared across multiple components, but there was no shared guidance governing its behavior, placement, naming, or implementation. Before designing a solution, I needed to determine whether it should be treated as a component-specific feature, a reusable interaction pattern, a shared component, or some combination of the three.

Distinguishing Pattern from Component

I began by separating the interaction from its visual implementation. Components define a specific interface object, including its structure, appearance, states, and properties. Patterns define a reusable solution that can span multiple components and establish when it should be used, which behaviors should remain consistent, and what accessibility expectations apply.

Distinguishing a Pattern from a Component

The interaction appeared across different component types, supported the same group-level user goal, and remained conceptually consistent even when its visual treatment changed. This led to a working hypothesis: the behavior should first be defined as a cross-component pattern, while a reusable Figma or code asset could be considered separately.

Auditing the Existing System

I mapped how the interaction currently appeared—or could potentially be supported—across accordions, expandable cards, tables, and related disclosure components. For each component, I documented its existing configuration, placement guidance, group-control support, documentation coverage, and potential changes.

The audit exposed uneven support across the system. Some components already included the behavior and documented its placement, while others required teams to construct their own solutions or offered no guidance at all. This created variation in both implementation and the resulting user experience.

Deconstructing the Interaction

Looking beyond individual components revealed a shared structure: one group-level control changes the state of a collection of related items, while each item continues to maintain its own state.

Defining this underlying model helped separate the persistent user need from any particular interface treatment. It also provided a foundation for evaluating which components could participate in the pattern without tying the solution exclusively to accordions.

Using AI to Broaden the Research

Because the interaction was inconsistently named and rarely documented as a standalone pattern, conventional searches produced limited results. I used Microsoft Copilot within the organization’s approved environment to explore related terminology, surface candidate examples from public design systems, and identify additional questions for investigation.

AI accelerated the initial search, but it did not determine the findings. I reviewed the original sources, excluded examples that were not meaningfully comparable, and evaluated the remaining systems against a consistent framework covering behavior, placement, control model, visual treatment, and accessibility guidance. I then synthesized the evidence into the working hypothesis and open decisions that guided the next phase.

Comparing Established Approaches

I evaluated the public design-system examples against a consistent set of criteria: group behavior, visual treatment, placement, control model, accessibility guidance, and notable implementation decisions.

Primary findings from comparing established approaches.

The comparison showed that no system exposed the interaction as a standalone primitive. Most documented it within an existing disclosure component, but their implementations differed considerably. Some used two persistent actions, while others used a single control that changed with the current state. Placement, terminology, and visual treatment also varied.

Despite those differences, the examples shared one important principle: the control acts on a defined collection of related elements.

What the Discovery Established

The behavior represents a cross-component interaction pattern rather than a feature inherently tied to one component.

• The pattern should be defined before deciding whether a reusable Figma or code implementation is warranted.

• Existing implementations provide no universal convention for placement, naming, or control model.

• Shared guidance could reduce local design decisions and improve consistency across participating components.

• Accessibility behavior, participating components, naming, placement, and the form of any reusable asset remain decisions to resolve during the next phase.

Next Steps

Discovery established the foundation for a shared interaction pattern, but several decisions still require cross-functional validation. The next phase will focus on:

• Defining which components can participate in the pattern

• Establishing naming, placement, and state-behavior guidance

• Validating keyboard, focus, and screen-reader expectations with accessibility partners

• Determining whether a reusable Figma asset, code implementation, or component-level configuration is warranted

This work is currently in progress. The case study will be expanded as the pattern moves through definition, validation, and implementation.