Case Study
Responsive by design. A multi-year React rewrite of a fragmented Java suite, anchored by a single design system — standards, components, and patterns — that delivered what the rewrite was for: phone portability, full-fidelity layouts on the wide office monitors clients actually worked from, and one set of usability standards across 100+ tools.
A sprawling Java suite built by separate teams, with inconsistent UI patterns and no shared foundation, was being rewritten in React. The rewrite needed a unifying design to anchor it; without one, the new stack would just regenerate the old fragmentation in a faster language. Mobile made the problem urgent. iPad made it impossible to ignore: clients on large-screen tablets were getting phone layouts and couldn't understand why.
Led the design system end-to-end through a multi-year React rewrite — architecture, component design, responsive behavior, documentation, and engineering partnership across desktop, phone, and iPad.
Managed the engineering team implementing the React library with full task prioritization and delivery authority. Held the final design call in grooming, with the VP of Development or CTO as the escalation path under schedule pressure.
Authored the shared responsive standards — column grid, size classes, canonical layouts — that every product team designed against.
Pushed for mobile parity earlier than the business wanted to commit to it. The iPad collision proved the call right; Version 8 was the integration.
Components had to work across desktop, phone, and iPad without per-product design or dev work — a constraint the original Java apps had never been built to meet. The new system had to.
The design system became the anchor: a Figma component library, a React library documented in Storybook, a shared responsive standard every product team designed against, and a library of canonical layouts and patterns. For clients, that delivered what the rewrite was meant to — phone portability for managers on the floor, full-fidelity layouts on the wide office monitors they actually worked from, and one set of usability standards so the whole suite felt and operated as a single product. The component architecture later let a company-wide rebrand roll out across the suite far faster than it otherwise could have.
This case study covers what the rewrite produced. The methodology, research program, and SDLC work that made it possible for a UX practice to exist in the first place were built first, over the years before the rewrite started — that story is the companion case study, Establishing a UX Practice.
The component library was built so the majority of our desktop apps translated cleanly to a mobile form factor — one design intent, one set of components, two devices.
The product suite had grown into several separate Java desktop applications built by different teams. Overlapping UI patterns, inconsistent interaction models, duplicated design and engineering effort — and from the client's seat, an experience that didn't feel like a single product. Moving from one tool to another meant relearning conventions. There was no shared source of truth.
The rewrite needed something to anchor it. A modern stack alone wouldn't fix anything; it would just let the fragmentation regenerate in a new technology. The design system was that anchor — a shared foundation of standards, components, and patterns that every rewritten app drew from, so the new suite could ship as a single coherent product instead of as a faster version of the same problem.
Mobile made the timing urgent. As handheld devices moved into the workplace, teams were solving responsive challenges independently — compounding fragmentation rather than resolving it. iPad sharpened the case: technical constraints meant our mobile suite couldn't load the desktop versions on iPad, so clients on large-screen tablets were getting phone layouts on devices the size of laptops. They didn't have a vocabulary for what was wrong; they just knew it was. The case for a purpose-built responsive system became impossible to defer.
In addition to building the Figma components for our designers to use, I built dozens of usage examples for them to copy into their own designs — a small move that drove a disproportionate amount of the consistency the suite eventually had.
The design system came together as three pieces working together: a set of UI components, a shared responsive standard, and a library of canonical layouts and patterns. Every rewritten app drew from all three. Components were designed in pairs from the start — every desktop variant with a matching mobile one, sharing semantics so a workflow could move between devices without being redesigned — and co-documented in Figma and Storybook so designers and developers worked from the same source of truth. Documentation included stress-test stories, copy-ready examples, and developer reference material, but the move that actually drove adoption was earlier: engineering had input on every component as it was being built, not after. By release, the team that had to use the components had already shaped them.
More than 500 components, with multiple variants each — including responsive variants for desktop and mobile, designed together rather than retrofitted.
Design documentation for every component — specs, states, variants, accessibility notes — so any product team could pick up a component and use it correctly without asking.
Developer documentation was a key driver of adoption. Engineering had input on every component's technical implementation as it was built — so by release, the team that had to use the components had already shaped them.
Testing components rather than whole products let us use internal employees as a fast feedback source — early on, the only feasible source. Over the course of the engagement, that program matured from internal surrogates to direct testing with client end users; the long version of how that program was built lives in the companion case study.
Components alone weren't enough. Without explicit rules, teams were re-solving the same layout questions independently — what counts as a "tablet" breakpoint, how big the gutters should be, where a navigation rail belongs at compact widths — and producing different answers each time. The result was a suite that looked vaguely related but never quite the same. Shared standards ended that.
I authored a responsive design reference built on five principles: a shared column grid (12 columns on desktop, 8 on tablet, 4 on mobile), mobile-first sizing, size classes, platform-specific components, and canonical layouts. Once the reference existed, the question stopped being "what should we use?" and became "which of these is right for this screen?"
Borrowing the size-class concept, I mapped every supported device to a width and a height class (compact / regular / large). One design intent could then resolve predictably onto any device instead of being hand-tuned screen by screen.
| Screen width | Device class | Columns | Gutter | Min. margin |
|---|---|---|---|---|
| 0–599 px | Mobile | 4 | 8 px | 16 px |
| 600–839 px | Foldable / small tablet | 8 | 8 px | 16 px |
| 840–1023 px | Tablet | 8 | 8 px | 16 px |
| 1024–1379 px | Desktop | 12 | 16 px | 16 px |
| 1380+ px | Widescreen desktop | 12 | 16 px | 32 px |
Rather than leave each screen's structure to chance, I defined three canonical layouts that covered the vast majority of the suite's needs — so a team starting a new screen began from a proven structure, not a blank canvas.
The reference went well beyond grids and layouts — it also codified touch behavior, safe areas (home indicators, notches, the dynamic island), foldable postures, typography scaling, element sizing, and keyboard and drag-and-drop conventions — so a team could resolve almost any responsive question without inventing an answer.
All of the layout rules together at the widest desktop class — the 12-column grid, content corners, shared app chrome, and the List-Body canonical layout in actual use. This is the form factor managers ran the suite from in the office.
A 100+ product rewrite doesn't stay coherent on intent. It stays coherent on process. The governance model carried that load.
The foundation was an audit. Before any of the rewrite work began, I'd mapped the entire Java platform — every menu, screen, and configuration surface — into a single information-architecture artifact. That audit didn't just orient the team; it became the source of the rewrite backlog. Every legacy surface mapped to a component-team item, a priority, and an owner. New requests on top weren't just added; they were vetted with the requesting team before entering the queue, and prioritized so components with multi-product utility moved ahead of single-use solutions. The system grew toward leverage, not sprawl.
Decision authority was explicit. Weekly grooming meetings brought design, the two senior software architects, and the engineering team together. I held the final design call. The VP of Development or CTO could escalate or overrule under schedule pressure, and occasionally did. Where their calls accelerated a downstream release at the cost of design readiness, the result was UX debt in lower-priority areas. The model worked best when design and engineering timelines were aligned; where they weren't, schedule won. That's worth naming honestly: design authority is real, but it isn't absolute, and a governance model that pretends otherwise is a model that breaks under pressure.
The workflow itself iterated over the engagement. The earliest draft I have on hand handled releases informally. Once QA passed, the developer pushed the component to master, sent an email to the dev community, and the team celebrated.
An earlier draft of the component workflow. Release was informal: push to master, email the dev community, celebrate.
By the v11 version below, Release had become a structured phase of its own, with explicit steps and accountability between Testing & QA and the final shipment. Development and Testing & QA also picked up more internal structure along the way: explicit revision loops, test artifacts, and decision points.
The component team workflow at v11 (the version that landed). Intake, requirements, grooming, development, QA, and a formal Release phase. The process that kept 100+ products building from the same foundation.
Pushed for mobile components over internal resistance
Versions 1–7 were desktop-only. Architects resisted mobile parity, arguing our apps were too data-heavy for small screens — a reasonable position for phones, but one that left iPad orphaned. Clients on large-screen tablets were getting phone layouts and couldn't understand why. Version 8 became a full integration of desktop and mobile components in a single system. The iPad collision is what made the case impossible to defer; the design call was correct earlier than that.
Replaced Excel-style tables with touch-friendly list patterns
Dense data tables worked with a mouse but were unusable on touch devices. Touch targets, scrolling behavior, and information density all had to be rethought from the ground up — not just resized. The system shipped paired components: a desktop grid pattern and a mobile list pattern, with shared semantics so a product team could move between them without redesigning the workflow.
Introduced context-sensitive navigation for tablet
Persistent desktop sidebars were redesigned to hover and auto-dismiss on iPad, preserving content space while keeping navigation accessible. The same component had to behave differently by device — tablet couldn't be treated as a simple middle ground between desktop and phone.
The Approve Shifts manager flow — one of the first complex workflows redesigned for touch. Data-dense desktop tables were replaced with a focused list pattern: one pending record per row, clear approve/deny affordances, and no horizontal scroll.
Design status at departure
Version 8 complete — desktop and mobile components fully integrated, responsive behavior defined at the system level, and 100+ products shipping inside a unified shell.
Rebrand speed
The component architecture let a company-wide visual rebrand roll out across the product suite significantly faster than would otherwise have been possible. Because every product drew from the same components, the rebrand could be planned as a single structured inventory — more than 200 applications and configuration screens spanning desktop, mobile, and universal platforms across 15 functional areas — each item mapped to an owner, a size estimate, and a delivery order, rather than re-themed product by product.
Accessibility
Improvements were made within the constraints the organization would support — a color audit for color-blind friendliness, data-visualization contrast verification, and distinct iconography for status notifications so state was never communicated by color alone. No dedicated resourcing; opportunistic gains.
On the mobile push. I made the case for mobile parity earlier than the business was ready to commit to it, and couldn't make the argument stick on its own. The iPad collision is what made it unavoidable — clients on large-screen tablets getting phone layouts, with no good answer for why. Version 8 exists because that collision validated what I'd been advocating for. The right read isn't that I failed to persuade. The right read is that I diagnosed the problem before the business felt it, built the case over time, and delivered when the case became impossible to defer. That's a longer arc than I wanted, but it landed.
On the overrule path. The escalation route — VP of Development or CTO overrules under schedule pressure — was the right structural answer for an organization shipping at pace. It also occasionally moved components ahead of design readiness, with UX debt in lower-priority areas as the cost. The governance model worked best when design and engineering timelines were aligned; where they weren't, schedule won. I'd build the same model again, but I'd be more explicit up front about where the debt accumulates so it stays visible rather than absorbed.
If you want the process story — the research program, the methodology, the SDLC redesign, and the developer-facing design enablement that made this rewrite tractable in the first place — that's the companion case study: Establishing a UX Practice.
← → prev/next · scroll or pinch to zoom · drag to pan · Esc to close