Ecommerce Website Design Guide: Choose Before You Order

You have three proposals for building your online store. The headings look alike, but the prices and delivery times are far apart. The reason is simple: each vendor assumed your needs differently. This ecommerce website design guide helps you settle the build method, the essential features, the ongoing costs and the vendor's commitments before you place an order. What you end up with is a requirements document that puts every proposal on the same footing so you can compare them.

When does your store need its own website?

Your store needs its own website when manual selling can't keep up with order volume and mistakes start costing money. First, let's agree on a definition. An online store isn't just a digital shop window. It's a system that shows products, records orders and takes payment. It also keeps everything that happens after the purchase trackable.

These signs usually mean the time has come:

• Orders arrive through messaging apps, and now and then one gets missed or shipped twice.

• Customers have to message you and wait for a reply just to find out where their order is.

• Customer details are scattered across several people's phones, and you have no reliable access to them.

• You track stock in a notebook or a separate file, and sometimes sell items that are already gone.

The opposite call exists too. If your supply isn't stable yet, or nobody is available to handle the site day to day, a website won't fix your sales problem. It will just put the same disorder in front of customers, at a higher cost.

You also don't need to see the site as a replacement for your social media pages. In most stores, the two work side by side. The first output of this ecommerce website design guide is three lines in your requirements document: why you're launching, your current sales channels, and the name of the person responsible for the site's daily operation.

What should you settle before ordering an ecommerce website?

The first step in this ecommerce website design guide is simple. Before you order an ecommerce website, define the type of product and customer, the number and variety of products, payment and shipping methods, and your stock rules. The integrations you need, the budget for building and maintenance, and the person in charge of daily management must be clear too. Then separate launch features from later additions, and for each requirement write down an acceptance criterion and who owns the decision.

If you're asking what you need to know before ordering an online store, the short answer is this: you need to know what problem you're solving. A requirements document is an early agreement about the problem, the constraints and the expected outcome. It isn't a list of technology names. That's why a line like "build it in such-and-such programming language" almost never helps an estimate.

So my suggestion is to write each requirement as one row with five columns. This simple template is the backbone of every ordering guide I give clients:

The last column matters most. If you don't write down how something will be verified, both sides will argue on handover day about whether it's "done". Complete the document once and send that same version to every vendor. In this ecommerce website design guide, each section adds a new row to this document.

How do purchase scenarios clarify what your store needs?

A purchase scenario turns a vague need into behaviour you can test. Say, for example, a clothing store has 200 designs. The number is entirely hypothetical and is only here for practice.

Here's the first catch: 200 designs doesn't mean 200 products. If each design comes in four colours and five sizes, you're dealing with around four thousand variants. Stock makes sense at the variant level, not the design level. The blue shirt in size M might sell out while the same design is still available in other colours.

Now write out three paths in full:

1. A normal purchase: the buyer picks a design, colour and size, pays, and gets a confirmation message.

2. Going out of stock during checkout: the last size L is in two people's carts and one of them pays first. What does the system do with the second person?

3. A partial return: the buyer sends back one of three items. How are the refund amount, the shipping cost and the stock corrected?

The second path is where the phrase "inventory management" actually gets its meaning. So instead of that general phrase, write: "Concurrent orders must not be confirmed beyond the sellable stock." That's a sentence a testing team can genuinely test.

A requirement you can't test isn't a requirement yet; it's a wish that found its way into a contract.

For each path, also name the person who decides what the correct behaviour is. The returns policy, for example, belongs to the sales manager, not the developer. If you ask me where in this ecommerce website design guide you should spend the most time, my answer is right here.

Hosted store builder, WooCommerce or custom development?

The choice depends on how well your sales process fits a ready-made solution, not on taste or a tool's reputation. Definitions first:

• Hosted store builder: a ready-made service that gives you a store to build and run on a subscription. Infrastructure and updates are the provider's job.

• WooCommerce: a store plugin running on WordPress, where hosting and maintenance fall to you or your vendor.

