Modernizing a regulatory platform

Modernizing a legacy regulatory SaaS platform whose UI was fused to its database — and learning that the constraint itself, not the look, was the real problem.

this project shows

end-to-end ownership, systems thinking, design-system authorship, cross-functional collaboration, working with ambiguity in a constrained, legacy environment.

deliverables:

Complex B2B / government regulatory SaaS

my role

Product Designer — owned the core forms-and-tables interaction

outcome

A from-scratch design system and a modernization strategy that redirected the company toward a clean-slate rebuild

the constrains

The UI was fused to the database schema. One entity per view, related data buried under "connections."

The stack was old. Vanilla Java, no component library. Every new pattern cost real engineering time.

Government reliability requirements. Changes had to be safe and slow.

The directive was "just a facelift." Don't change the patterns users are trained on.

Reframing the brief

The product wasn't just looked outdated — it was a database admin UI wearing a thin skin. The userflow was the schema. To complete a workflow user has to jump back and forth between many tabs at the bottom tab bar.

First move:
prettier, same bones
try prototype->

First, a clean visual pass over the broken flow, on purpose.

Proof to the company that design changes how a product is perceived, before asking for expensive structural change.

build the design system for scale

With the visual direction accepted, the next step was durability. A one-off facelift doesn't scale. The moment you add a new application type or workflow, inconsistency creeps back in. So we built the design system on top of it: a shared set of components and rules so that once the first version ships, the product can grow without redesigning from scratch each time.

One view instead of ten tabs

Pulled data scattered across separate database tables into one decision-ready view — so a regulator can approve or reject in one place, without touching the schema.

A side panel that edits a record and surfaces related data in place. One new pattern at a time, the interface gets less like a database and more like a tool.

the real answer:

Coordinator queue

a dense, scannable table of all 15 applications. Every workflow state is represented so a coordinator can triage without opening anything. The work starts here.

Application Record

one application fully unpacked: requirements, their status, who owns each one, blocking vs. non-blocking. The coordinator acts here.

Request Threads

async back-and-forth with the applicant, surfaced as a dedicated view rather than buried inside the record. Communication is first-class, not an afterthought.

Profile Record

the person behind all their applications. Shared across everything they've ever filed, not scoped to one application.

try prototype ->