
Encounter Submission Portal
Turning operational complexity into a clearer service workflow
What began as a rough concept for a regulated B2B workflow needed to become something sales could show, stakeholders could align around, and engineering could build from. I led the work from early concept through MVP prototyping by running recurring workshops, mapping the workflow, and creating a demoable experience that clarified requirements and accelerated action.
Role
Lead designer from concept to MVP prototype
Teams
SMEs, sales, engineering, product, operations
Scope
Workflow definition, concept exploration, prototyping, handoff, feedback loop
13%
reduction in bounce rate
40%
increase in engagement
24%
increase in task completion
Challenge
Sales needed a way to demonstrate encounter submission workflows to prospective clients, but the product began as a rough idea with fragmented requirements, technical complexity, and regulatory constraints. The team needed something more concrete than a napkin sketch to validate feasibility, communicate the opportunity, and move toward build readiness.
Why it mattered
Without a clear prototype, the organization had difficulty aligning on what the product should do, how the workflow should function, and how to communicate its value to clients. The opportunity was not just to design screens, but to make a complex service process understandable and actionable.
Who needed what
Customers
Business
Internal teams
My role
I led design from concept to MVP prototype, helping translate a rough product idea into a clearer workflow and a demoable experience that sales, leadership, and engineering could all use.
I was responsible for
Key partners
What became clear
01
The workflow needed to be discovered, not just drawn
The challenge was not simply to turn requirements into screens. The team needed structured conversations to uncover edge cases, dependencies, compliance concerns, and workflow realities before the product could become credible.
02
Shared understanding was as valuable as the prototype itself
The recurring workshops created alignment across business, product, and technical perspectives. That shared understanding helped the team move faster and gave the work momentum beyond a static artifact.
03
A strong prototype could do multiple jobs at once
The MVP prototype became a sales tool, a validation tool, and a build-starting artifact for engineering. That made it more than a design deliverable — it became a working bridge between concept and execution.
How the experience evolved
Phase 1
FRAME THE WORKFLOW
I started by running biweekly workshops with SMEs, sales, and technical partners to surface requirements, identify edge cases, and define what the core submission journey needed to support in an MVP.

Phase 2
PROTOTYPE THE CONCEPT
Once the key workflow was clearer, I translated the conversations into rapid clickable prototypes that sales could use in demos and teams could react to quickly. These prototypes were iterated after each workshop and informed by ongoing feedback.

Phase 3
CREATE A BUILDABLE HANDOFF
From there, I created a spec-less handoff package with annotated components, acceptance criteria, interaction notes, and a living component inventory so engineering could begin implementation without waiting for a traditional spec backlog.
Key design decisions
Structure the work around recurring workshops
Rather than trying to solve the workflow in isolation, I used recurring workshop sessions to surface complexity early and create alignment across business, sales, and technical partners.
Prototype early to make the service understandable
I used rapid clickable prototypes to turn abstract requirements into something teams and prospects could react to, making the workflow easier to test, explain, and improve.
Design the handoff to accelerate action
Instead of stopping at a presentation-ready prototype, I packaged the work so engineering could begin implementation immediately, reducing the delay between concept validation and build.
Tradeoffs + Constraints
Constraint: The product began as a rough concept with incomplete requirementsResponse: I used workshops and journey mapping to surface hidden requirements, edge cases, and compliance constraints before locking in the MVP direction.
Constraint: Multiple groups needed different things from the same artifactResponse: I built the prototype to serve as a sales demo, a validation tool, and a handoff mechanism, allowing one artifact to support several organizational needs.
Constraint: The team needed momentum before a full spec process could catch upResponse: I created a spec-less handoff package with enough structure and annotation for engineering to begin work without waiting on a formal backlog of documentation.
Outcomes + Signals
What changed
For usersThe workflow became clearer, more structured, and more grounded in real operational needs instead of staying abstract or fragmented.
For the organizationThe work accelerated client feedback, improved stakeholder alignment, and created a bridge from concept to implementation that reduced ambiguity and increased momentum.
Encounter Submission Portal
Turning operational complexity into a clearer service workflow
What began as a rough concept for a regulated B2B workflow needed to become something sales could show, stakeholders could align around, and engineering could build from. I led the work from early concept through MVP prototyping by running recurring workshops, mapping the workflow, and creating a demoable experience that clarified requirements and accelerated action.