• Custom development: a system built around your specific process, with code written for exactly that job.

Don't answer the common "WordPress or custom?" question with your product count, because product count is a poor yardstick. A store with few products may have complex pricing. Meanwhile, a store with thousands of products may be perfectly comfortable on a ready-made solution. Run the scenarios from the previous section against each option and see which one handles them without patchwork.

Follow this order for a first screening:

1. When your scenarios run on a store builder's standard features and you have no special integrations, start there.

2. If you need more flexibility, specific plugins or independent hosting, evaluate WooCommerce.

3. If, after a serious review, no ready-made solution covers your core scenario, move to custom development.

Still, this list isn't a final decision tree. It only rules out options that don't fit. From the point of view of this ecommerce website design guide, none of them is inherently better. And "we have special needs" isn't, on its own, a reason to build custom. Write down in the document which option you chose, why you set the others aside, and which points still need technical review.

What features does an ecommerce site have, and which are essential at launch?

If you ask what features an ecommerce site has, the list is almost endless. But at launch, only the ones without which an order can't be completed, or operations start limping, are essential. I always sort features into three groups: essential for ordering, essential for operations, and deferrable.

A minimum healthy path has these links: complete product information, variants and stock, a cart, payment, shipping calculation, status notifications to the buyer, and an order management panel. Every missing link means someone behind the scenes has to fill the gap by hand.

Some features don't have a fixed place. Search and filters may not be needed for a store with a few dozen products, but they're essential for the clothing store from the previous section. Guest checkout, meaning buying without creating an account, helps one-off purchases. Discount codes are needed from day one if you run regular campaigns. Any ecommerce website design guide that hands you a fixed feature list will mislead half the stores that follow it.

For example, suppose the budget only stretches to one of two things: a loyalty club, or correct shipping costs based on city and weight. The loyalty club can wait a few months. But wrong shipping costs mean either a loss on every order or an angry call from the buyer. At this stage of the ecommerce website design guide, you come away with two lists: in scope and out of scope for version one, with the reason behind each priority.

How much does an online store cost, and how is the budget set?

The cost of designing an online store depends on scope. That's why there's no fair number without a requirements document. These factors have the biggest effect on an estimate:

• Scope: the number of scenarios and user roles, not the number of pages.

• Data quality: a tidy product file with unique IDs, or a scattered list that needs cleaning up.

• Design: a ready-made theme with configuration, or a user interface designed from scratch.

• Integrations: every external system, from accounting to the shipping company, needs its own work and testing.

• Testing: the more payment and stock scenarios, the heavier the testing.

• Data migration: moving orders and customers from a previous site is not a small job.

Also look at build cost separately from everything else. Content entry, product photography, tool and plugin licences, hosting and advertising to attract customers usually sit outside the build contract. Many disputes start from exactly these unwritten assumptions.

Compare two proposals only when their assumptions are the same. For instance, ask each vendor how many data types and how many integration scenarios their price covers. A cheaper proposal that leaves product entry to you isn't cheaper in practice; someone still has to do that work. To see a reference version of our service scope, take a look at ecommerce website design services and reference pricing.

So write three things in the document: your budget ceiling, the costs you know fall outside the contract, and the items that are still unclear. Stating a budget ceiling isn't a negotiating weakness; it helps the vendor propose a realistic scope. Any ecommerce website design guide that gives you a figure without that ceiling is guessing.

How do you assess maintenance costs and the ability to move?

To assess maintenance costs, ask for a list of specific tasks, not one flat monthly fee. Maintenance means updating the core and plugins, monitoring errors, taking backups, testing that they restore, and responding to outages. Building new features isn't maintenance and needs a separate agreement. In this ecommerce website design guide I take maintenance more seriously than the build, because a store is built in a few months and runs for years.

The first question I usually ask a vendor is this: if payments start failing at eleven at night, who notices? Then two more:

• Who follows it up, and how quickly do they respond?

