Company
KualiHigher-ed SaaS · 7 products
One design system across seven products.
Kuali shipped seven higher-ed products that all looked and worked differently. As a Senior Product Designer — with no mandate to fix it — I made the case for a single design system, recruited the team, and started the Kuali UI Guild that outlived me. I later grew into a UX Manager role.
7
Products unified under one system
7
Designers recruited into the Guild
1 week
To build the core component library (offsite)
Pure UI
React components engineering built from it
The challenge
Seven products, seven personalities.
Kuali built seven products — curriculum, catalog, research (including Protocols), Ready, financials, and a custom app builder. Many customers used several of them, and each looked and behaved differently. Switching between Kuali products was jarring: it caused user fatigue and confusion, and the inconsistency quietly cost the company real time and engineering money to build the same things over and over.
The goal was simple to say and hard to do: make it obvious you're using a Kuali product, and give every engineer reusable components instead of another one-off UI.
Why it was hard
No mandate, deep silos.
01
I wasn't asked to do this
I was a Senior Product Designer, not a manager. There was no directive and no budget for a design system — I had to create the will for it.
02
A culture of "own your product"
Teams had been told to run their products like their own companies. That built ownership — and seven divergent design directions.
03
Dev-heavy, UX-light history
Earlier UIs came from very junior designers and engineering defaults. Consistency had never had a real advocate.
04
I lost my co-lead mid-way
The senior designer I recruited to start this left the company partway through, and I was suddenly carrying it alone.
What I led
Started it, sold it, systemized it.
I came to Kuali from Instructure, where I'd helped craft a design system — so I knew both the craft and the politics of getting one adopted.
I personally produced
- The UX audit that made the inconsistency undeniable
- The design principles the system was built on
- The initial type, color, icon set, and first components
I directed
- Recruiting designers into what became the UX Guild
- The offsite agenda that produced the component library
- The shared standards the products aligned to
I influenced
- Exec buy-in — hard conversations with the UX director and leadership
- The CEO, head of product, and head of engineering signing on
- How engineering chose to implement it in code
The team delivered
- The full Figma component library, built together
- Director of UX (Rob Foster) co-building the library
- Engineers building the "Pure UI" React components
Key decisions
The decision ledger.
The calls that turned a personal frustration into an adopted, org-wide system.
The decision
Treat the inconsistency as one company-wide problem — a shared design language and component library — rather than seven separate cleanups.
Alternatives
Keep polishing each product in its own silo. Or wait for leadership to mandate a system that no one was asking for.
Evidence
The UX audit — every product's styles gathered in one Figma file — made the cost of divergence impossible to unsee.
Tradeoff
A far bigger, more political effort than fixing one screen — but the only version that actually scales.
Who
Me + a recruited senior designer, then the Director of UX, then execs.
Result
Org-wide buy-in for a single system, and a team formed around it.
What I'd change now
Line up a second committed owner earlier, so the effort doesn't stall if one person leaves — which is exactly what nearly happened.
The decision
Invest first in a crisp case and demo, take it to the Director of UX, and use his help to get the CEO, product, and engineering leads bought in — before asking anyone to build.
Alternatives
Quietly build components and hope teams adopt them — the classic way design systems die on the vine.
Evidence
Design principles + concrete examples in Figma turned an abstract "consistency" pitch into something leaders could see.
Tradeoff
Slower to first component, but the mandate meant the work would actually be used.
Who
Me, Director of UX (Rob Foster), then C-level and eng/product leadership.
Result
Leadership committed. The system had air cover, not just enthusiasm.
What I'd change now
Tie the pitch to a hard cost — engineering hours saved per reused component — to make the ROI undeniable.
The decision
When a skeptical designer pushed for a prebuilt React library, I backed engineering to choose how to build — so long as they matched the design spec. They created their own components, "Pure UI."
Alternatives
Mandate a specific third-party library and risk fighting the people who'd maintain it.
Evidence
Adoption depends on ownership. Engineers build what they believe in.
Tradeoff
Gave up control of the tech choice to gain real, durable adoption.
Who
Me, the skeptical designer, and the engineering team.
Result
The skeptic came on board, and engineers built and named their own component set.
What I'd change now
Set up shared governance between design and "Pure UI" from day one, so the two never drift apart.
The decision
Use the team's annual offsite (San Diego, Oct 2019) to build the component library together, from a shared list, in a week — instead of me building it alone over months.
Alternatives
Keep grinding solo. It was slow going, and it made the system "mine," not "ours."
Evidence
The Director of UX offered to help and pulled the whole team in — momentum was there to capture.
Tradeoff
A concentrated, intense week over a diffuse solo effort — and shared ownership as the payoff.
Who
The full design team.
Result
The core component library built in a week — and owned by everyone who built it.
What I'd change now
Schedule the "keep it alive" cadence before leaving the room — a living system needs a standing owner, not just a great week.
Collaboration & leadership
Leading before I had the title.
This is the clearest example of how I lead: I saw a company-level problem no one owned, and I built the coalition to fix it. I recruited a senior designer to start, brought in the Director of UX as a partner and sponsor, and turned a group of designers and engineers who all quietly hated the inconsistency into the Kuali UI Guild. When the one real skeptic pushed back on the tech, I didn't overrule him — I gave engineering ownership, and won him over.
I did this as an individual contributor. The influence, the exec conversations, and the team I built are why I later grew into a UX Manager role — the responsibility came before the title.
Product evolution
From seven UIs to one language.
Before — seven divergent products
Different type, color, icons, and patterns per product. Reused nothing; re-taught users every time they switched.
Product A UIProduct B UIProduct C UI…× 7
After — one system, many products
Shared principles, type, color, icons, and a Figma component library — mirrored in engineering's "Pure UI" React components.
Design principles→Figma component library→"Pure UI" in code→All 7 products
Outcome
A system that outlived me.
C-level buy-in
Leadership committed to one system — the political battle a design system usually loses.
A unified team with a mission
The Kuali UI Guild: designers and engineers who owned consistency together.
Spec + component library
A shared design spec and a Figma component library the whole team built.
"Pure UI" in production
Engineers built reusable React components from the system — and it kept going after I moved on.
Reflection
What I took from it.
What worked
Selling the vision before building it, and building the library with the team. Shared ownership is what made it survive.
What I'd do differently
Secure a second owner and a maintenance cadence up front. A system stalls the moment it depends on one person.
What I learned
You can lead org-wide change without authority — if you build the coalition and give people ownership of their part.
How it shaped my leadership
This work is why I grew into managing. I'd already been doing the job: setting direction, aligning execs, and growing a team.
See the rest of the Kuali story
The system was the foundation. Two products show what I did on top of it — saving a deal, and reviving a product.