Case Study 03 · Platform Design System · Onity Group

I built the design system while shipping the products that needed it.

Tokens, components, and workflow patterns extracted mid-flight from the platform's first two portals, so every later surface starts from parts instead of a blank file. The case table, the progress tracker, the exception lane, and the inline-validation pattern all live here now.

In active use · 2025–2026 Design Systems Enterprise Software Mortgage Servicing 0 to 1

Overview diagram of the platform design system showing the Loan Deboarding and Real-Time Inquiry portals feeding shared tokens, components, and workflow patterns

One system under two portals: what got extracted, and where it came from

Portals built on the system

Loan Deboarding + Real-Time Inquiry

Workflow patterns reused across the platform

inline validation, case table, progress tracker, exception lane

Every

Upload surface runs the validation pattern

adopted platform-wide after the first portal

Role

Senior UX Designersystems owner, sole designer

Team

Onity Grouptwo product squads consuming the system

Timeline

Ongoingbuilt alongside both portals, 2025 to 2026

Tools

Figma · Variables · Librariestokens, components, and pattern documentation

A note on confidentiality

I've modified the palette, names, and component details shown here to respect Onity Group's confidentiality. The sheets were recreated with AI assistance to convey the system's structure without exposing the actual product. The decisions and the reuse story are intact.

Snapshot

The short version.

If you only read three paragraphs, read these. Problem, change, and results in about a minute.

Problem

Two portals were being designed at once on a platform with no shared parts. Every screen decision was being made twice, drift was already visible between early prototypes, and everything later on the roadmap would have inherited the mess.

Change

I extracted the system from the products instead of designing it upfront. Tokens and a six-step type ladder first, then only the components and workflow patterns the portals proved they needed: the case table, the progress tracker, the exception lane, inline validation.

Results

Both portals ship from the same parts. The four core patterns are documented and reused across the platform, every upload surface runs the inline-validation pattern, and the next two roadmap projects started from this work instead of from scratch.

Foundations

Extracted, not invented.

A system designed before its products is a guess. This one was pulled out of two real portals mid-build, which meant every token and component had already survived contact with actual mortgage workflows.

Tokens before opinions

One palette, a six-step type ladder with a 12px floor, a 4px spacing base, and six semantic statuses. The statuses came straight from the portals: a release is on time, at risk, breached, waiting, released, or unassigned, on every surface, in the same colors.

Tokens · Type Ladder · Semantic Status

Foundations sheet with the recreated platform palette, grey ramp, six semantic status chips, six-step type ladder, and 4px spacing scale

Components earn their way in

Nothing entered the library until a portal needed it twice. The case table, status chips, buttons, and fields all graduated from product screens, so the library never grew faster than the platform's real needs.

Library Discipline · Reuse Over Speculation

Core components sheet showing the case table with status chips, button set, field states including error, and the inline validation pattern with plain-language messages

Workflow patterns

The patterns are the system.

Components are table stakes. What the platform actually reuses is behavior: how progress reads, how exceptions get owned, how errors get caught at the door. These were designed once, argued over once, and consumed everywhere since.

A progress tracker where waiting is first-class

Built for the Inquiry portal, reused by Loan Deboarding the same sprint. The "waiting on investor" state gets its own drawing, because that is where releases actually sit, and hiding it is how status meetings get born.

System Status · Reused Component

Progress tracker pattern in three rows: standard flow, waiting on investor with a flagged state, and complete, across six milestones from submitted to released

The exception lane: type, owner, SLA, log

Kickbacks, MERS updates, and investor delays used to live in email threads. The lane gives every exception the same four fields on any surface, and the audit trail stays on the release record where accounting can find it.

Exception Handling · Audit Trail

Three exception lane cards showing a formatting kickback with SLA countdown, a MERS update on track, and an escalated investor delay, each with type, owner, SLA chip, and activity log

Adoption

Did it spread?

A design system's only honest metric is whether people who are not its author build with it. The system is in active use; these are the reuse signals so far, stated plainly.

2 portals

Built entirely on the system

Loan Deboarding and Real-Time Inquiry ship from the same tokens, components, and patterns, with no visual drift between them.

Every

Upload surface runs inline validation

The validation pattern from the Loan portal was adopted for every upload surface on the platform: plain-language errors, caught at the door.

Next 2

Roadmap projects started from these parts

The teams behind the next two platform projects pulled from this library and its research templates instead of starting over.

Retrospective

What I took from this.

Two layers of impact that don't show up in a library file. What building it changed about how I work, and what it leaves behind for the platform.

Impact on me

A system extracted from real products beats a system designed in advance.

The temptation was to spend a quarter on foundations before either portal drew a screen. Extracting mid-flight was messier, but it meant every pattern had already survived a real workflow before it was named. The system never had to guess what the platform needed; the portals told it.

Tokens and type ladder locked before the second portal's first review
Nothing entered the library until a product needed it twice
What I'd do differently: write the pattern documentation at extraction time, not after the second consumer has already picked it up

Impact on the platform

The system is why the next products start faster.

The clearest sign it works: the parts get used by people who didn't build them. The patterns documented here became the starting point for the platform's next surfaces, and the research templates traveled with them.

Case-table pattern, status chips, owner, aging: consumed by both portals
Exception-lane workflow reused across the product
3-org interview synthesis template carried into the platform team's research