Skip to the case study

All case studies

Jill Low

Product Designer, UX/UI & Front-end Coder

Case study · Product editor Senior UI/UX Designer, StoreHub Aug 2020 to Dec 2020

Turning a bulk-upload gap into a full product-editor redesign

A gap in StoreHub's bulk product upload turned into a full redesign of how merchants add and edit products, built on research across three feedback channels, eight competitors, and nine user tests.

01

A bulk upload that didn't cover everything

While Malaysia was under quarantine, StoreHub had an influx of food and beverage merchants signing up for Beep Delivery, a food delivery platform launched in late March 2020. Customer Success quickly struggled to onboard all of them, especially getting product information and menus uploaded and live.

Merchants already had a way to bulk-update products by CSV. What that upload couldn't handle was multiple-choice variants: the setting that lets a customer pick more than one add-on, bubble tea toppings for instance. Those had to be added by hand, one product at a time, with no way to duplicate the setup from one product to the next.

Line chart of the number of products added over time, from May 2015 to August 2020, climbing steadily and then spiking sharply around the point marked 'Quarantine starts' in March 2020.
Products added over time. The jump around March 2020 is the quarantine-driven rush onto Beep Delivery.
02

What the redesign was replacing

The brief I got was to make multiple-choice variants manageable in one central place and attach them to products from there. The more I looked at it, the more it made sense to redesign the whole add/edit-product flow instead. The timing lined up: the BackOffice was already being revamped section by section, and this was one of the sections still waiting its turn.

The screen as it stood: a dense single column, and the manual variant setup merchants repeated for every product.
03

Digging into the problem before drawing anything

I started by documenting the existing behaviour and my own assumptions, then went looking for what merchants had actually said about adding products, across three channels:

  1. Pendo, where merchants submit and vote on feature requests: 50 requests related to adding products.
  2. PlanHat support tickets, almost every support touchpoint by email or phone: about 37 issues, from one month's worth of tickets, since the full volume was too large to read in full.
  3. Zendesk chat logs, across our different apps' support channels: 9 issues, also sampled from one month.

We then split every issue by which field in the product form it belonged to, so we could zero in on one field at a time. Alongside that, I reviewed eight competitors: Square Up, Vend, Shopify, Lightspeed Retail and Ecommerce, Lightspeed F&B, Shopkeep, and Wongnai. That research shaped decisions later on, including changing some concepts that were core to how StoreHub had always modelled a product.

The research trail: documented requirements, merchant issues collated by field, and a side-by-side of how competitors handle the same decisions.
04

Variants for retail, modifiers for food and drink

The redesign changed three things:

  1. Retail and food and beverage merchants now created products differently. Retail merchants would create variants, generating child products with inventory tracking on. F&B merchants would create modifiers instead, which don't track inventory but let customers pick options. Previously every merchant had to work out whether their variants were single or multiple choice, then decide separately whether to track inventory, which only applied to single-choice variants anyway.
  2. Modifiers could now be managed centrally and attached to any product. This was the original ask that started the project: an easy way to add ice cream toppings, bubble tea add-ons, sweetness levels, or poke bowl ingredients once, rather than rebuilding them per product.
  3. Online product settings merged into the general product settings. With more merchants selling online anyway, keeping those settings on a separate tab just meant people forgot to check it.
The prototype we started testing with internal trainers, onboarding specialists, and merchants.
05

Testing with nine of thirteen planned merchants

This touched the core of everything StoreHub did, so we tested carefully before writing any production code. We wanted to know whether merchants understood variants versus modifiers, whether they realised these settings also applied to their online channels, and whether they could recreate their existing products, including the awkward ones, in the new interface.

I prototyped the flow and ran one-on-one sessions, picking products from each merchant's own catalogue to try rebuilding. The thirteen planned sessions covered five internal trainers, a single mom-and-pop restaurant, a five-store ice cream parlour, a retail fashion store that also sells online, a dental equipment wholesaler selling online to dentists across Malaysia, a 92-store dessert franchise, a service-based business such as a school or car workshop, an external retail store, and an external Italian restaurant.

We got through nine of the thirteen. Most merchants responded well to the variants and modifiers concept and were keen to use it. I documented what still needed fixing and the open questions, for the wider group of product managers and our CTO to weigh in on before the remaining four sessions and the production build.

One of the nine sessions: a merchant rebuilding a real product of theirs in the new flow.
06

Where I left it

I left StoreHub not long after this round of testing, before the remaining four sessions or the production build. What I do know: the research held up. Every merchant we tested, from a single restaurant to a 92-store franchise, understood variants versus modifiers without us having to explain it twice.