contact

confidential product case study

Designing a Sales Channel Into an Enterprise Platform, from Zero

Legal services were sold and fulfilled manually, outside the product.

I designed the Service Center: a client-facing discovery and purchase experience, plus the back-office portal that operates it.

role
Product Designer
scope
Service Discovery, Request Flow, Backoffice Portal
collaboration
Cross-functional Product Team
platform
Responsive Web Application
project type
Net-new · 0 to 1
2
portals, one system
5+
services made sellable
0 → 1
net-new surface
The Service Center, with legal services grouped by category and a Suggested for you section.

tl;dr / 30-second version

the problem

A legal operations platform offered 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.

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.

context

Revenue without a product surface

A legal operations platform managed entities, contracts and compliance for enterprises. Around that core sat 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 of an existing flow, it was a net-new surface: the product had no service-purchasing path before this work shipped.

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

Me
Product Design
Product Manager
Priorities / scope
CTO
Architecture / review
Engineers
Delivery
Ops team
Forms / fulfillment
Client-facing

Service Center

01
Available Services:Discovery organized by category
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
KYCA 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 additional informations
04
Ticketssupport queue, deliberately list-only for V1
05
Adminuser management and workspace-level white-label configuration

discovery

The catalog already existed. In spreadsheets and forms.

The services weren't hypothetical: they were being sold manually. That gave discovery real operational ground truth to design from.

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 flowconversion
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

wizardjurisdiction 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. 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 requestsbackoffice
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 and when it'll be done. The operator asks what's in the queue and whether they're on time. Renaming and pruning per audience costs almost nothing in build and removes a whole 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.

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 work turned 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

Specifying 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

A handful of moderated sessions, especially on the jurisdiction step, would have de-risked the flow's hardest moment directly.

scope

Sequence the backoffice earlier

Designing the request-details loop earlier would have surfaced the "additional information" workflow sooner.

Want to discuss the work in more detail?_

Additional context about my process, design decisions, and responsibilities can be discussed during an interview.

Get in touchLinkedIn
vm_
private access
restricted case study

This work is shared privately.

Some project details are protected due to confidentiality. Enter the password provided to you to view this case study.

Press Enter or use the button below.
← back to selected work
confidential case study