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
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: the first design language system, which brought consistency to terminology, components and layouts.
v2 (facelift): after a mood board and competitor review, I restyled the whole platform and rebuilt the system to be code-ready, so engineers could ship consistent UI without me in every review.
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 for every contact and property.
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 · Results
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.
