Finding the right abstraction

A small feature that changed where the decision belonged

The request sounded straightforward: allow one sales order to use more than one fulfillment location.

A sales order records what a customer wants to buy. Fulfillment is the later step where the company decides which items will ship, when they will ship and which warehouse they will come from.

The early product assumed one location for the entire order. That kept the interface simple, but it stopped working as soon as different items needed to ship from different warehouses.

The obvious response was to add more location fields and dropdowns to the order. That would solve the immediate request, but it would also make an already complex screen harder to understand and tie future shipping decisions to the wrong part of the process.

1. Asking when the decision was actually needed

At the time the order is created, the user may not know where each item will ship from. Stock can change. Items can ship at different times. The order describes the customer’s request, but it does not yet describe how the company will fulfill it.

This changed the question from “How do we add several locations to an order?” to “Where does the location decision actually belong?”

With product and engineering, I followed what would happen after an order with several locations was created. I also reviewed the steps with fulfillment specialists who understood how warehouses and shipments were managed in practice.

Looking at the full process made the answer clear: the warehouse belonged to the fulfillment, not the order.

2. Moving the decision to the right moment

Instead of asking users to choose several locations while creating the order, we delayed that decision until they created a fulfillment.

For example, an order with five items could later become two fulfillments. Three items might ship from Barcelona and two from Madrid. Each fulfillment would have one clear location.

This matched how the work happened and kept the order easier to read. It also avoided asking for information before the user had enough context to provide it.

We intentionally limited each fulfillment to one location. Supporting several locations inside one fulfillment would create more combinations, more error states and little practical value. If another location was needed, the user could create another fulfillment.

Keeping one location per fulfillment made both the screen and the system logic simpler.

3. Reusing what users already knew

The product and its design system were both still evolving quickly. The design system was the shared library of fields, buttons and behaviours used across the product. Creating a new location selector might have solved this case, but users would have to learn it and the team would have another piece to build and maintain.

I worked with the design-system team to reuse a location selector that users already knew. The change behaved like the rest of the product and required less engineering work.

The important design work was not the dropdown itself. It was deciding what the location applied to and when the user should choose it.

What changed

• No need to change how orders were created: Users could continue creating orders in the same way. They only chose a location later, when preparing each fulfillment.
• A familiar workflow for users: We reused an existing location selector and introduced no new interaction pattern, so no additional training was needed.
• A rule that worked for one location or many: Each fulfillment kept exactly one location. The same model worked whether the whole order shipped together or was split across several warehouses.
• Significantly faster to develop: We changed the simpler fulfillment step instead of rebuilding the more complex order. Reusing one existing selector also reduced the amount of new design and engineering work.

What I learned

Sometimes the simplest interface comes from moving a decision rather than designing a better dropdown or screen for it.

Limiting each fulfillment to one location was not a missing capability. It was what kept the rule clear. Supporting every possible combination would have made the product harder to use and harder to change later.

The change looked small when it shipped. The useful work was deciding where the location belonged in the process.