01 — PROJECT OVERVIEW
● 2025
Transforming Legal Descriptions into Actionable Intelligence
Helping title underwriters map property boundaries in minutes, not hours.
ROLE
Design Lead
TEAM
PM, Engineering, UX Research
TIMELINE
2024–2025
PLATFORM
Web (Galileo)
16
test legal descriptions
3
mid-fidelity mockup rounds
1
parcel type in V1 scope
Paused
for AI governance review
02 — OVERVIEW
Galileo is a property research and underwriting platform used by title insurance underwriters to evaluate risk on a property in question. I led design on a feature that automatically extracts and plots legal descriptions onto the map, replacing a manual, error-prone process. I owned problem framing, research, and design direction from early discovery through usability testing.
DESIGN STRATEGY · USER RESEARCH · PROTOTYPING · USABILITY TESTING
03 — THE PROBLEM
Legal descriptions define a property’s boundaries and are essential to establishing chain of title. But mapping one onto a property in question is complex and time-consuming, and underwriters had no good tool for it inside Galileo. Their options were tracing lines by hand on a GIS, using an external plotter, or handing the work to another team — and getting it wrong isn’t a minor inconvenience, it’s a risk to the accuracy of a title policy. Depending on parcel complexity, the manual process typically took an underwriter roughly 30–90 minutes per file.
“When mapping a legal, you can’t make any mistakes.”
UNDERWRITER FEEDBACK, DISCOVERY RESEARCH
04 — CONSTRAINTS
THE USER NEED
Underwriters needed a faster, more reliable way to confirm boundaries — especially for newly developed land, overlapping parcels, or files with no prior policy to reference.
THE TECHNICAL REALITY
8 of 16
The early extraction model could draw straightforward legal descriptions accurately. Multi-parcel and easement-heavy documents introduced OCR noise, ambiguous legal phrasing, and long cross-referenced calls that exceeded the model’s reliable context, so extraction broke before a plot could be trusted.
PROBLEM REFRAMING
INITIAL ASSUMPTION — Automate legal description mapping end-to-end.
RESEARCH REVEALED — Extraction only worked reliably on single-parcel, metes-and-bounds descriptions with no exception language, easements, or multiple parcels.
NEW UNDERSTANDING — This couldn’t be a fully automated tool — it had to be a verification tool, where the human catches what the model misses.
OPPORTUNITY — Design for fast, low-stakes correction, not just extraction.
05 — PROCESS
01 EMPATHIZE → 02 DEFINE → 03 IDEATE → 04 PROTOTYPE → 05 TEST → 06 NEXT STEPS
06 — RESEARCH
EMPATHIZE WORKSHOP
QUESTION — How do underwriters currently map legal descriptions? FINDING — Four manual workarounds exist today: visual GIS tracing, hand-mapping, net deed plotters, and tasking out to another internal team — none of them fast.
FIELD ANECDOTE
QUESTION — Do underwriters already think about boundary verification visually? FINDING — An underwriter’s technique of overlaying a prior survey on a recent aerial photo in Microsoft Word resonated with dozens of underwriters on a national call, validating a side-by-side comparison model.
STAKEHOLDER DISCOVERY
QUESTION — What does the team still need to align on before design can move forward? FINDING — Open questions across property linkage, information architecture, view, and customization shaped multiple rounds of design decisions.
The Decision: Where does this tool live?
EVIDENCE — Underwriters already verify boundaries through visual comparison across documents and mapping tools.
MAP TOOLS
PROS + Doesn’t tie the tool to one property · Easier to build technically
CONS − Risk of low discoverability · Similar tool adoption was already low
PROPERTY SNAPSHOT
PROS + Clear connection to the property · Easier to archive
CONS − Competes for limited panel space · Adds snapshot clutter
WHY WE CHOSE THIS
Stakeholder review led to a left-navigation entry point, balancing visibility with a dedicated workspace.
The Decision: Scoping V1 around what the model could actually do
EVIDENCE — 0 of 16 test descriptions with easements could be reliably drawn.
0 of 16
TEST DESCRIPTIONS WITH EASEMENTS COULD BE RELIABLY DRAWN
FULL VISION
• Real-time drawing and animation
• Multi-parcel and easement support
• Drawing and overlay tools
• Production-system connectivity
V1 SHIPPED SCOPE
• Single-parcel, metes & bounds descriptions
• Manual upload with copy/paste fallback
• Side-by-side review
• Editable calls table
08 — ITERATIONS
UPLOAD → EXTRACT → PLOT
ROUND 1 — 10/17/24
Large modal-first concept. Established the core flow.
OCR | EXTRACTED LEGAL
ROUND 2 — 10/24/24
Added side-by-side raw text and extraction review.
NAV | MAP | CALL TABLE
ROUND 3 — 11/11/24
Moved into a dedicated left-nav workspace.
09 — THE SOLUTION
A workspace designed for verification before confidence.
Underwriters upload a legal description and start extraction from the workspace. The system turns the source into structured calls, then generates a plot from those calls rather than hiding the model’s reasoning. The calls table gives reviewers a place to inspect bearings, distances, curves, and exceptions before accepting the geometry. Side-by-side review keeps the original description visible next to the plotted result, so discrepancies can be located, corrected, and re-plotted in context.
CORE WORKFLOW
Upload → Review → Plot → Correct.
01 UPLOAD OR PASTE
GOAL — Get the legal description into the system.
INTERACTION — Upload a document or paste text as a fallback.
OUTCOME — Works around inconsistent document quality.
02 REVIEW SIDE-BY-SIDE
GOAL — Verify extraction before trusting it.
INTERACTION — Raw OCR text shown next to the extracted description.
OUTCOME — Builds user trust before plotting.
03 PLOT AND INSPECT
GOAL — See the boundary visually.
INTERACTION — Plotted shape on the map with zoom and label controls.
OUTCOME — User can sanity-check against the map.
04 CORRECT
GOAL — Fix what the model got wrong.
INTERACTION — Editable call table.
OUTCOME — No need to start over on a partial error.
10 — TESTING & FINDINGS
3 participants — UserZoom prototype test, January 2025
2 of 3
PARTICIPANTS STRUGGLED TO LOCATE THE ENTRY POINT ON FIRST ATTEMPT
DISCOVERABILITY GAP
Participants first scanned the left navigation for familiar property, document, and map labels, then tried the general document area before abandoning the task. The legal-description entry point was too easy to miss because its icon did not communicate its purpose at a glance.
EDITING CONFUSION
Participants could not tell whether correcting a value in the calls table would update the plotted geometry, or whether they needed to edit directly on the canvas. The two editing surfaces lacked a clear ownership model, making people hesitate before committing a correction. One participant asked directly for more guidance mid-task, noting they weren’t sure how edits were supposed to work.
11 — OUTCOME · STATUS
Where this stands today
USER IMPACT — Aimed to cut the time and cognitive load of manual boundary mapping, especially for complex or ambiguous parcels.
PROCESS IMPACT — Established a reusable verification-first pattern for future AI-assisted extraction features in Galileo.
ORGANIZATIONAL IMPACT — Usability findings are directly shaping the next round of toolbar and correction-flow design.
VALIDATION STATUS — Evidence supports the interaction model and scoping decisions — not production adoption, since the planned MTP study hasn’t run yet.
12 — REFLECTION
If I did this again, I’d push earlier for a rough, low-fidelity usability check on the entry-point decision before investing in polished mockups. This project sharpened how I think about designing around a partially reliable AI system — the interface has to assume the model will sometimes be wrong and make correction fast and low-stakes, not just make the happy path look good.
01 — Test discoverability earlier, before high-fidelity investment.
02 — Build AI governance review into the plan from day one.
03 — Design the correction flow before the happy path.
FINAL TAKEAWAY
“Designing for an unreliable model isn’t about hiding its limits — it’s about making the human’s correction as fast as the machine’s mistake.”
13 — NEXT STEPS
01 Clear AI governance review → 02 Run 5–10 user MTP study → 03 Launch v1.1 to production
