Nector connects consumers with verified financial-service providers across credit repair, tax, insurance, and investment. The interesting design challenge wasn't the matching; it was that the compliance requirement meant I couldn't design a typical marketplace. No global directory. No direct messaging. No "browse everyone." I had to design by subtraction.
Consumer
- → Guided onboarding
- → Ranked match cards
- → Guided filter widget
- → Conversational chatbot
- → Rates provider after chat
Matched only
Conversations are bound to matches
Compliance gate
No directory. No DM-anyone.
Provider
- → Credential verification
- → Independent or team account
- → Dashboard: leads + response rate
- → In-chat scheduling
- → Rates consumer after chat
Different consumers have fundamentally different mental models when looking for financial help: some want to be guided, some know what they want, and some can't even phrase it yet. I designed three distinct entry points that feed the same underlying state layer rather than three separate products.
Ranked Match Cards
Matchmaking engine surfaces top providers as swipeable cards. Interested/Not Interested actions feed signal back, improving the next round. Good for the consumer who doesn't know where to start.
Guided Filter Widget
For consumers who know what they want: service type, goal, location. Deterministic search that gets out of the way. Designed to be invisible to the power user.
Conversational Chatbot
For consumers who can't phrase what they need. Natural language input translates to a matchmaking query without exposing the underlying model. Good for the user who would abandon a form.
State is shared across all three: A provider dismissed in swipe mode won't be re-surfaced by the chatbot. A filter result marked "Interested" reflects in the ranked view. The UIs are different doors into the same room.
The most consequential design decision in the chat product was what not to design.
There is no global user directory. There is no "message any provider" affordance. Conversations are bound to matches. I made the compliance behavior structural, enforced by the absence of features rather than warning copy. You can't misuse something that doesn't exist.
Provider Info Card
Collapsible card in chat header: specialization, response rate, rating, "View Profile." The consumer never leaves the thread to remember why they're there.
In-Chat Scheduling
Meeting proposal renders inline as a card with Google + Outlook integration. The conversation is the calendar, with no separate surface and no app switching needed.
Bidirectional Rating
Both sides rate. Pending feedback gates new matchmaking flows: non-intrusive reminders first, then a soft block. Rating data feeds matching quality; treating it as optional would undermine the engine.
Most cross-platform projects design web first and "adapt" for mobile. I pushed back on that. Native and web have different physical realities, and treating one as canonical produces a clumsy experience on the other. I ran both tracks in parallel from discovery through handoff.
Web
- Multi-column layouts
- Hover states + cursor affordances
- Modal dialogs
- Keyboard navigation
- Dense data tables
Native Mobile
- Single-column, thumb reach
- Tap states + haptics
- Bottom sheets + drawers
- Swipe gestures
- Simplified data display
Same tokens. Same component semantics. Different physical forms. A button on native has the right tap target; the same button on web has the right hover state.
Team accounts: permission split, not two products
Company Owner and Sales Agent share the same IA, navigation, and component set. Permission-gated controls are hidden or disabled for agents, not moved to a different app. Less product to build, less to maintain, fewer handoff failures between role types.
Gate ratings when the data is foundational
Most rating systems are encouraged-but-optional. I argued for gating when the rating data feeds matching quality: if the signal is poor, the engine degrades silently. Non-intrusive reminders show first; the gate activates after. The consumer friction is small; the platform integrity benefit is large.
Scheduling as an in-chat object, not a separate surface
The consumer never needs to think about "going to a calendar" because there is no calendar to go to; meeting proposals are chat actions. This eliminated an entire navigation problem and kept context-switching to zero during what's already a cognitively loaded financial conversation.
Compliance as a design constraint, not a legal disclaimer
Financial services regulations create UX patterns that fight against instinctive marketplace design: no free browsing, no unsolicited contact, gated interactions. The challenge wasn't understanding the rules; it was convincing stakeholders that the best UX was to enforce them architecturally rather than plastering compliance warnings over an otherwise open product. I made the case by showing how design-by-subtraction actually reduced the cognitive load on users.
Shared state across three discovery modes
Three discovery modes that share state sounds elegant in a diagram; it gets complex in practice. I had to map every possible state transition: what happens when a user dismisses someone in swipe mode, searches for them in filter mode, and then asks the chatbot to find someone "like that"? Getting this right required thinking in state machines before thinking in screens.
Two platforms with no canonical primary
Designing web and native in parallel meant every decision I made had to work in both contexts simultaneously. When I hit a pattern that worked beautifully on one platform and awkwardly on the other, I had to decide whether to find a third approach that worked well on both, or whether the platforms genuinely warranted different patterns at that point, and be explicit about that divergence in the system documentation.