02 / Scope · B2B SaaSProduct Designer

From stalled handoffs to a shared implementation system.

Scope connected software vendors, their customers, and implementation experts. I helped turn that manually coordinated service into a product that made ownership, progress, and the next action visible from intake through signed contract and delivery.

Role: Product Designer
Focus: 0→1 product design · Workflow design · Research
Delivery: 7+ capabilities across 20+ sprints

Newest Scope workspace while an expert match is pending — Newest platform version: one workspace connected matching status, conversation, stakeholders, meetings, and attachments. Fictional project data is used throughout.

Platform scope

A service workflow became a complete product.

I designed the connected experience across the entire implementation lifecycle. Each role saw the same project and progress, with the controls, context, and decisions relevant to their part of the work.

01Request
02Match
03Proposal
04Contract
05Implementation
06Complete

One lifecycle connected the service from initial context to delivered work.

Software vendor

Initiate and stay informed

Start the request, decide who supplies the details, and retain visibility into the customer’s implementation.

Customer

Provide and approve

Add project context, meet the expert, review the proposal, and sign the contract.

Expert

Scope and deliver

Accept a match, define deliverables and pricing, prepare the contract, and update progress.

Guided request

Collect the context needed for an implementation without asking users to write a brief from scratch.

Automatic match

Route a qualified project to the right expert and make the acceptance window visible.

Shared workspace

Keep the vendor, customer, and expert aligned on one project and one current state.

Structured proposal

Turn discovery into deliverables, timing, and a price the customer can review.

Integrated contract

Carry accepted terms into the agreement and expose signature status to every party.

Visible delivery

Move deliverables through progress and completion while updating the customer.

Portfolio-level visibility

The product also showed vendors how the program was performing.

A partner dashboard brought expert activity, customer adoption, contract value, funnel movement, and archived-project reasons into one view. That expanded Scope from a place to manage one implementation into a tool for understanding the implementation program.

Scope vendor dashboard with expert, customer, contract value, funnel, and archive-reason data — Dashboard design iteration with populated program-level data.

01 / The operating problem

The service moved through people. The product had to move the work.

Implementation projects crossed three organizations: a software vendor initiated the work, a customer supplied context and approvals, and an expert scoped and delivered the implementation. Much of that coordination still lived in email, calls, spreadsheets, and customer-success follow-up.

The product page showed a project and its milestones, but its largest surface was an empty chat. When a user returned, they still had to work out whether to wait, send a message, review something, or ask another stakeholder to act.

Business performance / measured in days

01Time to project submission

02Time until the agency sends project details

03Time to contract signature

View the earlier project experience

Older Scope vendor project page while waiting for an expert match — A vendor could see matching was underway, but the page offered little beyond waiting and an empty chat.

Older Scope customer project page after matching with an expert — After matching, coordination shifted into chat and a separate scheduling link.

02 / Behavior, not assumptions

“Unresponsive” was the label. Hotjar showed the behavior.

A funnel review made the cost of stalled projects visible: “unresponsive” represented 40 projects, or 71% of the cases in the surviving view. That number described where work stopped. It did not explain why.

We reviewed Hotjar sessions twice weekly. The recordings showed customers and experts trying to connect at different times, returning to a project without a clear action, or losing momentum between visits. The design problem was coordination across time, roles, and tools.

Donut chart with unresponsive as 40 cases and 71 percent of the displayed outcomes — Surviving funnel view: unresponsive was the dominant recorded outcome.

Research themes: did not know how to respond, forgot, deprioritized, or abandoned the project — The research separated different behaviors that had been grouped under one operational label.

Anonymized frame from a Hotjar playback of the Scope project chat — Hotjar session excerpt, anonymized for this portfolio.

03 / Defining the system

The project became the shared object.

I organized the experience around one implementation project: its state, participants, decisions, documents, and deliverables. The same project could show different actions to each role while keeping everyone aligned on the same source of truth.

The supporting specification made the behavioral requirements concrete: provide useful defaults, show what is expected now, reveal the full process, identify every stakeholder, and keep proposal and contract decisions attached to the work.

Cropped Notion product requirements for the customer and vendor project experience — Supporting product requirements connected user goals to the redesigned project experience. Account and browser information have been removed.

04 / Reducing the first delay

Replace one intimidating prompt with a guided intake.

The original intake gathered a project through one long, generic set of questions. Users and vendors stalled because it was unclear how much detail was expected, and the answers often felt templatized rather than useful for matching.

I split the request into three stages—Logistics, Big picture, and Details—so each screen had one kind of decision. Optional fields lowered the pressure to know everything up front, while examples explained what useful detail looked like.

Before / one submission

Nine questions in one pass

A single form mixed logistics, constraints, technology, and the project objective.

Earlier Scope project intake with nine questions on one page — Earlier project-details flow.

After / progressive context

Logistics → Big picture → Details

Three smaller decisions established ownership first, then collected the context needed for matching.

Three focused stepsClear ownership · optional detail · useful examples · automatic matching

Later Scope Details step with contextual guidance and examples — Later intake design: guidance and the working form stayed visible together.

What changed

Answer uncertainty in context

Examples showed the level and kind of detail that would help an expert respond.

Separate optional from essential

Users could move forward without pretending to know every technical constraint.

End with a concrete outcome

“Get an expert” described what completing the request would unlock.

The ownership branch

Vendor starts→Who fills out details?→

VendorCustomer receives invite

→Automatic expert match

When the customer owned the details, the vendor entered an email and stopped. Scope handled the invitation and next steps, removing an unnecessary relay.

05 / Designing the handoffs

One workspace. Role-aware action.

Each milestone changed what the project needed. Matching introduced the people. The proposal turned discovery into price, timing, and deliverables. The contract made the agreement reviewable and signable. Progress kept the customer informed after the sale.

I designed those transitions as states of one product, with the project context remaining visible while the primary action changed for the person responsible.

Newest Scope proposal editor populated for the Beacon Checkout Migration project — Newest proposal experience: the expert could save progress, structure the estimate, and send it to the customer without leaving the project.

Newest Scope contract populated for the Beacon Checkout Migration project — Newest contract experience: proposal terms carried into a reviewable agreement with visible stakeholder and signature status.

06 / Maintaining momentum

Make waiting a state—and action impossible to miss.

Notifications were designed around the work a user could do: no immediate action, optional action, required action, and an empty state. In-product banners oriented people who returned; email brought them back when another participant had advanced the project.

This preserved the value of asynchronous communication without asking users to monitor another inbox inside Scope.

Early handwritten notification model connected to three user goals — Early model: separate in-project guidance, return prompts, and email calls to action.

Notification component states designed for Scope — Notification system: distinguish waiting, optional action, required action, and empty states.

07 / Outcome

The service became a product the business could operate, measure, and grow.

Across 20+ sprints, I designed and shipped 7+ capabilities spanning intake, matching, project coordination, proposals, contracts, notifications, and delivery. The result was an end-to-end implementation workspace built around clear ownership rather than manual follow-up.

1shared project across three roles

3time-to-progress KPIs measured in days

7+capabilities shipped across the lifecycle

20+sprints of iterative product delivery

Good workflow design gives every person enough context to act—and enough confidence to wait when the next move belongs to someone else.

Next / Comparative Market Analysis