Increasing efficiency by optimizing item substitutions
Timeline: Sep 2022 - Aug 2023
Role: Lead Product Designer
Design Team: Myself, Jess N. (Sr. Product Designer)
Platforms: App (iOS), Web
One of the biggest challenges facing grocery e-commerce is substitutions. When customers had substitutions through PC Express, store employees would call the customer prior to pickup to review them.
I led the design for the customer experience allowing customers to approve and reject substitutions asynchronously through PC Express. This solution is expected to save over 81,000 labour hours and over $2.8M in labour costs.
My Role
I led the design for the customer experience.
My role on the team was the lead designer for the customer experience. Though I focused and advocated specifically for the customer experience, I worked closely with the designer on the fulfillment side (Jess) and the operations teams which dealt with the store employee experiences. Operations teams were crucial in the success of this project because they defined how information flows to store employees and the timing of the notification to customers.
![](img/Async/the-team.webp)
Context
Substitutions are crucial for the customer and for our business.
Today, PC Express primarily operates its grocery delivery and pickup services through its stores. That means that if you place an order online, there’s a store employee picking the order. What that also means is your groceries can’t be fully guaranteed because someone who’s shopping in-store could’ve taken the last item. Though this affects customers, this also affects store operations because that means the order isn’t 100% filled (a major KPI), which results in losses for the business. Substitutions become important because they provide a customer an opportunity to still get a similar item and provide the business an opportunity to get closer to the 100% fill-rate.
Things start to fall apart when customers get inaccurate substitutions or when those substitutions are substantially more expensive. What we do to mitigate those situations is to call the customer shortly before they receive their order to ask if they’re okay with those changes to the order.
What we learned in this project is that customers really like the phone call due to it’s personal touch, yet operations teams dislike it due to its impact to productivity at the stores.
20%
Churned due to too many substitutions
16%
churned due to more expensive substitutions
The Goal
Focusing on substitutions to address customer satisfaction and churn
One of our key business goals was to increase OSAT (Order Satisfaction) scores and address customer churn. Recent research showed us that expensive substitutions and inaccurate substitutions were some of the biggest reasons for churn from our businesses. We knew addressing this problem in some capacity can start to regain trust with our customers and impact our business positively.
Workshopping
Aligning on the problems with substitutions.
Substitutions spanned across the customer and store employee experiences, so I defined a workshop to align everyone on what the key problems are. The goal of the session was to inform everyone on the customer impacts, and have teams ideate and vote on what they believe to be the key issues.
![](img/Async/problem-alignment.webp)
Measuring impact
Increasing approved substitutions, improving satisfaction, and increased efficiency.
Once the problems were aligned on, we defined the most important measures of success before defining the solutions. I designed for this step to happen before ideation because I wanted teams to think objectively during voting.
Once we ideated on solutions and voted on them based on our KPIs, we had two solutions that we needed to decide on: "Async Sub Management" and "Search for Subs". The latter was a solution to allow for customers to search for the substitutions they want. Currently, the platform only offers a recommended items, which aren't always accurate.
![](img/Async/measuring-impact.webp)
Decision point
Do we proceed with low-hanging fruit that only impacts customers?
Or do we proceed with a solution that will impact customer and store employees?
Outcome
We proceeded with the more complex solution due to it's impact on store employees.
I presented the outcomes of the workshop to senior leadership teams, and decided to continue with the solution that impacted both customers and store employees. The solution was two-fold: to allow customers to approve and reject substitutions asynchronously, and to remove reliance on the phone-call for reviewing substitutions (a major impact to store employees).
![](img/Async/SLT-solution-pres.webp)
journey
Defining the ideal journey for customers and store employees.
I worked with Jess to define the service map and understand when this process actually happened during an order. This flow is triggered when the order is flagged as “staged” meaning everything for the order has been picked, typically an hour before the order is picked up.
When a customer reviews their order on the app or website today, they would see a read-only view of their substitutions and any items that were not available and didn’t have a substitution selected.
![](img/Async/service-bp-1.webp)
phase 1
I worked on initial flows and designs for the experience.
I started with a simple flow for how information would flow in this experience. I knew this was a time-sensitive activity as customers had a maximum of 1 hour to manage their substitutions, so I ideated to send either an SMS or Push Notification and an email to the customer. If the window timed out to make changes (i.e. the customer opens the link in their SMS after they've received their order), they should see a timeout state, otherwise it's a successful experience.
![](img/Async/service-bp-2.webp)
I explored variations of how the approval and rejection could look for substitutions. I reused a set of buttons that acted akin to toggles elsewhere in the experience to ensure consistency. I used a sheet interaction for app because the customer can’t return or make edits to their submission and since it’s time sensitive, it’s meant to be quick. In addition, I worked with Operations to also show items that were expiring within a few days, since it’s discussed during the phone call — in general, these “order updates” were now referred to as “exceptions”.
Something else we added during the design phase was the option to opt-in for a phone call from the store employees. Though this was the exact function that this project was meant to replace, we wanted to learn if customers still wanted the call outside of this feature.
web exploration
![](img/Async/web-exploration.webp)
app exploration
![](img/Async/app-exploration.webp)
adding a phone call toggle
![](img/Async/phone-call.webp)
phase 2
Iterating on designs using existing components.
Rather than re-inventing how customers view substitutions in the web and app experiences, I decided to build upon what we already had in the experience. The changes were to add actions to the existing substitutions view, but maintain it’s place in the app and website with no further changes. My development teams also liked this approach as the foundation for this UI already existed.
Updates to web
![](img/Async/web-design-updates.webp)
Updates to app
![](img/Async/app-design-updates.webp)
phase 3
The end-to-end flow for customers managing substitutions.
Once I presented the prototypes to our development teams, they brought up a few edge cases, so I noted them down and designed out the flow. I knew I'd need to build upon this later, as new things come up, but it was a start for our developers to refer to.
![](img/Async/flow-initial.webp)
Usability Testing
I tested an option without a “submit” button
Whenever an order came in with exceptions, we knew there was a fixed window. It opened when the order was staged, and we could assume it closes when the customers order timeslot starts. Though this decision was still up in the air for the operations teams, we tested it with customers through an unmoderated study.
![](img/Async/usability-test.webp)
Outcomes
Feedback was positive, but customers weren't confident that their selections were saved.
Overall, customers were able to locate the experience and make the appropriate selections to their exceptions and found it really easy! The main point of feedback was the submission, some customers felt stuck and weren’t sure if their selections were saved or not. This made a lot of sense in hindsight, so we knew we had to add that back in.
The other piece of feedback was about the phone call. Customers had questions about when it would happen and what decisions they would be able to make on it. This revelation led the team to spin on whether we should include the toggle in the MVP or not.
Decision point
Do we remove the toggle for the phone call and save operational costs immediately?
Or do we keep it in to learn about how customers use it?
Workshop to solidify scope
We decided to keep it to learn from customer usage.
Jess and I designed a brief workshop to align the teams on what the scope was for MVP and what wasn’t. We found the teams were spinning on the timing of when this notification for the ability to manage exceptions was sent to customers, as well as the phone call. We had the teams write down pro’s and con’s for the different ideas and vote to include it into MVP or not.
The outcome was a resounding ‘yes’ to continue with the inclusion of the phone call toggle because the benefits far outweighed the cons. Since we couldn’t guarantee whether a customer actually received a call or not, we also knew we had an option to simply learn from the toggle, but not send any response to store employees to avoid impacting their workflows.
![](img/Async/revisit-MVP.webp)
![](img/Async/vote-MVP.webp)
final designs
I finalized the flows and reviewed them with my development teams.
Once we knew exactly what was in scope for MVP, I defined the flows for web and app, both of which were almost identical. I started to share these with our web and app teams and fielded questions about how we would get data from the store employees and different edge cases such as errors and timeout states.
![](img/Async/async-figma-flows.webp)
final web designs
![](img/Async/updated-web.webp)
final app designs
![](img/Async/updated-app.webp)
hypothesis
We had high expectations for the success of the program.
Though the most notable results were expected to come from employees, we also anticipated an increase in OSAT scores from customer and hypothesized a notable increase in retention, considering substitutions were a large cause for churn.
81,000
hours saved for store employees
$2.8M
in labour costs saved for store employees
And then the project was put on-hold for other initiatives the company wanted to work on.
So we waited… for almost a year and a half.
Since the pause
Opening the floor for more changes to the experience.
Despite the workshop from Jess and I to finalize scope for MVP, the over a year-long pause gave time for Ops to rethink decisions and make changes to the experience. The phone call was ultimately removed. We have a new paragraph block for a payment issue that could happen for some customers. We have a separate section for preselected substitutions (if a customer has made substitution selections in cart).
Reflection
A simple solution for a contextually complex project.
I’d be lying if I said I wasn’t proud of my efforts on this project. I was able to lead the design end-to-end, in addition to defining project milestones and estimating my work accurately. I liked the challenge and the ability to design something that will inevitably make a big difference to both store employees and customers. The stuff I didn’t like was out of my control. Business priorities shifted and thus this project got deprioritized, and it’s still something I question today considering substitutions is our #1 problem to solve.
What I would’ve done differently is to have the workshop to align on MVP scope earlier, but that’s nitpicking… If this project had launched, I would’ve loved to add more details about the impacts and how the learnings from customers and employees then impacted the experience moving forward.
Last updated [07/04/24]