• Who holds the access needed to fix the problem, such as the hosting panel or the payment provider account?

If the answer to all three is "you", that's fine. But you need to know in advance and have someone ready for it.

A store you can't walk away from isn't your asset; it's a lease whose terms someone else writes.

The ability to move is just as important. Exporting products alone isn't enough for a migration, because past orders, customer data, original-quality images and page addresses also have to move. User passwords usually can't be transferred directly, so customers may have to create new ones.

In the document you build with this ecommerce website design guide, write down who is responsible for maintenance, which costs recur, which items can be transferred, and what you receive when the engagement ends.

How should a product page be judged for purchase decisions?

A buyer should be able to decide without contacting you; that's what a good product page means. The simple test: can they tell whether the product suits them, what the final price is, whether it's in stock, and when it will arrive? If you keep only one test from this ecommerce website design guide, make it this one.

For our hypothetical clothing store, a size guide and an accurate photo of each colour matter more than a big slider and decorative effects. A buyer who isn't sure size L will fit either sends a message or closes the page. And if they do buy, the odds of a return are high.

Make a few things clear before the add-to-cart button:

• The out-of-stock status of each variant, and whether the buyer can ask to be notified when it's back.

• Price differences between variants, if larger sizes cost more, for instance.

• Return conditions in plain language.

• Shipping restrictions, such as a product that can't be sent to every city.

At the same time, test the page on a real phone, not just in the designer's preview. Buttons should be easy to tap with a finger and text should be readable without zooming. Someone navigating only with a keyboard should also be able to pick a size. For more detailed criteria, the web accessibility guidelines are a good reference.

The output of this section is a product content template: which fields, how long, and which images. So approve the sample page against these criteria, not because the design looks nice.

What acceptance criteria apply to the cart and payment?

The core criterion is this: the buyer knows the full amount before paying, and no error ever loses money or an order. Product price, discount, shipping and any other charge must be visible before the buyer goes to the payment gateway. Form errors should appear next to the field in question, not at the top of the page as a generic message.

Most teams build the happy path well. The trouble lies in the other paths, and each one should be written out separately:

• The buyer returns from the gateway after a failed payment; their cart should still be there.

• Money has been taken, but the connection dropped before returning to the site.

• The buyer clicked the pay button twice or refreshed the page.

• Between entering the gateway and returning, the last unit of the product was sold.

Be sure to write one technical rule into the document: payment confirmation must happen through a trusted server-side path. In other words, the site itself queries the payment provider. A receipt shown in the browser, or the user simply landing back on the site, is not proof of payment. Read this section of the ecommerce website design guide with the most care, because payment errors hit buyer trust directly.

The document's output is this list of statuses, plus the rule for following up unclear transactions and the name of the person who answers a worried buyer.

Where does SEO enter store design?

SEO enters the design the day you decide on your category structure and page addresses. SEO means preparing pages so search engines can find and understand them. So don't reduce it to writing a few articles after handover; by then most of the decisions that matter have already been made. That's why in an ecommerce website design guide, SEO sits next to structure, not next to advertising.

Make three decisions before you load content at scale. First, the map of categories and subcategories. Second, stable product URLs: addresses that don't change when the price or category does. Third, how filter pages behave. Combinations of colour, size and price can generate thousands of duplicate URLs, while only a handful deserve to be found.

Also make the difference between a temporarily out-of-stock product and a discontinued one clear. The page of a product that's coming back should stay, with only its status changing. A product removed for good is better sent via a permanent redirect to the closest product or category.

In a redesign, prepare the full list of old URLs and the replacement destination for each before launch. Nobody can guarantee rankings; even so, following Google's official search documentation prevents avoidable damage. Document output: the category map, rules for filter pages, and who is responsible for product content.

How do you make sales measurement trustworthy from day one?

Define exactly what you're counting before launch; that's the only way measurement can be trusted. An event is the record of a specific user action, such as adding a product to the cart. A page view, starting checkout and a confirmed purchase are three separate events and must not be mixed up.

