CASE STUDY 06
Designing Within Constraints.
Sometimes the component isn't the problem.
Discipline
Design Systems
Focus
Component Architecture
Platforms
Desktop · Mobile
The Situation
A new regulatory disclosure requirement introduced significantly more information into an existing product card.
On desktop, the additional content was manageable.
On mobile, it consumed too much valuable screen real estate and threatened to turn an otherwise flexible component into an increasingly complicated collection of exceptions.
The obvious solution
Create another component variant.
That's the default response when a new requirement lands: add a variant that accounts for the new edge case. It's fast, it's contained, and it keeps the existing component untouched.
But every variant adds weight. More states to maintain, more decisions for the next designer, and a system that slowly grows harder to reason about.
My Solution
Challenge the requirement first.
Instead of adding another variation to the design system, I raised the issue with Product and Legal to understand which information was actually required and what could be minimized.
That conversation allowed us to reduce unnecessary content rather than designing around it.
The Result
Less content
Fewer exceptions
More scalable component
The Principle
Not every edge case deserves a variant.
Sometimes the best way to protect a design system is to solve the problem upstream before it ever reaches the component.