Redesigning Product Discovery & Order Transparency at OneCart
Redesigning how customers find products and track orders across a multi-store grocery marketplace.
29%
Average Returning User Growth (YoY 2023 – 2025)
context
The Grocery Delivery Ecosystem
OneCart is a multi-store grocery marketplace in South Africa, aggregating products from 6–7 retailers (Woolworths, Pick n Pay, Makro, Dis-Chem, Clicks) with same-day delivery through personal shoppers and drivers. Most customers come to compare prices across stores.
Operationally, things were solid — shoppers, drivers, retailer partnerships all functioned. But the customer-facing experience hadn't kept up. The homepage was static. Search broke on misspellings. Every retailer organised products differently. After checkout, customers had no idea what was happening with their order until it showed up — or didn't.
We were brought in for a visual redesign. Customer interviews and Baymard benchmarking showed the problems were structural, not cosmetic. My PM and I reframed the scope around three specific gaps: fragmented discovery, broken search, and post-purchase silence. Business backed it once we walked them through the evidence.
Problem
Discovery was fragmented
Each retailer had its own category structure. Customers relearned how products were organised every time they switched stores. The homepage had no dynamic content, no promotions. Comparison — the main reason people used OneCart — was harder than it should have been.
Search was brittle
Exact spelling required, no autocomplete, unstructured results. Customers used search to work around bad taxonomy, but search itself was unreliable.
Post-checkout was invisible
Backend systems tracked everything — shopper assigned, items found, driver dispatched — but none of it reached customers. The most common support query was “Where is my order?” App store reviews said the same thing.
Constraints
Key Constraints
We had to work within the existing backend — no greenfield rebuilds. Product data quality varied across retailers, making automated category mapping unreliable. Delivery partners didn't support real-time GPS, so live tracking was off the table. There was no user testing infrastructure, and everything had to ship on both web and mobile.
Research & Design Strategy
External research — Baymard Institute
We reviewed Baymard's published e-commerce UX research to benchmark OneCart's experience against industry standards. Three findings were directly relevant:
- Product sub-types are often misused as categories instead of filters — this validated what we saw in retailer category structures and shaped how we designed the unified taxonomy.
- Search must tolerate spelling variation and intent mismatch — this made autocomplete and fuzzy matching non-negotiable in our search redesign.
- Category-aware filtering after search is critical for findability — this informed our decision to group search results by OneCart categories and add filter components.
Internal research — Customer interviews
We interviewed 12 customers across three segments: new users, frequent users, and low-frequency users.
Most users cared deeply about promotions and price comparison across stores: The homepage needed to surface deals dynamically, and discovery had to work across retailers, not within them. This directly drove the Sanity CMS integration and unified taxonomy.
Search was used primarily to compare prices, not to browse: Search results needed to group by product across stores, not by store. The results page and filters needed to support comparison as the primary behaviour.
Lack of order visibility created anxiety and reduced repeat usage: Post-purchase communication was directly linked to retention. This made the order status translation layer a priority.
Users preferred proactive communication over having to “check manually”: The notification strategy needed to be event-driven and channel-aware. Customers shouldn't have to open the app to know what was happening.
Strategy
- Discovery, checkout, and post-purchase are one experience. Treat them as a system.
- Work within existing backend systems. Only push for investment where customer impact clearly justifies it.
- Web and mobile reach parity.
- Every status and notification answers a customer question, not a backend event.
What We Excluded & Why
- Full backend restructuring: Business vetoed against a new backend restructuring
- Live map tracking: Delivery partner APIs didn't support real-time GPS
- Advanced notification preferences: Needed the foundation before adding complexity
Solution
Rebuilding Product Discovery & Search
Discovery and search were two sides of the same problem: customers couldn't reliably find and compare products across retailers.
Taxonomy: We introduced a OneCart-level category system that mapped all retailer inventories into one structure. Categories followed how customers think (“Beverages & Juices”, “Bread, Bakery & Desserts”), not how stores organise shelves. NLP handled most of the mapping; our PM and an engineer filled gaps manually so we could ship without waiting for automation to mature.
Homepage: Sanity CMS replaced the static homepage with dynamic content feeds — promotions, “Top Deals”, seasonal collections. Marketing could update what customers saw without filing engineering tickets.
Search: We redesigned the entire search experience: autocomplete with spelling tolerance, cross-store results in a single view (searching “milk” showed every retailer's options in one list), new filter and sort components, and all search states designed properly (empty, loading, results, no results).
Decisions that mattered
Unified taxonomy was non-negotiable. Layering filters on top of seven different retailer category structures would have preserved exactly the inconsistency customers were complaining about. One browsing model, period.
We shipped with manual category mapping alongside NLP. Waiting for automation to get accurate enough would have blocked the entire redesign with no clear timeline. Manual mapping filled the gaps while NLP improved in the background.
Sanity CMS for the homepage was a pragmatic call — marketing needed independence from engineering, and building a custom content system for that would have been overkill.
Search results show all stores in one view rather than separated by retailer. The whole point of searching on OneCart is to compare — siloing results by store would have defeated that.
Designing the Order Status & Notification System
This was the most complex piece of the project.
A single customer order could contain multiple sub-orders across different retailers, each with its own personal shopper. Shoppers and drivers operated independently.
The backend tracked dozens of operational events, but customers saw almost none of it. We couldn't restructure the backend — business vetoed that on time and cost.
The translation layer: Through workshops with business and engineering, we mapped every backend event to what it meant for the customer. I designed a finite set of customer-facing states, each answering: what's happening now, and what comes next?
Seven primary states: Order placed → Shopper assigned → Shopping in progress (with item-level indicators: found, partially found, not found, substituted) → Shopping completed → Handover to driver → Driver on the way (ETA + driver details + call button) → Delivered (with rating prompt).
Four exception states: Order running late (with updated ETA), delivery rescheduled (with cancel option), unable to find order (all items out of stock), driver couldn't find you (contact info surfaced).
Notifications: Rather than notifying on every backend event, we mapped urgency to channels. Push notifications for time-sensitive moments (shopper assigned, driver on the way). SMS with tracking URL as the default for web users. Email for confirmation and post-delivery feedback. In-app as the persistent, full-detail view. The idea was that if you got a notification, it meant something actually changed — not just a system event firing.
Decisions that mattered
Engineering had proposed restructuring the event system. Business said no — too expensive, too slow. The translation layer was the alternative: an abstraction that shipped within existing sprint cycles and gave customers what they needed without touching backend architecture.
A subtle but important rule: “Shopping completed” only fires when the last active sub-order finishes. If a sub-order gets cancelled or rescheduled, it doesn't count. Without that, customers would see “completed” while items were still being picked up in another store.
For the driver stage, we had a choice between a live map and an information-based approach (ETA, driver name, call button). The GPS data from delivery partners wasn't reliable enough for a map — so we went with information and direct contact. A laggy, inaccurate map would have made things worse.
Exception states are shown explicitly with explanations, not hidden behind happy-path screens. When a delivery gets rescheduled, you see why. When items can't be found, you see that too. We'd seen what happens when platforms hide delays — customers call support, leave bad reviews, and stop coming back.
Impact
Outcomes
27% Avg New user growth (YoY, 2023–2025)
Sustained year-over-year growth in new user acquisition across the redesign and post-launch period.
29% Avg Returning User Growth (YoY, 2023–2025)
Consistent year-over-year growth in returning users, supported by improved order visibility and notifications.
18% Avg. revenue growth (YoY, 2023–2025)
Steady year-over-year revenue growth during and after the platform redesign.
The redesign was the primary product change during this period, though other factors contributed to growth. Support reported fewer “where is my order” queries after the status and notification systems went live. App store sentiment around order tracking improved. Marketing started running promotional campaigns through Sanity without waiting on engineering. Cross-store comparison got noticeably easier.
reflection
Conclusion
What worked
The research reframed the project. Without customer interviews and Baymard benchmarking, this would have stayed a visual redesign. The evidence let us expand the scope without friction — every design went to business with the reasoning behind it. By the time we were presenting the order status model, the team had enough trust in the process that scope conversations were quick — we weren't relitigating decisions from three sprints ago.
The translation layer was the right call. A backend restructure would have taken months and might not have happened. The abstraction gave customers clarity on top of what already existed.
What I'd do differently
Do research before starting design, not alongside it. We discovered structural problems mid-execution, which meant some early work had to be revisited. Research first, scope second, design third.
Test designs with customers before development. We shipped based on research and internal validation. Even lightweight usability testing would have caught things earlier.