UI/UX Case Study

Stewart Rate Calculator
Redesign

Luke McKean · Lead UI/UX Designer · 8 months · Stewart Title

Title Insurance·Fee Estimation·Web App

01 The Problem & Users

The Problem

Agents couldn't get estimates fast.

The original calculator required multi-screen navigation with inconsistent input patterns. Agents didn't know which fields were required, drop-offs were high at the loan info screen, and state-specific fee logic was hidden.

Unclear required fields
Multi-screen friction
Hidden state logic
High support call volume

The Users

Title Agents

Primary users. Generated estimates daily for buyers and sellers. Needed fast, reliable outputs without calling support.

Internal Teams

Used the tool for quality checks and compliance review. Needed outputs to match state-specific rate logic exactly.

Newer Agents

Less familiar with title fee structure. Needed clear guidance on required fields and what each output meant.

02 Constraints

Timeline

8 months from discovery to handoff — tight for 20 states with custom rate logic per jurisdiction.

Stakeholders

Two stakeholders with competing goals. Business wanted power-user flexibility. Product wanted simplicity.

Tech Stack

Built on Azure with MUI as the component base. Custom components had to align with existing MUI patterns.

State Logic

20 states with unique fee calculation rules. State-specific details had to surface without overwhelming the form.

Existing Brand

Design had to match Stewart's broader standards. No blank-slate freedom — patterns from other products carried over.

Team Size

One designer alongside 3 engineers and a PM. I owned research, wireframes, high-fidelity design, and handoff.

02 Constraints: Requirements Scope

The complexity of the project was evident before a single wireframe was drawn. Field specs covered multiple search modes, state-by-state parcel logic, and edge-case match scenarios — all of which the UI had to surface without overwhelming agents.

State-by-state requirements matrix

State-by-state requirements matrix

Policy type and covered party options

Policy type & covered party options

Requirements spanned transaction types, policy types, endorsements, and state-specific pricing logic — all captured before design began.

03 Design Approach: Hi-Fi Design

Mockups informed a single-screen layout with smart defaults, contextual fields, and inline state-specific guidance. MUI formed the component base.

Commercial transaction with endorsements

Commercial transaction — with endorsements

Residential transaction results with totals

Residential transaction — results with totals

1

Research

Support tickets + agent interviews revealed key drop-off points.

2

Flow Mapping

Mapped the full journey, identified redundant steps.

3

Wireframes

Single-screen approach with smart defaults and contextual fields.

4

Design System

MUI-based components, aligned to Stewart brand standards.

5

Handoff

Figma library, CSS tokens, redlines PDF with annotations.

04 Tradeoffs

Simplicity vs. Power

Gave Up

Buried advanced options (endorsements) behind a progressive disclosure section that only appeared after core inputs.

Got Instead

Cleaner entry for most agents. Power users still had access, just not on page load.

Single Screen vs. Guided Steps

Gave Up

Removed the step-by-step wizard that held users' hands through each screen.

Got Instead

Faster flow for experienced agents. Added inline tooltips and a confirmation step on the state selector to compensate.

Flexibility vs. Accuracy

Gave Up

Removed some open-ended optional fields to reduce confusion.

Got Instead

Fewer incomplete submissions and edge-case bugs. Users couldn't enter data in ways that broke the rate logic.

BEFORE

Before and After comparison

05 Outcome & Learnings

20

States with custom rate & fee logic

+15%

Increase in agent adoption

-10%

Reduction in support calls

What I Learned

  • Domain complexity doesn't justify UI complexity — smart defaults and progressive disclosure can handle both.
  • Testing with real agents exposed gaps no internal review would catch.
  • Tight alignment between design tokens and CSS variables made handoff nearly frictionless.

What's Next

  • Saved estimate templates so agents can reuse common scenarios.
  • Real-time zip code and property type validation to catch errors earlier.
  • Analytics hooks to track which transaction types cause the most drop-off.
Rate Calculator — delivered product

Rate Calculator — delivered product

Modal component library

Modal component library

Thank you

Luke McKean

Lead UI/UX Designer