Shopping Cart Experience
MY ROLE:
UX Designer
TIMELINE:
Jan-March 2023
TEAM SETUP:
UX Designer, Service Designer (AOT Technologies)
Product Owner, Data Analyst, Engineers (Ministry of Citizens)
METHODS USED:
Heuristic Evaluation, Affinity Mapping, Jobs-to-be-done, HMW, Service Blueprint, Journey Map, Opportunity Workshops
Project Overview
Together with the AOT Technologies team, I achieved a successful bid and secured a project collaboration opportunity with the Ministry of Citizens' Supply Services division. Our primary objective was to assess the existing shopping cart experience and develop a strategic plan for its future enhancements.
Ministry of Citizens' Supply Services provides a comprehensive supply chain, inventory management, and product distribution to support government-funded organizations and citizens. In the fiscal year of 2019/2020, Supply Services processed 136,000 purchases through their nine online shopping carts, totalling $59M in transactions.
The Ministry had intentions to acquire an e-commerce platform, driven by limited internal resources, but required guidance on the feasibility of migrating their product lines and whether this solution would be advantageous overall.
CHALLENGES:
Multiple business lines that operated independently despite belonging to the same entity
Wide range of products (from medical supplies for BC Ambulance to online courses and print-on-demand books)
Outdated shopping cart infrastructure (difficulty in maintaining legacy code)
GOALS:
Understand the current state of four shopping carts, and one custom web-based application
Formulate a strategy to determine which product lines can be transitioned to an e-commerce platform and identify those that require alternative solutions.
Create a list of high-level requirements for the future e-commerce platform
Initial Evaluation and Project Timeline
Within our bid proposal, I incorporated a comprehensive top-level heuristic evaluation of publicly accessible shopping carts. Additionally, I outlined a project roadmap aligned with the Ministry's initial proposal.
Spoiler alert: The roadmap underwent significant changes once we became more familiar with the business's intricacies. For instance, we realized that conducting usability testing wasn't necessary since we had spoken with engineers and the product owner, and after conducting our own evaluation, it was clear that the existing solutions would be entirely replaced due to several technical and business factors.
Initial understanding of product lines & limitations
I started by talking to the Product Owner and technical team to understand business specifics and their assumptions. We also created a stakeholder map to categorize all groups, understand their influence and interest.
Key Insights
The ERP system (SAP) was the sole repository for all product and customer data. As a result, multiple supplementary solutions were developed to enable users to manage product lines in an easier way.
The tangled nature of the codebase limited the ability to make changes to websites, which led to the creation of additional web tools for tasks like invoice retrieval, product management, and purchase request approval.
Certain processes were specific to the Ministry and required special attention. For instance, orders from any Ministry or broader public sector organization required approval from the Expense Authority before processing.
Discovery Workshop
To ensure a comprehensive understanding of each product line's specifics, I conducted interviews with representatives from each line of business. The goal was to map out their commonalities and differences, as well as uncover some unique specifics.
Then I organized a full-day discovery workshop to collaborate and share information. The Product Owner expressed concern regarding siloed working practices among teams that had persisted for several years. Bringing everyone together was thus essential to address this concern.
I mapped out their customers, how they currently managed their product categories, what type of payments they were dealing with, and the shipping process. This helped us understand the high-level structure of Supply Services and prioritize our work based on uncovered complexities.
Defining the focus areas. Where to dive deep?
According to the statistics from the shopping cart, the product lines providing medical supplies (PDC and OREO) had the highest number of distinct customers and average weekly orders. The initial findings also suggested that these product lines had the most intricate business structure, so I dived into their specifics first.
Product Distribution Centre (PDC) exclusively serves the government and other entities in the public sector by offering a wide range of items, such as medical devices, pharmaceutical drugs, incontinence products, janitorial supplies, and more. PDC is the go-to supplier for Ambulance, Corrections, Fire departments, midwives, and other healthcare professionals in British Columbia. They rely on PDC to procure and order any necessary medical supplies.
Field studies and observations
I spent a couple of days at the PDC warehouse in Coquitlam, understanding the specifics of the order fulfillment process. Among some of the insights were:
The high volume of order returns. This was a critical insight that should be uncovered, as some medical products can’t be returned and must be disposed of due to healthcare regulations.
75% of orders were shipped by Purolator, which was integrated into the SAP system. However, customers did not receive any information with order tracking.
Having no option to cancel the order on the front end resulted in warehouse employees getting calls from Customer service and manually pulling the orders from the assembly line.
Mapping out our user groups
After understanding intricacies of the fulfillment process, I collaborated with the Product Owner to identify and analyze all types of clients involved. This exercise enabled us to recognize both commonalities and distinctions among them.
Notably, we discovered a distinct group of users that utilized unique approaches for ordering goods, setting them apart from other clients of the PDC. As a result, we determined that these users (marked in blue on the map) required separate analysis.
End-to-end order management blueprint
After user interviews (~ 20 interviews), I analyzed the data to uncover common themes, their interconnections, and identify any underlying pain points. I created a service blueprint that underlined different stages of the fulfillment journey, main touchpoints users were interacting with, as well as their pain points.
The blueprint helped to illustrate three clear themes:
Before the actual ordering experience, there was a Preparation stage that was done manually through emails and phone calls: setting up accounts and approvers, managing product lines and new product requests. Basically, PDC acted as a ‘middle man’ for clients who were requesting products and customers who were ordering them.
For some clients (BC Ambulance, Fire departments) it was essential to manage the stock and allocate products, especially if the product was in high demand. Currently, it was managed manually through blocking orders, without any visibility on the shopping cart - “So in here we got this massive spreadsheet. So we send logistics department this spreadsheet and we would ask them to change into how much they want for each stations. Then we go into and can change it. It's a lot of manual work”
There was a clear distinction between those who were requesting products (BC Ambulance Logistic Department) and those who were ordering them (individual Ambulance Stations).
They had different jobs to fulfill as for the Logistic Department it would be necessary to make sure that each station will get some products even if it is in high demand, though as stations wanted to order as many as they need. However, nothing on the front-end prevented ambulances from ordering as many as they want, so such orders were blocked on SAP level without any further notification to end users.
Though there was an approving process in place for the ambulance stations, we uncovered that approvers were mainly a part of the ambulance team ‘on the road’ and were mainly approving everything - “The only checks and balance that we have is the approver. Because that approver is the expense authority. But here's the thing, EA are paramedics on the road. They are really busy, they just go and click”
The distinction between users who were requesting and ordering products
End-to-end PDC Supply Services Blueprint
Analyzing a specific group of users and their unique journey
Earlier we identified that not all users had same journeys with ordering medical supplies. A big portion of PDC clients were citizens with complex medical conditions that were eligible to receive medication free of charge.
There were 3 types of users involved in this specific process:
Health authorities who prescribe what medical supplies the client needs to get.
Programs (Ministry of Family and Children, WorkSafe BC, Ministry of Social Development, etc.) determine what the client is eligible to get for free (how often, how much, when)
Clients separately order items for which they were set up for from PDC
challenges
Order tracking and completion are done manually, having about 10 CST staff to operate calls (~120) and emails (~100)
Time to onboard new staff - 3-4 weeks
service blueprint
There was a limited possibility to talk to those who were ordering medical supplies due to privacy protection. However, I spent a couple of days with Customer Service representatives observing their work. I also had interviews with CST team from Ministry program who were setting up files in the system - OREO - that both PDC and Ministry program had access to.
As a result, I created another service blueprint to underline major challenges both teams were having.
Main findings
Medical professionals didn’t have access to PDC Product Catalogue, thus were prescribing medication that PDC might not have or had supplements. It increased time for Program’s Approval Team to go back and forth with doctors to finalize the list based on the PDC list.
For some programs like Ministry of Family and Children, there was high possibility for end users to order online as the list of medications were set up and approved, and parents were ordering for their children - “One of the problems - people call in standard business hours to speak to a human to order things that they've already been eligible for”
Though PDC and Ministry of Family and Children worked with same clients, they were working in 3 separate systems that had no integrations. All data migration was done manually - “We need to go to SAP to double-check. We go to track the order. We go to change anything on the file... Right now, there's a lot of double work for the team”
Not all programs can be moved online as some of them had clients with severe medical conditions and required assistance while ordering - “individuals who will not use a computer, don't have access to the internet phone call or mentally challenged to type email”.
Identifying opportunities for the PDC
Once pain points and limitations were identified, the next step involved collaborating with the PDC team to define potential opportunities.
To ensure everyone was aligned, I prepared and shared an extensive research report. Additionally, I compiled key pain points and formulated "How Might We" (HMW) statements for each stage of the process (pre-shopping, shopping, and post-shopping experience) to guide our problem-solving efforts effectively.
Opportunity Workshop
Expense authority approval was a mandatory but a cumbersome process that involved logins into two separate system, manually maintaining the EA database, and no integration with SAP. The result of this discussion was an initiative to create a direct integration of EAs into SAP (still in implementation as requires other ministries’ involvement). This integration also reduce the need to manually fill-in the needed account coding fields (ministry coding, reference number, etc).
Unified data representation in SAP - product information on SAP level was not organized properly, and ERP was defined to be the sole repository for all the data. For example, there were no unified method of classifying product based on units of measurements - “It just that it seems like on the warehouse level or on material master level, they could not come to conclusion whether we call it case or box or whatever. It just happens to be bag, it's a bag of something. I dunno what it is. It's just bag.” This resulted in customers ordering wrong quantity of items and then returning products, which further are discontinued.