Role
Lead designer from concept to MVP prototype
Teams
SMEs, sales, engineering, product, operations
Scope
Workflow definition, concept exploration, prototyping, handoff, feedback loop
13%
reduction in bounce rate
40%
increase in engagement
24%
increase in task completion
Challenge
Sales needed a way to demonstrate encounter submission workflows to prospective clients, but the product began as a rough idea with fragmented requirements, technical complexity, and regulatory constraints. The team needed something more concrete than a napkin sketch to validate feasibility, communicate the opportunity, and move toward build readiness.
Why it mattered
Without a clear prototype, the organization had difficulty aligning on what the product should do, how the workflow should function, and how to communicate its value to clients. The opportunity was not just to design screens, but to make a complex service process understandable and actionable.
Who needed what
Customers
Business
Internal teams
My role
I led design from concept to MVP prototype, helping translate a rough product idea into a clearer workflow and a demoable experience that sales, leadership, and engineering could all use.
I was responsible for
Key partners
What became clear
01
The workflow needed to be discovered, not just drawn
The challenge was not simply to turn requirements into screens. The team needed structured conversations to uncover edge cases, dependencies, compliance concerns, and workflow realities before the product could become credible.
02
Shared understanding was as valuable as the prototype itself
The recurring workshops created alignment across business, product, and technical perspectives. That shared understanding helped the team move faster and gave the work momentum beyond a static artifact.
03
A strong prototype could do multiple jobs at once
The MVP prototype became a sales tool, a validation tool, and a build-starting artifact for engineering. That made it more than a design deliverable — it became a working bridge between concept and execution.
How the experience evolved
Phase 1
FRAME THE WORKFLOW
I started by running biweekly workshops with SMEs, sales, and technical partners to surface requirements, identify edge cases, and define what the core submission journey needed to support in an MVP.

Phase 2
PROTOTYPE THE CONCEPT
Once the key workflow was clearer, I translated the conversations into rapid clickable prototypes that sales could use in demos and teams could react to quickly. These prototypes were iterated after each workshop and informed by ongoing feedback.

Phase 3
CREATE A BUILDABLE HANDOFF
From there, I created a spec-less handoff package with annotated components, acceptance criteria, interaction notes, and a living component inventory so engineering could begin implementation without waiting for a traditional spec backlog.
Key design decisions
Structure the work around recurring workshops
Rather than trying to solve the workflow in isolation, I used recurring workshop sessions to surface complexity early and create alignment across business, sales, and technical partners.
Prototype early to make the service understandable
I used rapid clickable prototypes to turn abstract requirements into something teams and prospects could react to, making the workflow easier to test, explain, and improve.
Design the handoff to accelerate action
Instead of stopping at a presentation-ready prototype, I packaged the work so engineering could begin implementation immediately, reducing the delay between concept validation and build.
Tradeoffs + Constraints
Constraint: The product began as a rough concept with incomplete requirementsResponse: I used workshops and journey mapping to surface hidden requirements, edge cases, and compliance constraints before locking in the MVP direction.
Constraint: Multiple groups needed different things from the same artifactResponse: I built the prototype to serve as a sales demo, a validation tool, and a handoff mechanism, allowing one artifact to support several organizational needs.
Constraint: The team needed momentum before a full spec process could catch upResponse: I created a spec-less handoff package with enough structure and annotation for engineering to begin work without waiting on a formal backlog of documentation.
Outcomes + Signals
What changed
For usersThe workflow became clearer, more structured, and more grounded in real operational needs instead of staying abstract or fragmented.
For the organizationThe work accelerated client feedback, improved stakeholder alignment, and created a bridge from concept to implementation that reduced ambiguity and increased momentum.
Encounter Submission Portal
Turning operational complexity into a clearer service workflow
What began as a rough concept for a regulated B2B workflow needed to become something sales could show, stakeholders could align around, and engineering could build from. I led the work from early concept through MVP prototyping by running recurring workshops, mapping the workflow, and creating a demoable experience that clarified requirements and accelerated action.

