Interview: Designing for Reusability — Conversation with a Design System Lead

We spoke with Hana Park, lead of a large retailer's design system team, about the tension between creating highly reusable components and avoiding abstraction leakage. Hana's team supports dozens of product teams and has gone through multiple iterations of governance, token modeling and component APIs.

Key takeaways

Start small with strict boundaries: Hana recommends shipping a small set of well-documented components and enforcing clear contracts for each component. This avoids early bloat and reduces the need for breaking changes later.

“A component should be an API you trust — not a kitchen sink that tries to be everything for everyone.”

— Hana Park

Balancing flexibility and constraints

Hana's team found success with a composable approach: provide small primitive components that teams can compose into richer patterns. This keeps primitives stable while giving product teams the ability to create tailored experiences. The design system documents composition patterns, recipes, and scaffolded examples for common use cases.

Governance and adoption

Adoption needs both technical integration and social buy-in. Hana's team runs monthly office hours, migration clinics, and a changelog with clear migration guides. For large breaking changes, they provide codemods to automate repetitive edits and reduce the friction to upgrade.

Token design

On tokens, Hana favors a layered model: core tokens (colors, spacing, typography) map to brand tokens which in turn map to component-specific tokens. This layering wires design changes to components predictably without forcing every team to handle global token mapping.

Measuring success

Hana measures success using a mix of adoption metrics (component usage, dependency graphs), developer happiness (surveys) and runtime metrics (bundle size, time-to-interactive). These metrics help allocate engineering resources and prioritize the next set of components to build.

Advice for small teams

For small teams building their first design system, Hana suggests focusing on a single surface (e.g., forms) and solving the hardest problems there first. Doing so yields templates and patterns that can be reused across other surfaces.

Closing

Hana's experience underscores an important truth: reusability requires deliberate API design, strong documentation, and a human-centered adoption plan. When components are treated as products, they last longer and serve teams better.