TL;DR
WHY
To allow orders that a Supplier cannot fulfill to route to Suppliers who can fulfill the order
WHAT
Web platform in the healthcare space
HOW
Research synthesis, MVP release scoping, user flow mapping, UX design
Problem Framing
This platform allows users to order Durable Medical Equipment (DME) and Supplies. There are two main actors in this flow: Facilities and Suppliers. Facilities can order place orders for patients, and Suppliers then receive these orders to fulfill. Sometimes, and often enough from the volume of complaints we received about this use case, Suppliers cannot fulfill orders for a number of reasons. Prior to this feature rollout, orders would simply sit on the Supplier's order dashboard indefinitely or need to be canceled, which would make Facilities remake the order entirely and try a different Supplier.
With this in mind, our team set out to construct data model changes and a congruent experience with the rest of our platform to enable Suppliers to send orders they cannot fulfill to other Suppliers. This functionality is not limited to one time; an order may be sent more than once to find the right Supplier to fulfill it (however, our data shows we usually don't see more than one transfer).
With this in mind, our team set out to construct data model changes and a congruent experience with the rest of our platform to enable Suppliers to send orders they cannot fulfill to other Suppliers. This functionality is not limited to one time; an order may be sent more than once to find the right Supplier to fulfill it (however, our data shows we usually don't see more than one transfer).
Annotated Prototypes
Press the image below to view an annotated prototype of this experience and flow.
Artifacts + Flows
There are several moving parts in this experience. Similarly, we were building functionality to change a model relationship from 1:1 to one-to-many, adding exponentially scaling complexity. To align our team on what features should be scoped to each release and ensure we were thinking about the end-to-end flow wholistically, I created this user flows.
.jpeg)
.jpeg)
Reflection
What worked?
Our PM rigorously worked to appropriately scale the scope of each feature release which helped scale the designs down. This helped optimize design's capacity to focus on only specific parts of the experience and interaction design, namely the UI design of Vendor-to-Vendor communication. This is a highly visible, user-facing feature that was frequently requested. Delivering on this initiative saw immediate use as we tracked in Glassbox, our user session monitoring tool, and our data channels.
What to improve for next time?
As a technical constraint and experience change, opening the line of communication for vendors to communicate with each other changed our model from one-to-one to one-to-many. This relationship change as a technical lift and design complexity exponentially scales as you add actors to the model. For instance, what does the Communication tab look like in Vendor comments when there have been six transfers? These sort of edge cases both technically and design-wise were difficult to account for at the speed at which we were asked to deliver this feature. Similarly, involving engineering earlier in the discovery process would've saved time in not having to scrap some of the design directions for Supplier Transfer from technical constraints.
