2021
Gett.UI
Design System
Gett’s enterprise products were built with conflicting UI patterns across teams. Components were redesigned, rebuilt, and QA’d repeatedly, while accessibility issues surfaced late in delivery.
I led the creation of Gett.UI: a shared system for components, tokens, documentation, and governance. The goal was to reduce repeated UI work and help teams ship accessible features faster.
Industry
Enterprise SaaS
Role
Enterprise Design Lead
Focus
Design Systems, Governance, Accessibility
Business problem
Inconsistent UI patterns were slowing delivery, duplicating engineering work, and creating accessibility rework across Gett’s enterprise products.
Design response
I built Gett.UI as a shared system for components, tokens, documentation, governance, and WCAG-ready patterns.
Business result
The system reduced repeated UI work, improved accessibility quality, and helped product teams ship features faster.
40%
Faster Feature Rollout
80%
Fewer Accessibility Bugs
90%
Cross-Product Adoption
Gett’s enterprise UI had become expensive to maintain. Five teams used seven different date pickers. Designers repeatedly specified the same buttons and forms. Engineers rebuilt similar modals across products. Accessibility issues often appeared late, after implementation had already started. This was not just a UI problem. Every repeated pattern added work for design, engineering, QA, and accessibility review.
Finding
the Shared Layer
We started by looking for the work teams were repeating. The same buttons, inputs, tables, filters, modals, and date pickers kept appearing across Accounting, Infrastructure, B2B SaaS, and Security. That repetition gave us the starting point: build the shared layer first, not the perfect system.
The Cost of Inconsistent UI
The cost showed up in everyday delivery. Teams spent time rebuilding components, debating patterns, fixing accessibility late, and onboarding new hires into product-specific UI rules. Even small inconsistencies created extra decisions for design, engineering, and QA.
A System That Speeds Up Work
The system had to be useful from day one. It needed to reduce repeated work, improve accessibility, and make teams faster without becoming another approval layer.
Starting With
High-Use Components
We started with 20 components that almost every team needed: buttons, inputs, tables, filters, modals, and date pickers. The rule was practical: if several teams used it, it belonged in the system. That kept the MVP focused on real delivery bottlenecks instead of design-system theater.
Governance stayed lightweight. Any team could propose a component, but adoption depended on shared need, clear ownership, and engineering feasibility. Engineers were involved early, shaping APIs, edge cases, and implementation details before the components reached documentation.
Building Accessibility
Into the System
Accessibility became part of the component spec. Components shipped with contrast-checked tokens, keyboard behavior, focus states, and error patterns aligned with WCAG 2.1 AA. Teams no longer had to rediscover accessibility requirements at the end of delivery
Documentation
Storybook became the place teams went to use the system. It included usage rules, real examples, anti-patterns, accessibility notes, and developer API specs, so designers and engineers could work from the same reference.
What We Learned
Starting small helped teams trust the system. API-first collaboration made components easier for engineers to adopt. Progress over perfection kept the library useful instead of rigid. Legacy debt was the hard part.
Some ideal patterns had to change once they met real product constraints, which made feedback loops as important as the components themselves.
Outcome
Feature rollout became 40% faster, cross-product adoption reached 90% in six months, and accessibility bugs dropped by 80%. The system also saved more than 200 developer hours per month by reducing repeated UI work across teams. New hires had a clearer starting point, and product teams could build from pre-audited patterns instead of reinventing basic interface decisions.
The clearest signal was in the handoff: teams spent less time asking which version of a component to use, and more time building the actual product.
Rebuilding the same buttons?
I help teams create shared systems that accelerate development. Let's talk.