Content

Item Level Fulfillment

AE + aerie app customers couldn't mix fulfillment in a single order - user were either shipping everything or picking everything up. We set out to change that, giving users per-item control directly from cart. With no defined success metrics, I helped drive the project through iterative app designs, building clickthrough flows for iOS and Android, and running unmoderated remote testing. However, the project was cut for several reasons, and none that had to do with the UX.

Item Level Fulfillment

AE + aerie app customers couldn't mix fulfillment in a single order - user were either shipping everything or picking everything up. We set out to change that, giving users per-item control directly from cart. With no defined success metrics, I helped drive the project through iterative app designs, building clickthrough flows for iOS and Android, and running unmoderated remote testing. However, the project was cut for several reasons, and none that had to do with the UX.

COMPANY

American Eagle Outfitters

Role

Product Designer

TOOLS

Axure, Sketch

Year

2022

COMPANY

American Eagle Outfitters

Role

Product Designer

TOOLS

Axure, Sketch

Year

2022

COMPANY

American Eagle Outfitters

Role

Product Designer

TOOLS

Axure, Sketch

Year

2022

Problem

Problem

AE + Aerie customers shopping on the app had one fulfillment option per order: either ship everything to home or pick everything up in store. There was no way to mix. If you wanted one item fast and another shipped, you had to place two separate orders. Leadership identified this as a missed opportunity. Omnichannel shoppers (those who engage across both digital and physical channels) tend to have higher lifetime value.

The ask came from internal business strategy, not a specific customer complaint or competitor feature, with leaders noticing the demand for better order fulfillment flexibility. Success metrics were undefined at that point - the team had to figure out what "good" looked like from scratch.

Strategy

Strategy

The first job was to make the problem testable before any significant design investment was made. That meant narrowing down what we were actually asking users to do, and finding the fastest path to signal.

What this meant:

  • Validate the mental model before solving the UI

  • Treat mixed findings as useful signal, not failure

We landed on a model where customers could choose, per item, whether to ship to home or pick up in store, all within the cart to checkout flow. The split order would be presented clearly at checkout, showing two fulfillment groups with separate timing.

Design

Design

As the lead app designer, I went through several iterations of designs, reading from best-in-class competitor analysis and existing data insights. After going over each iteration with stakeholders, I built clickthrough prototypes for both iOS and Android. The designs kept the fidelity at concept-level, which was enough to communicate the mechanic and simulate a real cart task without requiring a full UI build.

Writing a script, I ran unmoderated remote testing sessions. Participants were given tasks simulating a real order where different items had different fulfillment availability. This qualitative data was fed back into the wireframes, updating the designs as needed based on user feedback.

Outcomes

Outcomes

What we found from the testing sessions, is that the results were mixed. The concept resonated with some users but caused confusion for others - which was itself a useful finding.

What worked:

  • Users familiar with BOPIS understood the concept quickly.

  • Getting some items faster was seen as genuinely valuable.

  • Visual separation of ship vs. pickup items felt intuitive when shown clearly.

What didn't work:

  • First-time exposure to split-order UI caused hesitation and re-reading.

  • Some users didn't realize they could change fulfillment per item.

  • The checkout screen with two shipment groups felt complex to some.


The ILF project ended up being cut.

Why this feature was cut:

  • Supporting item-level fulfillment required significant backend changes to order management systems. The engineering lift was substantially larger than scoping had anticipated.

  • By the time testing concluded, organizational priorities had moved. The feature was deprioritized in roadmap planning and removed from the backlog.

What I ended up learning:

  • Not all good design gets built, and that's worth discussion. The research contributed real organizational knowledge even without shipping.

  • Mixed test results are still worthwhile. The split in comprehension pointed to a viable concept that needed a better communication, not a fundamentally broken idea.

  • UX and engineering need to align earlier. Involving engineering in discovery would have pressure-tested feasibility, giving us a clearer picture of the lift needed to build and make this feature live.

What we found from the testing sessions, is that the results were mixed. The concept resonated with some users but caused confusion for others - which was itself a useful finding.

What worked:

  • Users familiar with BOPIS understood the concept quickly.

  • Getting some items faster was seen as genuinely valuable.

  • Visual separation of ship vs. pickup items felt intuitive when shown clearly.

What didn't work:

  • First-time exposure to split-order UI caused hesitation and re-reading.

  • Some users didn't realize they could change fulfillment per item.

  • The checkout screen with two shipment groups felt complex to some.


The ILF project ended up being cut.

Why this feature was cut:

  • Supporting item-level fulfillment required significant backend changes to order management systems. The engineering lift was substantially larger than scoping had anticipated.

  • By the time testing concluded, organizational priorities had moved. The feature was deprioritized in roadmap planning and removed from the backlog.

What I ended up learning:

  • Not all good design gets built, and that's worth discussion. The research contributed real organizational knowledge even without shipping.

  • Mixed test results are still worthwhile. The split in comprehension pointed to a viable concept that needed a better communication, not a fundamentally broken idea.

  • UX and engineering need to align earlier. Involving engineering in discovery would have pressure-tested feasibility, giving us a clearer picture of the lift needed to build and make this feature live.