Make the product model explicit
Collect a representative sample of products before planning the catalogue. Note variants, SKUs, barcodes, images and any restrictions that affect what can be purchased together. Product count alone does not show the complexity of these rules.
Identify who maintains descriptions and prices, how imports will work and whether an existing product system remains authoritative. A small trial import can reveal data cleanup work before the full catalogue is migrated.
Define order and payment states
Agree the states an order can move through: basket, awaiting payment, confirmed, cancelled and fulfilled are examples to discuss rather than a universal model. Decide which transitions staff can perform and which need a confirmed provider response.
A payment return page is part of the customer journey; payment confirmation also needs a supported server-side process. Plan what the customer sees if the browser closes, a payment is pending or a notification arrives more than once.
Work through fulfilment exceptions
Discuss delivery areas, collection, partial fulfilment, returns and products that become unavailable after a basket is created. Decide how stock is reserved and released, and where staff resolve discrepancies.
A good initial brief includes existing supplier interfaces, delivery rules and a few real order examples. This supports a more realistic development scope than a list of desired page designs alone.