Plan for two common mistakes from the start. If the purchase event fires when the thank-you page loads, every refresh of that page creates a new purchase in the report. The second mistake is a wrong expectation: analytics figures almost never match real orders, because some users block tracking.

So your source of truth for sales is the orders panel. Regularly reconcile the recorded amounts with payments, cancellations and refunds. Visit numbers alone don't show whether the store is succeeding. To find where buyers drop off, read customer journey analysis to find purchase barriers.

There's a security point as well. Don't send customer names, phone numbers or addresses to analytics tools without reason, and give report access only to those who need it. This part of the ecommerce website design guide adds three items to your document: the list of events, a precise definition of a successful purchase, and who investigates report discrepancies.

What does connecting to accounting and inventory require?

The main prerequisite for an integration is agreement on the data, not the technical existence of a connection. An application programming interface, or API, is the channel through which two systems exchange data. Your accounting software having an API only means the door is open; it says nothing about what's behind it. This section of the ecommerce website design guide usually has the biggest impact on the estimate.

Clarify these before the estimate:

• Source of truth: which system decides price and stock?

• Shared identifier: does each product variant have the same code in both systems?

• Update interval: real time, every few minutes, or once a day?

• Stock reservation: is an item reserved when added to the cart, or on payment?

For example, suppose accounting sends stock levels to the site every night. Then in-store sales between noon and night aren't visible on the site, and the same item gets sold online too. So either accept that risk knowingly or shorten the update interval.

Also, resending the same message must not create a duplicate order or accounting entry, because connections sometimes drop and systems retry. It must be clear where errors are logged, how many retries happen, and who gets notified.

If you sell in-store and online at the same time, walk through this scenario with whoever runs your accounting before the estimate. Order cancellations and returns must also be recorded correctly on both sides. Document output: the list of exchanged data, integration documentation, and the person who signs off on each side.

Which documents and access should be ready before kickoff?

Before kickoff, product data, brand identity, operational rules, legal documents and account access should be ready, or at least defined. Here's the base list I recommend in this ecommerce website design guide:

• A product data file with the name, description, price, variants and ID of each item

• Good-quality product images with a consistent aspect ratio

• Brand identity: logo, colours, font and tone of voice

• Shipping, returns and refund rules in writing

• The business's legal details for the payment gateway and legal pages

• The name of the person who approves final content

However, payment provider requirements and licences tied to your type of business can change. So check them, up to date, with the official source for each service. There's no fixed rule for every store, and selling some products comes with separate conditions.

Be strict about access. The domain and main accounts, such as hosting and the payment gateway, should be in the business's name and under its control. So give the vendor a separate account with the minimum level needed, not the password to the main account. We've covered more detail in prerequisites for building a site and preparing access.

One warning: don't send passwords, API keys or customer data in your initial request for an estimate; no vendor needs them at this stage. In the document, note what's ready, what's incomplete, who owns each account, and by what date each item is needed.

How should ownership and responsibilities be set out in the contract?

Spell out ownership item by item in the contract, because "the site is yours" is a sentence each side understands differently. In this ecommerce website design guide, we treat these items separately: the domain, the data, the design files, the deliverable code, and licences for third-party tools.

That said, not every component is necessarily transferable. A theme or plugin bought on an annual licence usually doesn't become yours; you only have the right to use it. On a hosted store builder, the underlying code belongs to the provider. Read licence and subscription terms before you order.

Another boundary is the difference between fixing a defect and a new feature. Say your document states that discount codes shouldn't apply to sale items, but they do. That's a defect, and fixing it is on the vendor. But if you now want the code to work only on a first purchase, and that wasn't in the document, it's a new request and needs its own estimate.

This isn't a substitute for legal advice. For more pointers, see the guide to drafting a website design contract, and have your lawyer review the final contract.

Which decisions and dependencies is the timeline tied to?

