Planning guide / Commerce
E-commerce website requirements.
A structured way to define what an online store must sell, explain, calculate, exchange and support before a platform or build approach is selected.
Direct answer
What requirements does an e-commerce website need?
An e-commerce website needs documented requirements for the business model, customer types, catalogue and product data, navigation and search, pricing, tax, cart and checkout, payments, delivery or collection, customer accounts, order administration, notifications, returns, content, integrations, analytics, accessibility, security, performance and ongoing ownership. Define the operational path behind an order—not only the screens a shopper sees—before choosing a platform.
01 / Define the sale
Start with the commercial and operational model.
A feature list is premature until the team agrees what is being sold, to whom, under which rules and how the promise will be fulfilled.
Describe the sale in plain language. A business selling stocked physical products to individual customers has different requirements from one selling configurable products, subscriptions, digital access, wholesale orders or services. Mixed models may require separate journeys, pricing visibility and account permissions.
Questions to resolve
- What kinds of products or services will be sold, and can one order contain several types?
- Who can buy: guests, registered consumers, approved business accounts, staff, distributors or a combination?
- Which regions, currencies, languages and fulfilment locations are in scope at launch?
- How are prices determined, displayed and approved—including discounts, customer-specific terms or quotations?
- At what point is stock, capacity or availability reserved, and which system decides the answer?
- What must happen after payment: pick, pack, provision, book, notify, invoice, deliver or renew?
- Who owns catalogue accuracy, customer support, fulfilment exceptions, refunds and website content after launch?
The store should be reviewed against the laws, taxes, privacy duties, consumer rights and payment requirements that apply to the actual business and markets. This guide is planning guidance, not legal, tax or compliance advice.
02 / Catalogue model
Treat product information as structured data.
Product pages are the visible outcome of a catalogue model. The model must support how customers compare, how staff maintain information and how other systems identify each item.
Begin with representative product examples, including the awkward ones. Identify shared attributes, variations, bundles, add-ons, compatibility rules and availability states. Decide which fields are required, which are optional and where each value originates.
| Requirement area | Questions to document | Why it matters |
|---|---|---|
| Identity | Product ID, SKU, slug, barcode, supplier reference and variant identifiers | Prevents ambiguity across store, inventory, fulfilment and reporting systems. |
| Hierarchy | Categories, collections, brands, product families and relationships | Shapes navigation, landing pages, feeds and catalogue administration. |
| Attributes | Size, colour, material, compatibility, specifications and filterable values | Supports comparison, filtering and consistent product detail. |
| Commercial data | Base price, price lists, discounts, tax class and minimum quantities | Determines what the customer sees and what checkout calculates. |
| Availability | Stock status, lead time, preorder, backorder and location availability | Sets expectations and governs whether an item can be purchased. |
| Content | Names, summaries, full descriptions, media, documents and care information | Helps people understand the product and reduces inconsistent presentation. |
| Lifecycle | Draft, active, unavailable, discontinued, replaced and archived states | Controls visibility without deleting useful history or URLs carelessly. |
Content readiness checklist
- Create a field inventory and a completed example for each important product type.
- Agree writing, image, video and document standards before bulk entry or migration.
- Define meaningful image alternatives and avoid placing essential product information only inside images.
- Identify duplicate, incomplete and obsolete records before importing catalogue data.
- Plan stable product URLs and what happens when an item is replaced or permanently removed.
- Assign a content owner and a repeatable review process for future catalogue changes.
03 / Customer journey
Specify decisions, states and recovery paths.
“Add a checkout” is not a complete requirement. Each step contains rules, feedback, edge cases and opportunities for a customer to recover.
Find and understand
- Category navigation and landing pages
- Search behaviour and empty results
- Useful filters, sorting and comparison
- Product availability and delivery signals
- Related, compatible or substitute items
Select with confidence
- Variant and configuration rules
- Price, tax and promotion presentation
- Media, specifications and policies
- Quantity and stock validation
- Saved items or quotation routes where relevant
Complete the order
- Guest or account requirements
- Address and contact validation
- Delivery or collection choices
- Payment outcomes and retry behaviour
- Final review and explicit consent
Know what happens next
- Confirmation page and message
- Order status and account history
- Delivery, collection or access instructions
- Change, cancellation and return routes
- Human support and exception handling
States teams often miss
Review the journey with unavailable variants, changing prices, expired promotions, invalid addresses, unavailable delivery methods, payment rejection, a payment that succeeds but reports late, partial fulfilment, cancellation and refund. The interface must explain what happened; the operational team must know what to do next.
04 / Behind the screen
Map systems, ownership and exceptions.
The storefront is one part of a wider service. Reliable commerce depends on deliberate data movement and clear human responsibility.
For every important data object—product, price, inventory, customer, order, payment, shipment and refund—name the source of truth. Document which system creates it, which systems may update it, how quickly changes should appear and how staff reconcile failures.
| Flow | Define | Failure question |
|---|---|---|
| Product to storefront | Fields, validation, publish rules and update direction | Can staff see and correct rejected or incomplete records? |
| Inventory to storefront | Source, reservation point, update frequency and location rules | How is overselling prevented or resolved? |
| Order to operations | Trigger, line data, customer data, taxes, discounts and status mapping | Can an order be recovered without unsafe duplicate creation? |
| Payment result | Authorized, captured, pending, declined, cancelled and refunded states | How are delayed or conflicting responses reconciled? |
| Fulfilment status | Shipment, collection, tracking, partial fulfilment and delivery evidence | Who acts when fulfilment cannot proceed? |
| Customer communication | Message trigger, template owner, sender, language and support route | How does a customer receive help if a message is late or wrong? |
An external service may not provide a suitable API, test environment, permissions, documentation or commercial access. Verify those conditions with the service owner before treating an integration as committed scope.
05 / Quality requirements
Make non-functional requirements testable.
Security, accessibility, privacy, performance and discoverability affect trust and maintainability. “Fast and secure” is too vague to guide a build.
Quality checklist
- Accessibility: define the applicable standard and test keyboard use, focus, labels, validation, contrast, zoom and assistive-technology journeys.
- Security: minimize collected data, define user roles, protect administration, manage secrets, log important events and plan updates and incident response.
- Payments: prefer appropriately scoped payment-provider flows and document which party handles card or account data.
- Privacy: inventory personal data, purposes, consent where needed, retention, deletion, third parties and customer-request handling.
- Performance: define important page and transaction journeys, representative devices and networks, image rules, caching and measurement.
- Reliability: document backups, restore testing, external-service failure behaviour, monitoring and escalation ownership.
- SEO: plan crawlable categories and products, canonical behaviour, structured data accuracy, internal linking, metadata and removal or redirect rules.
- Analytics: define decisions the team wants to make, then implement consent-aware events and validate that reports reflect real states.
Structured data can help search systems interpret eligible product and business information, but markup must match visible, accurate content. It does not guarantee a particular search appearance or position.
06 / Platform decision
Choose after requirements expose the trade-offs.
A platform should be evaluated against the required operating model, ownership and change—not selected because it is fashionable or familiar.
| Criterion | What to examine | Evidence to request |
|---|---|---|
| Functional fit | Catalogue, accounts, pricing, checkout, order and content requirements | A demonstration using representative products and workflows. |
| Administration | Roles, approvals, bulk changes, auditability and common staff tasks | Hands-on review by the people who will operate the store. |
| Integration | APIs, webhooks, data limits, authentication, retry and testing options | Current technical documentation and access conditions. |
| Ownership | Data export, hosting, source access, account control and exit path | Contract terms and a documented migration or handover route. |
| Change | Extension model, release process, compatibility and testing needs | An example of how a likely future requirement would be delivered. |
| Total responsibility | Licences, providers, updates, operations, content and support boundaries | A responsibility map, not only a software feature comparison. |
Shortlist options only after separating must-have requirements from desirable improvements. Use a small set of representative scenarios to test the shortlist. A technically possible customization may still be a poor choice if it makes updates or operations difficult.
07 / Launch readiness
Rehearse the business event, not just the deployment.
A store is ready when customers can complete important journeys and the team can operate, support and recover them.
Before release
- Review representative products, categories, prices, promotions, taxes and availability with business owners.
- Test checkout, every enabled payment outcome, delivery or collection rules, notifications and account journeys.
- Verify orders enter the correct operational workflow and staff can handle cancellation, refund and fulfilment exceptions.
- Check responsive layout, keyboard use, form errors, content alternatives and important assistive-technology paths.
- Validate analytics, consent behaviour, search controls, metadata, structured data and redirects from replaced URLs.
- Confirm domain, certificates, production accounts, backups, restore route, monitoring and escalation contacts.
- Train administrators and support staff using real tasks; record what each party owns after launch.
- Prepare a release, rollback and communication plan with a clear decision-maker.
After release
Monitor real transactions and integration queues, review customer questions, check search crawling and indexing through appropriate tools, and prioritize fixes based on impact. Avoid changing many unrelated things at once; controlled changes are easier to verify.
Hich Web Development
Planning guidance from the organization.
Published and updated .
08 / Focused answers
Common planning questions.
The final answer depends on the store model and operating context.
Should the platform be selected before writing requirements?
Usually, document the important requirements and constraints first. A current platform may be a fixed constraint, but the team should still identify where it fits, where processes must adapt and where a different route needs consideration.
Does a small catalogue mean the project is simple?
Not necessarily. A store with few products can still have complex configuration, pricing, eligibility, delivery, payment or integration rules. Catalogue size is only one source of complexity.
Can every existing record be migrated automatically?
Migration depends on source quality, access, field mapping and the destination model. Decide which products, customers, orders, content and URLs need to move, what can be archived and how the migrated result will be reconciled.
Will technical SEO guarantee the store ranks first?
No. Technical and content foundations help search engines crawl and understand a useful site, but rankings and search features are controlled by search systems and competition. No responsible provider can guarantee first position.
09 / Continue
Turn the checklist into a commerce brief.
Explore the delivery service, or compare adjacent operational and integration needs.