case study 02 / traact service center_
Designing a Sales Channel Into an Enterprise Platform, from Zero
Traact's legal services were sold and fulfilled manually, outside the product. I designed the Service Center: a client-facing discovery and purchase experience, plus the backoffice portal that operates it.
Company
Traact
Role
Product Designer
Focus
Service Conversion UX
TYPE
Status
● Delivered · in build
tl;dr / 30-second version
The problem
Traact offered legal services (formations, certificates, dissolutions) but had no product surface to sell or operate them. Requests ran through external forms and manual coordination.
My role
Sole designer on the workstream, designing both sides from zero: the client-facing purchase experience and the internal backoffice portal, in weekly cycles with the PM and CTO.
What shipped
Service discovery, a full request wizard with jurisdiction logic, KYC compliance flow, request tracking, and a complete backoffice portal, all development-ready.
The result
A purchase channel enabling 5+ revenue-generating legal services to be sold and operated inside the product, delivered as the specification for the V1 build.
context
Revenue without a product surface
Traact manages entities, contracts and compliance for enterprises. Around that core sits a natural service business: Certificates of Good Standing, DBA registrations, entity formations, dissolutions, amendments. Clients wanted these. The company sold them. But the selling happened outside the product: external form tools, email threads, manual tracking. Every sale worked despite the process, not because of it.
The brief
Design the missing surface, from zero: a Service Center where clients discover, understand and purchase services, and a backoffice where the team operates every request. This wasn't a redesign. Nothing existed before it.
my role / system map
Both sides of the counter
Every client-side action creates backoffice work. I designed the two surfaces as one system with two vocabularies, which is what kept them coherent.
Where I owned the problem
Mapped the live service catalog and its operational forms into product flows
Designed discovery, request wizard, KYC, and client-side request tracking
Designed the backoffice portal: dashboard, request management, tickets, admin
Extended existing design system patterns instead of inventing new ones
Documented flows, states, and jurisdiction logic for the engineering handoff
The team around it
Product Design
Priorities / scope
Architecture / review
Delivery
Forms / fulfillment
Client-facing
Service Center
01
Available Services:
discovery organized by category, with a "Suggested for you" section leading
02
Service details:
what's included, timeline and pricing before any commitment
03
Request wizard:
full-page multi-step flow with jurisdiction-aware questions
04
KYC
a three-step compliance gate: ownership, identity, authority
05
Requests overview:
status tracking in the client's vocabulary
Internal
Backoffice Portal
01
Dashboard:
request volume and SLA compliance at a glance
02
Request management:
KPI cards, list and kanban views, filters
03
Request details:
full client submission, status, assignee, and an "additional information" loop
04
Tickets
support queue, deliberately list-only for V1
05
Admin
user management and workspace-level white-label configuration
discovery
Operational forms
The ops team ran requests through external form tools. I mapped every field of every service form into the design system, keeping what fulfillment genuinely needed and questioning what it didn't.
Jurisdiction variance
US legal services change by state: different fields, fees and requirements per jurisdiction. This variance was the core complexity the wizard had to absorb without exposing it upfront.
Compliance & conversion
Legal services demand verified requesters, so KYC wasn't optional. And the business goal was explicit: sell. Every flow decision was weighed against drop-off risk, not just usability in the abstract.
core tension
Legal service requests demand rigor: jurisdictions, signatories, compliance. Conversion demands the opposite, the shortest possible path to commitment. The design had to make rigor feel like progress, not friction.
design decisions
Three decisions that shaped the channel
Each one was argued, prototyped and reviewed in weekly cycles with the PM and CTO before build.
/01
Full-page wizard, not a modal
Request flow
Conversion
Option A — considered
Modal wizard with an X
Request flow in a modal over the Service Center. Lighter to build, but an X button one pixel away from every step is an invitation to abandon.
Option B — chosen
Full-page flow, "Back to Service Center" link
The wizard takes the whole page, matching the website's formation wizard pattern. Exit exists, but as a deliberate navigation, not a reflex.
Why this direction
A purchase flow is a commitment ritual. The full page gives each step room to breathe, keeps visual continuity with the public website wizard clients had already seen, and replaces the impulsive X with an intentional way out. Small structural choice, direct effect on drop-off.
/02
A dynamic jurisdiction step, not a mega-form
WIZARD
Jurisdiction logic
Option A — considered
One generic form for all states
Every possible field for every jurisdiction in one form, most of them irrelevant to any given request. Complete, and completely hostile.
Option B — chosen
Conditional jurisdiction-specific step
The wizard asks for jurisdiction early, then generates a dedicated step containing only that state's questions, with conditional logic for multi-jurisdiction requests.
Why this direction
State-by-state variance was the honest complexity of the domain. Hiding it entirely would break fulfillment; showing all of it would break conversion. The dynamic step shows each client exactly their complexity and nothing else, and it scales: adding a new state means adding data, not redesigning the flow.
/03
Same data, two vocabularies
Client requests
Backoffice
Option A — considered
One shared table for both surfaces
Same columns, same labels, client and backoffice. Consistent for the system, confusing for the client: "Owner", "SLA" and audit columns are internal language.
Option B — chosen direction
Audience-specific vocabulary per surface
Backoffice keeps operational terms. The client view translates: "Owner" becomes "Assigned to", "SLA" becomes "Estimated Completion", redundant columns dropped.
Why this direction
The client asks "who's helping me and when will it be done". The operator asks "what's my queue and am I on time". Same records, different questions. Renaming and pruning per audience costs almost nothing in build and removes an entire category of support confusion before it exists.
recurring theme
Conversion design in B2B isn't persuasion, it's the removal of hesitation. Every decision above trades a moment of doubt (an X button, an irrelevant field, an internal acronym) for a moment of clarity.
the product
The system, screen by screen
→ Key flows from the development-ready delivery. Full prototype available on request.
Available Services: discovery built to sell
A "Suggested for you" section leads, open by default. Categories collapse individually, and each card offers "Learn more" (about, what's included, timeline, pricing) before the request CTA. Informed commitment converts better than blind clicks.
Request wizard with jurisdiction logic
Basic information with jurisdiction selection, a dynamically generated state-specific step, signatory information, and order summary with transparent pricing. Multi-jurisdiction requests branch conditionally.
KYC: compliance as three clear steps
Ownership information, identity verification, authority confirmation. Icon-based step indicators reuse an existing design system component, and the flow gates requests without ambushing the user mid-purchase.
Backoffice: the operational cockpit
Dashboard with request volume and SLA compliance, request management with KPI cards and list or kanban views, and full request details in a stepped modal mirroring exactly what the client submitted, with an "additional information" loop back to the client.
validation
Weekly cycles, operational ground truth
01
Grounded in real fulfillment
The flows weren't invented from personas: they were reverse-engineered from forms and processes the ops team already used to deliver these services manually. If a field existed, fulfillment needed it or it died.
02
Weekly PM and CTO review
Every cycle shipped organized Figma flows for direct stakeholder review. Feedback turned into concrete changes fast: a wider KYC modal, a new jurisdiction-questions step, an entry dashboard for the backoffice.
03
Pattern consistency as a rule
New surfaces reused established patterns: the platform's sidebar structure, an existing icon-based stepper, the stepped modal format a design colleague had defined. Two portals, one recognizable product.
04
Documented for build
The delivery included updated PRD documentation: jurisdiction-specific field tables, flow diagrams, email notification templates, and a standardized pricing format across all services.
outcomes
What was delivered and what it meant
Created
A channel that didn't exist
From zero to a complete, development-ready purchase and operations system spanning two portals.
Enabled
5+ services made sellable
Certificates, DBA, entity registration, dissolution and amendments, each with jurisdiction logic and transparent pricing.
Operational
Fulfillment inside the product
Request tracking, SLA visibility, assignment and client communication loops replace email threads and external forms.
business impact
The Service Center turned Traact's manual service sales into a product surface built for conversion, delivered to engineering as the specification for the V1 build.
On a 0 to 1 workstream, the design is the business case: it defines what can be sold, how it converts, and what it costs to operate.
reflections
What this work taught me about designing for revenue
/01
0 to 1 inside an existing product is its own discipline
Greenfield freedom, brownfield constraints. Every new surface had to feel native to a platform clients already trusted, which meant the design system wasn't a limitation to work around but the fastest path to credibility.
/02
Operations is a user
Designing only the client side would have produced a beautiful funnel feeding a broken kitchen. The backoffice deserved the same design attention as the storefront, because the client's experience after purchase is made there.
/03
Conversion is mostly subtraction
The highest-impact decisions removed things: an X button, irrelevant jurisdiction fields, internal jargon from client tables. In B2B purchase flows, trust grows in the absence of confusion.
with hindsight
What I'd do differently
Measurement
Define the funnel metrics with the design
Discovery-to-request and request-completion rates were the obvious success measures. Specifying their instrumentation as part of the handoff would let the V1 launch prove the conversion thesis with data.
Users
Test the wizard with real clients pre-build
Validation ran through stakeholders who knew the clients deeply. A handful of moderated sessions on the prototype, especially the jurisdiction step, would have de-risked the flow's hardest moment directly.
Scope
Sequence the backoffice earlier
The client side led the timeline; the backoffice followed. Designing the request-details loop earlier would have surfaced the "additional information" workflow sooner, since it shapes both surfaces.
Next case