🚧 THIS CASE STUDY IS A WORK IN PROGRESS
Design System
Scaling design system with purpose.
When I joined Solv as a UX Designer, the seller portal was functional but fragile. There were 10 variants of primary blue. There were 3 different primary buttons across modules. Spacing changed from screen to screen. Form states behaved differently depending on who built them.
Nothing was broken. Yet everything felt uncertain.
Our sellers described the experience as confusing and inconsistent. Some hesitated before clicking. Others double-checked actions because they were unsure what would happen next.
I realized we were not dealing with a visual issue.
We were dealing with a trust issue.
Who are we really designing for?
Most of our internal reviews happened on high resolution MacBooks.
Our sellers were using low-cost Windows desktops with basic monitors.
That detail changed everything.
On their screens:
Subtle greys disappeared.
Blues looked faded.
Error states lacked urgency.
Primary buttons did not stand out.
A button that looked bold and clear on my screen looked flat and uncertain on theirs.
That was the turning point.
If the primary action does not stand out on their monitor, it is not primary.
We reduced the color palette.
We increased contrast.
We eliminated decorative shades.
We defined clear hierarchy.
The system began with empathy for hardware.
Why can’t we just fix screens one by one?
At first, the idea was simple. Fix the most visible screens.
But every sprint introduced new visual variations.
Each team made small local decisions.
Engineering duplicated CSS.
QA flagged recurring alignment issues.
Fixing screens individually would create temporary relief.
The inconsistencies would return.
This was not a screen problem.
It was a system problem.
We needed shared foundations.
Will a design system limit my creativity?
Junior designers were worried.
Will everything look the same?
Will experimentation stop?
Will creativity shrink?
I understood that fear.
So we reframed the conversation.
The design system would define:
Color tokens
Typography scale
Spacing system
Core components
It would not define ideas.
Instead of choosing between 10 blues, designers now chose the right interaction pattern.
Instead of debating button styles, we focused on user flows.
Constraints did not reduce creativity.
They redirected it toward clarity.
The tradeoff was fewer visual experiments.
The gain was stronger, faster decision making.
Why should engineering invest time in a component library?
Developers were practical.
Why refactor working code?
Why build a library when features are pending?
The concern was cost. And it was valid.
We outlined the invisible cost already being paid:
Rewriting similar buttons in different modules
Fixing repeated CSS bugs
Extra QA cycles for visual inconsistencies
Slower feature releases due to UI rework
Then we outlined the long term gain:
Reusable components
Single source of truth
Token driven theming
Fewer regression bugs
Reduced QA overhead
The cost of building the system was visible.
The cost of not building it was compounding silently.
We accepted short term refactor effort in exchange for long term velocity.
What tradeoffs did we accept?
We were honest about what this required.
Design tradeoffs:
Smaller color freedom
Stronger visual discipline
More documentation
Engineering tradeoffs:
Refactoring legacy components
Aligning on shared standards
Maintaining a component library
Cultural tradeoffs:
Designers aligning decisions
Engineers collaborating earlier
Shared ownership over UI consistency
It required maturity across teams.
Did it change anything for sellers?
Yes.
Primary actions became unmistakable.
Text readability improved.
Error states felt urgent and clear.
Navigation felt predictable.
On the same low-cost Windows monitors, the interface now felt confident.
Sellers no longer hesitated before clicking.
They trusted the system.
What this taught me
A design system is not a Figma library.
It is a decision system.
It reduces cognitive load.
It reduces engineering waste.
It reduces QA friction.
It increases user confidence.
We did not build a design system to organize files.
We built it so that every seller, on every screen, could move forward without doubt.
Outcome
Created a semantic design foundation that’s now scalable and maintainable.
Improved design-developer handoffs and reduced rework.
Empowered new designers to onboard faster and contribute confidently.
The system is no longer owned by one — it’s shared and understood by all.