Study
Case Study 04
Client
Union Home Mortgage
Discipline
Tooling
Discipline
Systems

Union Home Mort­gage

A backend-heavy team was shipping fast with no design system behind it.

Union Home Mortgage was building a set of internal applications to replace parts of a larger, more complex lending platform. Each tool was being built on its own, and they shared very little structure. As the number of applications grew, so did the gaps between them.

Focus
  • UI kit
  • Design system
  • WCAG tooling
Scope
  • Internal tools
Context
  • Backend engineering team
  • No design partner
Union Home Mortgage on laptop Union Home Mortgage on iPhone, loan officer directory Union Home Mortgage on iPhone, borrower dashboard

No two applications looked or worked the same way.

Layout, hierarchy and interaction changed from one application to the next. The team was mostly backend engineers, and usability and presentation weren't their focus. Users paid for that with extra effort on every screen.

Without a shared structure, every decision started from scratch. The applications got harder to build and harder to use.

A lending application screen before the system: bright colors, inconsistent typography, and no clear hierarchy.
Before the system, the team had been focused on functionality only.

The work focused on creating a system the team could actually use.

The goal was a shared foundation, so the UI matched across tools and each new application started with most decisions already made.

That meant building components atomic enough for a backend-heavy team to implement without a designer in the room, and locking down type, color, and grid so nobody had to make those decisions twice.

The system had to fit how the team already built software.

I built a UI kit and design system around how the team already worked. The components were reusable and the patterns were simple to implement.

The team was mostly backend engineers, so every component had to be clear enough to build from the written guidance alone.

Screens from multiple internal applications sharing the same components, grid, and type system.

Atomic design principles

Interfaces broken down into small components the team could reuse anywhere.

Screens from multiple internal applications sharing the same components, grid, and type system.

Grid system

One grid for every application, so layouts lined up from tool to tool.

Screens from multiple internal applications sharing the same components, grid, and type system.

Typography

A grotesk sans-serif picked for legibility, with a clear hierarchy for data-heavy screens.

Screens from multiple internal applications sharing the same components, grid, and type system.

Color palette

A shared color scale from the brand's primary and secondary colors, checked automatically against the WCAG 2.0 4.5:1 contrast ratio.

Shared components made the applications easier to build and to use.

With shared components, nobody had to rebuild the same pattern for each application.

Layouts and hierarchy became predictable, so screens were easier to scan. Tools that used to feel unrelated now felt like one product.

The team moved faster, and the tools got easier to use.

New applications came together faster, and they matched the rest.

Internal users found the tools easier to navigate, and each new tool took the team less effort to design and build.

Refined application screens showing a cohesive experience across the internal tools.

A shared foundation meant nobody had to make the same decision twice.

Next project

Proof Digital Identity on iPhone, profile and credentials Proof Digital Identity on iPhone, Digital ID onboarding Proof Digital Identity on iPhone, launchpad Proof Digital Identity on iPhone, final launchpad design

05 / 07Identity

Proof Digital Identity

Sharing sensitive information only works when people understand what they're sharing.

An MVP for secure, deliberate sharing.

Focus
  • MVP
  • Cross-platform design system
Scope
  • iOS
  • Android
Context
  • Paused before launch
View case study: Proof Digital Identity