E-commerce, Retail & FMCG
Ecommerce Storefront With Catalogue Search
Catalogues almost always arrive in a worse state than anyone admits. The usual case is a storefront that has grown a hundred products one at a time, where categories were created to solve last year’s problem and never retired. Search on top of that returns nothing useful, and the fix is not a better search box.
The work started by agreeing a category structure with the client’s merchandising team rather than imposing one. That took two workshops and produced a flatter taxonomy than either side would have drawn alone. Faceted search was then built on that structure, with the facets derived from attributes the catalogue already had, so filtering stays accurate as stock changes. Payments, shipping rates and tax were connected to the existing systems rather than re-keyed.
The decision that shaped the rest was where product data lives. Keeping a separate store catalogue would have been quicker to launch and would have left the client maintaining the same product in two places forever. Syncing from the existing system costs more to build and is the reason nobody now asks where the price is updated.
Every step from search to order confirmation was tested on real devices with real catalogue data before launch, including the payment paths that fail when a shipping address is outside the country the store ships to.
Handover included a written map of where each piece of data originates, and a note on the three syncs that need checking if orders ever stop appearing.
Catalogues almost always arrive in a worse state than anyone admits. The usual case is a storefront that has grown a hundred products one at a time, where categories were created to solve last year's problem and never retired. Search on top of that returns nothing useful, and the fix is not a better search box.
The work started by agreeing a category structure with the client's merchandising team rather than imposing one. That took two workshops and produced a flatter taxonomy than either side would have drawn alone. Faceted search was then built on that structure, with the facets derived from attributes the catalogue already had, so filtering stays accurate as stock changes. Payments, shipping rates and tax were connected to the existing systems rather than re-keyed.
The decision that shaped the rest was where product data lives. Keeping a separate store catalogue would have been quicker to launch and would have left the client maintaining the same product in two places forever. Syncing from the existing system costs more to build and is the reason nobody now asks where the price is updated.
Every step from search to order confirmation was tested on real devices with real catalogue data before launch, including the payment paths that fail when a shipping address is outside the country the store ships to.
Handover included a written map of where each piece of data originates, and a note on the three syncs that need checking if orders ever stop appearing.
- Industry
- E-commerce, Retail & FMCG
- Category
- Storefront
- Project type
- Ecommerce
- Project date
- 2025-03
Technologies
Project highlights
- Category structure agreed with the client's merchandising team
- Faceted search driven by existing product attributes
- Payments, shipping and tax connected to the client's systems
- One-way catalogue sync from the source system
- Account areas for order history and returns
- Checkout paths tested with real catalogue data on real devices
