Beverage Fulfillment Platform
B2B Logistics
About
In 2021, I joined a newly formed team building a new portal for a US beverage fulfillment company. We had around three months to ship the first release and years of business logic to understand.
I worked on the product’s foundation for about six months. Over the next few years, I kept returning to help other designers build on it.
Years
Q3 2021 - Q1 2022
Role
Product Designer
Scope
Product Discovery, Order & Fulfillment Flows, UX/UI/IxD, Prototyping, Design System
Team Composition
1 Product Designer
1 Product Manager
3 Engineer
1 QA
2 Support Roles
Fulfillment problems rarely stay in one place
Picture this: an order is already in motion. Stock has been allocated. The warehouse has started work. Then something changes. A carrier can’t take the shipment, inventory comes up short, or the order hits an exception.
What looked like one delayed order quickly becomes a problem for several people. Someone needs to understand what happened, what it affects, and what can be done next.
This was the environment behind the portal we were rebuilding. Years of fulfillment logic were already embedded in the existing product and in the way the business operated every day.
One order could touch a lot of the operation
Underneath the portal, an order connected much more than shipping. It affected inventory, warehouse work, delivery details, and the rules behind each fulfillment path.
As we started mapping those connections, the real shape of the product became clearer. Rebuilding it meant understanding how those pieces depended on each other before deciding how they should work together in the new platform.
7
Fulfillment models
20
Batch workflows
13
Exception categories
30+
Product & admin areas
Understanding the system
In 2021, I joined a newly formed team tasked with building a new portal for a US beverage fulfillment company. It was the first engagement between the two companies, so there was a lot to learn quickly. Luckily, we weren’t starting from scratch. The existing portal held years of business logic, and I spent my first weeks going through reports, admin screens, and workflows while talking with the client team to understand how the operation actually worked. The challenge? Figuring out how all those pieces connected.
Spending hours tracing statuses, rules, and exceptions was tedious at times, but valuable. It helped me understand how orders, inventory, warehouses, and shipping depended on one another, and gave us a much clearer foundation for the new product.
Various system windows disclosed in the documentation
Making sense of the workflows
Once we understood the basics of the operation, we started mapping how work actually moved through the system. An order could touch inventory, a warehouse, a carrier, recipient information, and several business rules before it was ready to ship.
Going through these workflows, their statuses, actions, and exceptions helped us see which parts were unique and which kept repeating. The same information and decisions were showing up across different order types, just under slightly different conditions.
That gave us a much clearer way to think about the new product. Instead of rebuilding each legacy workflow separately, we could start organizing the system around the things they had in common.
A few of the flows we mapped while untangling the order lifecycle.
Orders became the center of the product
On paper, the workflows looked quite different. But once I started putting them side by side, the same thing kept happening: most of the work eventually came back to moving an order forward.
That changed how I approached the new portal. The order became the place where the rest of the system came together, giving us a common foundation instead of a collection of separate workflows.
The model had to work for real people
Mapping the workflows gave us a good model of how fulfillment worked on paper. The next step was seeing how well that model held up with the people who knew the operation much better than we did.
Learning from the people who knew the operation
A lot of the early context came from working closely with the Product Owner, BA, and people on the client side who dealt with fulfillment every day. They helped us understand the rules behind the workflows, including the cases that weren’t obvious from the existing portal.
Putting the first version in front of users
Access to users was limited, but we were able to test the first version with a small group of people familiar with day-to-day fulfillment. I prepared Figma prototypes of the main order scenarios and tested them during the observation sessions.
The feedback showed where the interface needed more context or a different sequence of actions, and we adjusted those parts before the first release.
The first version came together
By the time we moved toward release, DTC, DTT, and Wholesale were built around the same order structure. Each path kept the fields, services, and handling it needed.
I worked through the remaining details with engineering as the prototypes moved into implementation. That shared structure became the base for the first release.
Feedback changed the model
Sometimes those conversations confirmed what we already understood. Sometimes they changed the direction completely.
One example came while working through how business rules should be managed. Our first solution treated rules mostly as individual objects. Additional stakeholder input exposed a more useful way to think about them: people were trying to complete business tasks, and one task could involve several technical rules.
That shifted the conversation from managing rules to helping people manage the work behind them.
Key Insights
Users think in tasks, not in individual rules.
One business need often requires multiple technical rules.
Rules solving the same business task can be grouped together, reducing noise and cognitive load.