@CHEWY
Item-level Autoship
Disagreeing and committing to a full system redesign
Chewy’s Autoship product is highly successful, however core usabilities issues create a high rate of churn and customer contacts. The architecture of the project, order-level subscriptions, creates a cascade of problems that result in a high degree of customer churn and cancellations.
Autoship’s service model is an order-level paradigm, while customers’ mental models are item-level
The problem
Redefine what a “subscription” is for Autoship, and rebuild the service from the ground up
The project
“All my items are auto delivery, but I do not need to receive them ALL in the same time period. Is there any way I can change the frequency of each individual item? It would also be easier on my wallet.”
Subscription management as it appeared before the project. Customer can have many subscriptions, which are repeat orders with interchangeable items.
Stated project goalIncrease item consolidation……..but we’re optimized for that now? More on that later.
Redefining “subscription”
This project necessitated I re-evaluate the definition of a subscription for Autoship. Which attributes “belonged” to a subscription if the subscription was now to a specific item?
Chapter 1
Existing definition
Order level subscription
A reoccurring order of a collection of items. Customer attributes and frequency live at the order level. The items inside are interchangeable.
Simplified entity relationship diagram of order-level Autoship architecture. A parent order spins off child orders which adopt its attributes.
New definition
Item level subscription
A reoccurring order of an item. Customer attributes and frequency are set at the item level. Subscriptions with the same next order date are consolidated into a single fulfillment, or “club.”
Simplified entity relationship diagram of item-level Autoship architecture. Items have their own attributes that spin off child orders, which are collected into fulfillments, ideally with other items.
A goal in opposition to the project
The stated goal of this project was to “increase item consolidation,” however an order-level paradigm is inherently geared towards items shipping together. Shifting to an item-level paradigm would actually decrease the chances of items shipping together.
Chapter 2
Compatible frequencies isn’t enough
Autoship runs off a very simply equation:
lastOrderDate + frequency = nextOrderDate
Even if items had compatible frequencies (example, item A’s frequency = 3 weeks and item B’s frequency = 6 weeks), the items may never ship together because the day customers start their Autoships is just as important for consolidation.
Data visualization showing how compatible frequencies do not guarantee items consolidate.
An epiphany
In order to support the central requirements and business goals of the project, I needed to encourage customers to start subscriptions with existing upcoming fulfillments
Nudging customers towards item consolidation
To maximize our chances of items shipping together, I motivated customers to start a new Autoship by adding to an existing fulfillment.
Chapter 3
Chances made to acquisition component to encourage item consolidation.
Delivery
As this was a complete system re-design, I knew that validating our new designs, and managing the sheer number of assets needed for development would be a huge task. With our limited design resources, I devised strategies to achieve these goals at scale.
Chapter 4
Rebuilding the dynamics of the system in Figma
Before launch, we did a hi-fi usability study which required me to make a complex prototype to replicate the unique ripple affect one Autoship action has on the system. For example, changing the next order date for one item would impact all the future fulfillments that item was in. Figma had just come out with variables in prototypes, allowing me rebuild the entire system for usability testing.
Screenshot of the complex prototype I made for usability testing during dev implementation.
Reusable component library
I quickly realized we would be maxing out Figma’s file size limit multiple times over. Though Chewy has a well established design system, I decided that creating a “pattern library” for myself and the other designer would keep us organized across so many files.
It also had the added benefit of being easy for away team designers to pick up post launch.
Screenshot of the component library I created to ensure efficiency across many files.
Final designs
Keyframes for Autoship acquisition
Keyframes for Autoship management
What I delivered
540+ Hi-Fi screens in a rolling release schedule and a completely component driven system for other designers
An unsatisfying conclusion
Right as we rolled out the new system to a small portion of internal users, we got word from senior leadership that they thought the endeavor too risky, which I actually agreed with.
In the end, we didn’t launch, the project quietly died and all the internal users were eventually rolled back to the order-level system.
Chapter 5
Why show a failure?
I am proud of this work despite how the project went down. It’s rare that you get to completely redesign a complex system from the ground up. In the end, ideas from the project still influence the work I’m doing now.
Through this project, I believe that my design partner and I earned the respect of product and engineering that still lasts to this day. Since this failure, our seat at the table has grown, and I’ve found my product partners seeking my input, earlier and more often in the idea-to-product lifecycle.