Decathlon: App Redesign

Sixty sports, one buyer

Decathlon sells across 60-plus sports and thousands of product lines through its own house of in-house brands (Quechua, Domyos, B'Twin, Kalenji) across roughly 1,900 stores in more than 80 countries. That range is a gift on a shelf and a genuine liability on a phone screen, because the person opening the app almost never wants the whole catalogue. They want one pair of running shoes. This unofficial redesign concept treats that mismatch as the entire brief.

Building narrowing into every screen

With a catalogue this wide, no home page alone can carry the weight of getting someone to the right product. So search pairs prominent filter chips with a full filter sheet (price, category, size, brand), and every filter option shows its match count, so a search never quietly dead-ends at zero results. Baymard's own research puts the share of retail sites that get this pattern right at only around 16%. Doing it properly here isn't a nice-to-have, it's most of the actual redesign.

    // Category = shoe type when every result is a typed shoe, otherwise sport    const catFn = (all) => (all.length && all.every((p) => p.type) ? (p) => p.type : (p) => p.sport);    const catLabel = (v) => RUN_TYPE[v] || ((D.sport(v) || { name: v }).name).replace(' & strength', '');    function passes(p, f, cat, skip) {      if (skip !== 'price' && (p.price < (f.min || 0) || (f.max != null && p.price > f.max))) return false;      if (skip !== 'cats' && f.cats.length && !f.cats.includes(cat(p))) return false;      if (skip !== 'brands' && f.brands.length && !f.brands.includes(brandOf(p))) return false;      if (skip !== 'sizes' && f.sizes.length && !f.sizes.some((z) => p.sizes.includes(z))) return false;      return true;    }    function run(q, sale, f) {      f = norm(f); const all = base(q, sale); const cat = catFn(all);      const results = all.filter((p) => passes(p, f, cat));      const count = (key, keyOf, v) => all.filter((p) => (key === 'sizes' ? p.sizes.includes(v) : keyOf(p) === v) && passes(p, f, cat, key)).length;      const uniq = (arr) => [...new Set(arr)];      const byBase = (keyOf) => (a, b) => all.filter((p) => keyOf(p) === b).length - all.filter((p) => keyOf(p) === a).length;      const cats = uniq(all.map(cat).concat(f.cats)).sort(byBase(cat)).map((v) => ({ v, label: catLabel(v), n: count('cats', cat, v) }));      const brands = uniq(all.map(brandOf).concat(f.brands)).sort(byBase(brandOf)).map((v) => ({ v, label: v, n: count('brands', brandOf, v) }));      // … the size rows and the price ceiling, counted exactly the same way.      return { all, results, f, cats, brands, sizes, maxPrice, catLabel, isEmpty: isEmpty(f), countWith: (g) => all.filter((p) => passes(p, norm(g), cat)).length };    }

Fixing the moment carts get abandoned

Baymard's cart-abandonment research names unexpected costs at checkout as the single most-cited reason people bail. So the bag shows the full price breakdown (subtotal, discount, GST, delivery) before checkout even begins, and checkout itself runs in three short steps, one clear action per screen, instead of the five-plus steps typical across the category.

What the numbers actually say

The case study's own argument was 'three steps, one action each,' and the first-pass checkout screen quietly broke that promise, merging address selection, payment choice and the final Pay Now button into a single view while the stepper above it claimed to be on Confirm. The shipped version is the confirm step the stepper actually promised: a read-only address, the chosen payment method, a compact summary, one button.

V1: caught in revision

Final