Designing the systems that transformed how ops specialists serve thousands of law firms
Role
Principal Product Designer
Timeline
8 weeks (September–November 2024)
The context
Everyone deserves to know when they're being sued.
Proof is a legal tech platform that handles service of process: the constitutional requirement that hat someone must be formally notified when they're sued. Proof's platform connects thousands of law firms with a nationwide network of vetted process servers.
The reality
Legal tech is complex.
Behind every successful serve is an ops team navigating layers of complexity: federal law, state law, county rules, court jurisdiction, judge preferences, client preferences. Can you serve on Sunday in Florida? Does this county require a notary? Is this a garnishment or a summons? Does that change the timeline? Before this project, that knowledge lived in spreadsheets, Slack threads, and people's heads.
Layers of complex rules and regulations that need to managed.
The Problem
There was no task system. At all.
Specialists worked from a dashboard that showed jobs needing attention, but there was no structure for what needed attention or who should handle it. The most common workflow was "babysitting": a specialist would open 15-20 browser tabs, one per job, and watch them move through the serve lifecycle. When something needed action, they'd jump in. Then go back to watching.
Work got distributed through Slack and tribal knowledge. A supervisor would say "hey, can someone look at the Smith case?" and whoever was available would grab it. A client could have five serves open with the same recurring issue and no one would notice - because people were thinking about individual jobs, not client relationships or task types.
This created compounding problems:
No ownership.
Enterprise clients paying premium rates got the same anonymous service as self-serve accounts. No one knew their history.
No visibility.
We couldn't measure performance because there was nothing to measure. Everyone did everything.
No specialization.
Some work requires deep expertise (affidavit prep, compliance review). Some requires speed (dispatch, basic QA). Treating all work as interchangeable meant neither got optimized.
No scalability.
Every acquisition, every new service line, every enterprise deal required ad-hoc workarounds. There was no model for how to organize work.
The old dashboard that ops was working out of. A choose-your-own-adventure with no ownership.
Mapping what "work" actually meant
Before I could design a task system, I had to define what a task even was.
I mapped the complete job lifecycle, from the moment a job enters the platform to final completion, and identified every point where ops might need to act. This revealed 10+ distinct task types, each with different triggers, different required information, and different actions.
The "babysitting" workflow existed because the system had no concept of these distinctions. A job needing dispatch looked the same as a job needing affidavit review. The only way to know was to open it and look.
Complete job lifecycle map revealing 10+ distinct task types and routing gaps
Designing the system architecture
I designed a three-layer model: Teams, Roles, and Routing Logic.
Teams create client ownership
Every client maps to a team. Enterprise clients get dedicated teams. Platform clients map regionally. Dispatch handles exceptions across all teams.
Roles create specialization
10 distinct roles, mapped from the lifecycle work. Each has clear responsibilities, required skills, and measurable outputs.
Routing logic creates predictability
Tasks find the right person through rules, not luck. The system prioritizes continuity (same person on a client's work) while ensuring coverage.
Documentation as a design artifact
The complexity here…10 roles, multiple team types, routing logic with fallbacks, just couldn't live in wireframes. I wrote a comprehensive spec covering every task type: what triggers it, what information surfaces, what actions are available, SLA expectations, escalation paths.
This document became the single source of truth for the build and survives today as institutional knowledge.
Internal documentation for cross-functional reference on how to handle tasks.
The outcome
From tabs to tasks
Specialists went from babysitting 15-20 browser tabs to working a structured queue.
Dedicated enterprise support
When a paralegal calls, they reach someone who knows their account.
Measurable performance
For the first time, we can see who's excelling and where training is needed.
Foundation for growth
Acquisitions now have an integration playbook.
The new tasks dashboard for operations teams @ Proof
"Project Phoenix" launched November 4, 2024.