UI/UX Case Study

Stewart
Spectr

Centralizing 25M+ title records into a fast, usable research tool

Role

Lead UI/UX Designer

Timeline

3 Months

Team

1 PM · 2 Engineers

Luke McKean

01

The Problem & Users

The Problem

Decades of data, locked and unusable.

Title policies, lender packets, parcel records, and property data were scattered across disconnected systems in inconsistent formats.

Researchers spent hours on a single request and still returned incomplete or conflicting results.

The business needed one tool that could handle national-scale searches and return data people could actually act on.

Who Used It

Title agents needing fast address and policy lookups

Researchers and analysts doing multi-record data work

25M+

Title policies consolidated

140M+

Parcels covered across the US

Key question: How do you centralize vast historical data at national scale without creating a confusing or fragile research interface?

02

Constraints

⏰ Timeline

3 months from kickoff to developer handoff. No buffer for major pivots. Decisions had to stick.

🔧 Tech Stack

Built on MUI Design System with Azure backend. Custom components had to extend MUI, not replace it.

👥 Stakeholders

Three stakeholders with different mental models of what the tool should do. Alignment required multiple rounds of scoping.

🔍 Data Complexity

Six distinct search types: Address, APN, Single Match, Multiple Match, Grantor/Grantee, and Legal. Each with its own logic and edge cases.

📱 Multi-Surface

Desktop and mobile both required, but most heavy workflows happen on desktop. Mobile needed simplification, not just a resize.

⚙ No Prior Baseline

No existing design system for this product. Every pattern had to be built and documented from scratch for the dev handoff.

03

Discovery & Research

Stakeholder interviews produced a detailed search field spec across all six search types. These spreadsheets became the source of truth for what the interface needed to handle.

Search module spec: Address, APN, Grantor/Grantee, Legal

Confirmation page and parcel detail data structure

04

Design Approach

1

Discover

Analytics review confirmed drop-off points. Stakeholder interviews mapped all six search types. Agent interviews surfaced what they actually wanted: specific fields, smarter defaults, less manual work.

2

Architect

Top IA decision: consolidate search, filters, and address detail into a single surface. Fewer screens meant fewer context switches, which was the core pain agents described.

3

Wireframe

Low-fi focused on cutting steps. Removed redundant fields, set smarter defaults, and surfaced provenance inline instead of behind a separate page.

4

Build & Test

Remote moderated testing with 8 agents. Three rounds of iteration, each targeting a specific finding from the previous session, not a gut-feel redesign.

Design principle: Every decision had to reduce friction, not just look cleaner. If cutting a step broke something downstream, it stayed.

05

Wireframes

Early sketches focused on reducing steps, surfacing defaults, and mapping the search-to-result flow before touching Figma.

IA flow: search types and result paths

Express search fields and form structure

Express search match and parcel detail

06

Design System

What We Built

MUI as the foundation.

Every component extended MUI rather than replacing it. This kept the handoff clean and dev velocity high.

Components documented:

Buttons
Loading states
Icon buttons
Form inputs
Data tables
Drawer / modal patterns

Handoff included: component library in Figma, tokens mapped to CSS variables, and a single-file PDF with redlines and accessible annotations.

07

High Fidelity: Search Interface

The search interface consolidated all search types under one tabbed surface. Single surface = fewer context switches.

08

High Fidelity: Search Results

Results displayed inline below the search form. Policy records expand with document image access and a direct link to parcel detail.

09

High Fidelity: Parcel Detail

What Agents See

The parcel detail view surfaced everything agents needed in one place, with no second lookup required.

Sections included:

Property summary with map
Owner and vesting details
Legal description
Sale history with recording dates
Physical characteristics
Assessment and tax data
Direct Starter and Reference Starter policies with document image links
Claim alerts surfaced inline

Parcel detail: property data, policies, and claim alerts in a single view

10

Tradeoffs

Single surface vs. separate screens

Chose: Single surface

Agents needed to cross-reference data constantly. Separate screens forced too many context switches. The tradeoff was a denser layout, managed through strong visual hierarchy and whitespace.

Medium fidelity prototype vs. high fidelity

Chose: Medium fidelity

Timeline didn't allow full high-fi before testing. Medium-fi was enough to validate key flows. Fine-grained visual feedback came later, which was acceptable because structural problems cost more to fix than visual ones.

Custom components vs. pure MUI

Chose: Extended MUI

Building entirely custom would have blown the handoff. Extending MUI kept dev velocity high and design consistent. The cost was some visual constraints the team had to work around.

Provenance visible by default vs. on demand

Chose: On demand (badge + drawer)

Showing provenance everywhere cluttered the results table. Testing confirmed agents only needed it for specific records. A badge and expandable drawer gave access without noise.

11

Outcome & Learnings

+80%

Agent adoption (A/B pilot, 500 agents)

2 hrs

Saved per agent per week

18%

Fewer address lookup errors

What I Learned

Provenance matters more than polish. Agents cared most about trusting the data source. Visual refinement was secondary to showing them where results came from.
Filter visibility is a UX problem. Active filters that aren't visible don't exist to the user. Surfacing them as pills cut confusion immediately in round-two testing.
MUI is a tool, not a constraint. Working within the system and extending it strategically kept dev handoff clean and helped the team ship faster.

Next Steps

Ship analytics hooks
Expand component coverage for localization
Follow-up usability test focused on enterprise workflows

Agents said: "faster and less stressful." Stakeholders reported fewer support tickets within weeks of launch.

Thank you