Real Estate AI Platfrom
Goliath has valuable sellers and buyers data, but the product was built entirely by engineers, and users exported CSVs to work somewhere else.
I designed the platform from the ground up: two design systems, 10+ features (workflows, filters, inbox, deals, tasks, contact and property pages, onboarding, settings), each for desktop and mobile with full states and edge cases.
Role
Product Designer,
Product Owner, QA
Tools
Figma, Linear, Codex, Notion, Framer
Year
2025-2026
01 · The starting point
A tool used only by the team that built it
was going public.
A small, engineering-led team: the CEO was an engineer, the co-founder ran sales. The platform worked, but the terminology didn't match how people talk, the wording changed from screen to screen and dense data screens drove people away.
My Contacts was a flat table of 155,000+ owners with a wall of phone numbers and no way to act on them. Sales calls and the internal team said it plainly: users preferred exporting to CSV over using the app.
"I just want to be able to find people that might be looking to sell, filter or create lists of people based on a common characteristic, and skiptrace or export those contacts."
Max Yuan, co-founder
describing the core job
Before: Goliath 1.0, Contacts table
02 · How I worked
Ship, learn, fix.
Goliath moved fast, so research had to move with it. Instead of long studies, I built research into the weekly rhythm and made sure every release taught us something.
Close to users
The product was dense, the wording didn't match how investors and agents talk, and people left the app to call, take notes or track deals.
Matching what users already know
For every feature I studied the industry-standard tools our users already used, so Goliath felt familiar from day one. Then I designed where we could do better.
From idea to release
I owned each feature from idea to release, balancing what users needed, what the business needed and what engineering could build
Learning after launch
Each release went out, the team flagged issues in Slack and we fixed them fast. That loop shaped the next round of design.
03 · Foundations
Two design systems, both code-ready.
Each system was built to match how engineers build, so they could ship consistent UI without me in every review.
v1 design language system brought consistency to terminology, components and layouts
v2 is a restyled version
04 · Deep dive: Automations
Making automation feel effortless.
Workflows let investors and agents automate outreach, follow-ups and handoffs: skip-trace new probate properties, text sellers around an address, remind people about appointments, assign a deal and notify the team.
Industry-standard CRMs already had strong automation, and we built on those patterns. But a blank builder suits savvy team leads. Ask most agents to build every flow from scratch, and most automations never get built.
Templates first, custom when you need it.
Beginners start from a ready-made workflow and adjust it; power users still get a fully customizable builder. I pushed for this over copying the competitor's build-from-scratch default.
05 · Deep dive: Filters
One filter system
Investors filter 150k+ contacts and properties by dozens of criteria, combined with AND and OR. The old version split this across tags, lists and raw CSV files, which made it confusing and hard to use.
One system
The same filters for contacts and properties, so people learn it once.
Search first
"Recently used" on top, because the list is long but most people reuse a few.
Saved filters in folders
My filters and Team filters replace static lists with views that update themselves. Shipped as proposed.
06 · Learnings
At Goliath I learned how to think like a Product Owner: writing tickets, working through bugs with engineers and testing releases meant I couldn’t just hand over designs. I had to weigh what users needed against what the business needed and what we could actually build.
I learned when to copy and when not to: familiar patterns made it easier for people to switch, but sometimes the familiar thing was exactly what didn’t work for our users. Most of all, I learned that a good design system is what lets a small team move fast, because nobody has to wait for me to check every screen.
