Splunk — Case Study
I Had No Authority to Mandate Change
Building a design system by earning adoption, not enforcing it.
7
Teams adopted
60%
Faster design productivity
~40%
Fewer QA cycles
Context
I couldn't tell anyone what to do.
Splunk's products were built by separate teams — Security, Observability, Enterprise. Each had their own engineers, roadmaps, and priorities.
Charts looked different across products. Not because anyone was wrong — because no one was aligned.
I had no authority to mandate change.
Problem
Different products, different visual languages.
Teams had their own priorities. Their own deadlines. I couldn't ask them to stop and rebuild.
If I wanted consistency, I had to earn it — one team at a time.
Customers moving between Security and Observability felt like they were using two different products. Trust eroded. Support tickets piled up. “Why does this chart look different here?”
Share, don't force. Consult, don't control.
Approach
1–2 years of influence, not mandates.
Over 1–2 years, I:
- Explored use cases across teams — why does Security need this? Why does Observability need that?
- Shared findings proactively — not waiting to be asked
- Consulted with teams when they were ready to adopt
- Helped products transition to shared standards — on their timeline, not mine
System
16+ components. One flexible system.
One visual language. Sixteen chart types. Everything belongs together.
- Consistent sizing (small / medium / large)
- Shared color tokens
- Flexible variants for different use cases
- Documented so anyone could use it
Example
Single Value — one component, many needs.
This was the most-used component — and the most inconsistent. Getting this right proved the system could flex.
Impact
Adoption happened — because it was worth adopting.
7 teams
Adopted within 6 months
60%
Faster design productivity
~40%
Fewer QA cycles
New products defaulted to the system. Fewer debates about colors. Products finally felt like one platform.
You can't mandate trust. You have to earn it.
Reflection
What I learned
Design systems succeed when teams see value — not when they're told to comply. My job wasn't to enforce standards. It was to make standards worth following.