Your decisions and inputs shape the timeline more than the team's speed does. When a vendor gives you a timeframe, they're assuming several dependencies. Content will be ready on time and the design will be approved within a reasonable period. Integration access will arrive and outside parties, such as the payment gateway or shipping company, will respond.

Separate calendar time from the team's working time. The actual work might take a few weeks, but waiting for the product file or design approval can stall everything. That's why I always log waiting periods separately in project reports, so it's clear where a delay came from.

If you have a fixed business date, such as the start of a sales season, you have two options: shrink the scope of version one or compress testing. My recommendation is almost always the first, because skipping payment tests to hit a date is a risk that shows up on the first day of sales.

In the document, write down the target date, open dependencies, the owner of each decision, and the rule for how scope changes affect time. This ecommerce website design guide focuses on decisions; for a step-by-step account of delivery, see ecommerce website design stages, from contract to handover.

What tests should a store pass before handover?

A store is ready for handover when it successfully passes the scenarios in your requirements document; the homepage loading proves nothing. So pull your acceptance criteria straight from the table that had the verification column.

Depending on the agreed scope, this ecommerce website design guide recommends at least these tests:

1. Buying a product in a specific variant and checking that stock for that variant drops

2. Trying to buy the last unit of a product from two devices at once

3. Shipping to a region with a different shipping cost

4. Applying a discount code, and a case where it shouldn't apply

5. A failed payment and returning to the cart

6. A full and a partial refund

Also actually restore a backup, in an environment separate from the live site. A backup that has never been restored is just an assumption. Check the admin account, staff permission levels, and the removal of the vendor's temporary access too.

For speed and capacity, a number without context isn't an acceptance criterion. Write down the test conditions: which device, which network, and how many concurrent users. That's why "the page loads in three seconds" proves nothing without those conditions.

My suggestion is that the client runs acceptance testing with the vendor present. Record the result of each test with evidence, such as a screenshot or a test order number, and assign an owner to fix each error. Split errors into two groups as well: those that block launch, and those that can be handled after launch.

How does this ecommerce website design guide become a decision document?

This ecommerce website design guide becomes a decision document when you gather each section's output into four clusters. Each cluster has an open question, and it isn't closed until the answer is in writing.

Treat the table as a reading roadmap too. If, in a cluster, you hit a topic that needs separate expertise, such as tax on online sales or designing a loyalty programme, flag it for further study. You don't have to solve everything before requesting an estimate.

For example, suppose your document says "inventory integration required". Until you've decided which system is the source of truth for stock, that row's status is "not reviewed", not "decided". That simple label tells the vendor where they need to ask questions and where they can estimate.

The consolidated document has three parts: assumptions, firm decisions, and remaining uncertainties. Hiding uncertainties doesn't make an estimate more accurate; it just postpones the surprise.

What should you send Niasa for an estimate?

Send your requirements document along with a few real examples; that's the practical summary of this whole ecommerce website design guide. Copy this template and fill it in:

• Type of sales: retail, wholesale or both

• Products and variants: approximate number of designs and variant attributes such as colour and size

• Current channel: in-store, social media or an existing site

• Operational problems: where you currently have errors or waste time

• Essential features: the in-scope list for version one

• Integrations: accounting, inventory, shipping, SMS

• Budget: ceiling for build and maintenance

• Target date: along with the business reason for it

Alongside the document, send two complete product examples and one complex order scenario, such as an order with a discount and a partial return. If you use real data, remove customer names, numbers and addresses before sending.

At Niasa, we prefer to write ecommerce website proposals with the scope, assumptions, exclusions, dependencies and delivery criteria spelled out. So ask us for exactly that. Of course, these are refined during the requirements conversation and aren't fixed in advance.

If you haven't chosen a build method yet, don't ask for a fixed price; use this ecommerce website design guide to request a review of your options instead. A fixed price for a project with unclear scope is either padded with safety margin or full of exclusions.

Send the document however incomplete it is. In the requirements conversation, we'll work out together which rows are settled and which still have open questions.