Contractor Hub
Matching homeowners with the right contractor — by fixing the question they were asking, not the search they were doing.
The brief masked the real issue.
The existing platform had been redesigned twice in 18 months. Drop-off rates remained above 60% at the contractor search step. The team's assumption was that the search UI was confusing. After five minutes of user research, a different picture emerged.
- Users couldn't complete searches because they didn't know what type of contractor they needed
- The search taxonomy was built around trade names — plumber, electrician, roofer — not around problems users could recognise
- Admin staff were fielding calls daily from users who had submitted the wrong contractor type
- Contractor response rates were low because jobs were being matched to the wrong specialisation
Every failed search was a lost homeowner, a wasted contractor slot, and an admin support ticket. The business was funding a bad mental model with customer service.
The product was solving the wrong problem.
“Nobody says 'I need a plumber'. They say 'my ceiling is leaking'. The entire product was built for a user who doesn't exist.”
Discovered through 6 informal user interviews over 3 days. Every participant described their problem in outcome language — not a single person used trade terminology unprompted. The search model had been designed by people who already knew the answer.
Translating the insight into a design direction.
How might we help homeowners describe their problem in their own language, and let the system translate that into the right contractor type?
How might we educate users about contractor types before they search? — Discarded: adds friction before value, assumes users want to learn
How might we let users browse by symptom with a visual guide? — Discarded: too complex for Phase 1, validated the language problem but over-engineered the solution
What was built, and what wasn't.
- Symptom-based problem intake (replacing trade-based search)
- Admin matching interface — assigning contractor type based on intake
- Contractor notification and response flow
- Homeowner status tracking — submitted, matched, responded
- In-app messaging between homeowner and contractor
Validates matching model first before adding communication complexity
- Contractor profile pages
Out of scope Phase 1 — homeowners trust admin curation over self-serve profiles at this stage
- Payment integration
Separate workstream, different team
Draw the system before drawing the screen.
The admin layer was a deliberate Phase 1 decision — it let us validate the matching model without building a fully automated classifier. Admin acted as the intelligent fallback while we gathered data on how often automatic categorisation would have been correct.
Decisions made, and the trade-offs accepted.
| Decision | Why | Trade-off |
|---|---|---|
| Admin-led matching instead of automated contractor assignment | We didn't have enough data to trust an automated classifier. Admin involvement let us validate the categorisation model before automating it. | Slower matching speed. Admin bottleneck at scale. Requires hiring plan for Phase 2. |
| Symptom-based intake form instead of trade-based search | Every user interview confirmed users think in outcomes not trades. Building a search for a mental model nobody has was the root cause of the drop-off. | Users who do know their contractor type are forced through an extra step. Small price for the majority case. |
| Email notification to contractors in Phase 1 instead of in-app messaging | Reduces build complexity. Validates whether contractors respond at all before investing in a messaging system. | No message threading. Admin can't see response status inside the platform. Tracked manually in Phase 1. |
| Status page for homeowners showing three states only: Submitted, Matched, Responded | Research showed homeowners' anxiety peaked during silence — they didn't know if anything was happening. Three states eliminated that without over-engineering. | No granularity — 'Matched' could mean anything from assigned 1 hour ago to assigned 3 days ago. A timestamp was cut from Phase 1 scope. |
How it evolved from V1 to final.
Initial concept used a free-text symptom search with autocomplete. User testing revealed that autocomplete suggestions still used trade vocabulary — defeating the purpose. Users typed 'leaking' and got suggestions like 'Plumbing — leak repair'.
Replaced free-text with a structured selector: location in the home → symptom category → severity. Removed all trade vocabulary from the UI entirely. Admin testing showed a 40% reduction in reassignment rate compared to the old search.
Added the parallel admin matching interface. The key decision here was keeping the admin view minimal — a queue of unmatched jobs, each with the symptom description and a single dropdown to assign contractor type. No extra features.
The screens, with context.
The symptom selector uses plain language throughout — zero trade terminology. The three-step structure (location → symptom → severity) reduces cognitive load by chunking the decision.
Three-state tracker. Deliberately simple — research showed homeowners needed to know something was happening, not every micro-step of the process.
The admin interface shows only what's needed to make a matching decision: the symptom description, the property address, and the contractor type dropdown. Nothing else.
Email-first in Phase 1. The notification includes the symptom description (not the trade category) so contractors can self-assess fit before responding.
What changed.
What I'd do differently.
The brief is rarely the real problem.
Three UI redesigns had failed before this one because every brief asked for 'a better search experience'. The actual problem was the taxonomy. I'd do the research first now — before accepting any brief about a specific surface.
Admin as a product layer, not a workaround.
I initially saw the admin matching step as a temporary compromise. It turned out to be the most valuable data source we had — every admin decision was a labelled training example for the eventual classifier. Design the manual process well and automation becomes easier.
Three status states were enough. I almost added seven.
My V2 status tracker had granular states: Submitted, Under Review, Categorised, Matching, Matched, Contractor Notified, Responded. User testing showed people understood 'Submitted → Matched → Responded' immediately and found the extra states confusing. Simplicity won.
Next Project