Role
Lead designer from concept to MVP prototype
Teams
SMEs, sales, engineering, product, operations
Scope
Workflow definition, concept exploration, prototyping, handoff, feedback loop
13%
reduction in bounce rate
40%
increase in engagement
24%
increase in task completion
Challenge
Sales needed a way to demonstrate encounter submission workflows to prospective clients, but the product began as a rough idea with fragmented requirements, technical complexity, and regulatory constraints. The team needed something more concrete than a napkin sketch to validate feasibility, communicate the opportunity, and move toward build readiness.
Why it mattered
Without a clear prototype, the organization had difficulty aligning on what the product should do, how the workflow should function, and how to communicate its value to clients. The opportunity was not just to design screens, but to make a complex service process understandable and actionable.
Who needed what
Customers
Business
Internal teams
My role
I led design from concept to MVP prototype, helping translate a rough product idea into a clearer workflow and a demoable experience that sales, leadership, and engineering could all use.
I was responsible for
Key partners
What became clear
01
The workflow needed to be discovered, not just drawn
The challenge was not simply to turn requirements into screens. The team needed structured conversations to uncover edge cases, dependencies, compliance concerns, and workflow realities before the product could become credible.
02
Shared understanding was as valuable as the prototype itself
The recurring workshops created alignment across business, product, and technical perspectives. That shared understanding helped the team move faster and gave the work momentum beyond a static artifact.
03
A strong prototype could do multiple jobs at once
The MVP prototype became a sales tool, a validation tool, and a build-starting artifact for engineering. That made it more than a design deliverable — it became a working bridge between concept and execution.
How the experience evolved
Phase 1
FRAME THE WORKFLOW
I started by running biweekly workshops with SMEs, sales, and technical partners to surface requirements, identify edge cases, and define what the core submission journey needed to support in an MVP.

Phase 2
PROTOTYPE THE CONCEPT
Once the key workflow was clearer, I translated the conversations into rapid clickable prototypes that sales could use in demos and teams could react to quickly. These prototypes were iterated after each workshop and informed by ongoing feedback.

Phase 3
CREATE A BUILDABLE HANDOFF
From there, I created a spec-less handoff package with annotated components, acceptance criteria, interaction notes, and a living component inventory so engineering could begin implementation without waiting for a traditional spec backlog.
Key design decisions
Structure the work around recurring workshops
Rather than trying to solve the workflow in isolation, I used recurring workshop sessions to surface complexity early and create alignment across business, sales, and technical partners.
Prototype early to make the service understandable
I used rapid clickable prototypes to turn abstract requirements into something teams and prospects could react to, making the workflow easier to test, explain, and improve.
Design the handoff to accelerate action
Instead of stopping at a presentation-ready prototype, I packaged the work so engineering could begin implementation immediately, reducing the delay between concept validation and build.
Tradeoffs + Constraints
Constraint: The product began as a rough concept with incomplete requirementsResponse: I used workshops and journey mapping to surface hidden requirements, edge cases, and compliance constraints before locking in the MVP direction.
Constraint: Multiple groups needed different things from the same artifactResponse: I built the prototype to serve as a sales demo, a validation tool, and a handoff mechanism, allowing one artifact to support several organizational needs.
Constraint: The team needed momentum before a full spec process could catch upResponse: I created a spec-less handoff package with enough structure and annotation for engineering to begin work without waiting on a formal backlog of documentation.
Outcomes + Signals
What changed
For usersThe workflow became clearer, more structured, and more grounded in real operational needs instead of staying abstract or fragmented.
For the organizationThe work accelerated client feedback, improved stakeholder alignment, and created a bridge from concept to implementation that reduced ambiguity and increased momentum.