What to Expect During an Ecommerce Web Design Project
Most projects run late because of things sitting on the client's side. Almost nobody is warned about that in advance. Setting it out plainly, without blame, is the whole point of this page.
The Shape Of A Project
Every ecommerce build runs through the same six phases. The proportions are not the ones most people picture. Knowing the real shape is what allows a client to prepare for the parts that actually take time.
Discovery and structure. Working out what the shop has to do and how the catalogue divides. Short in calendar terms, decisive in outcome, since everything afterwards depends on it.
Design. How each page type looks and behaves. Moderate, running faster where the structure above it is already settled.
Build. Making it work. Frequently shorter than clients expect, which is hardest to believe since it is the thing people think they are buying.
Content and data loading. Usually the longest phase by a distance and almost always underestimated. Blocks three, four and five exist because of this one.
Testing. Checking it works, including a real order. Always the phase compressed when something has slipped, which is exactly when it should not be.
Launch. Short in itself, requiring planning where an existing shop is being replaced.
The pattern worth carrying forward: the phases people imagine are long, meaning design and build, are shorter than the phase nobody imagines at all.
What You Need Before You Start
Three groups of things. Assembling them before a project begins shortens it more reliably than anything the agency can do once it has started.
Access. The domain registrar login. Hosting, where you have it. Administrative access to your existing site. Analytics. Payment accounts, else the applications begun, since those involve checks that take as long as they take. And credentials for anything that has to connect, such as stock or accounting systems.
The recurring problem is not that access is refused. It is that nobody currently in the business knows where it is, because it was set up years ago by somebody who has since left. Finding out takes days rather than minutes, so doing it early costs nothing.
People. One person who approves work, plus somebody able to answer questions within a day or two rather than a fortnight.
Decisions. What the shop is actually for, whether that is more orders, fewer telephone calls or reaching somewhere new. And whether your deadline is genuine or aspirational, since the two are handled very differently and only one of them survives contact with block three.
Product Data
More projects run late because of product data than for every other reason combined. It deserves its own block. It also deserves understanding before anybody agrees a date.
What a usable product file contains. A unique code for every product. Name and description. Price, plus any customer specific pricing. A consistent variant structure. Stock figures. Weight and dimensions. Category assignment. Image filenames matched to product codes. And every attribute customers will filter or search by.
Why an export from an old system rarely produces one. An old system exports what it holds, in the shape it holds it. Fields are missing because the previous shop never needed them. Variants were expressed differently, sometimes as separate products. Categories reflect a structure you are replacing. Images are named by upload date rather than by what they show.
How long cleaning it takes. For any real catalogue, weeks of somebody's attention. Not an afternoon, nor something fitting alongside a full working week without the calendar moving.
Here is what makes this so persistently underestimated. The export looks finished. It opens, it has headings, it has one row per product and the row count matches what you sell. Everything appears present. The problems are all inside the cells. They are invisible until somebody tries to load it.
Photography
Four questions. The last determines whether the project launches on time.
Who takes it. A photographer, somebody internal with the right setup, else the manufacturer. Each works. Manufacturer imagery carries one caveat worth knowing: every competitor stocking that product has the same pictures.
To what standard. Consistent background, consistent crop, consistent lighting, consistent proportions. Products photographed at the same distance so they appear at comparable sizes in a grid.
How consistent it needs to be. More than most people expect. Consistency also matters more than individual quality. A shopper comparing four items in a grid is reading the differences between the photographs, so inconsistent backgrounds and crops make that comparison impossible regardless of how good any single image is.
Why it cannot wait until the build is finished. Three reasons. It becomes the only thing standing between a completed shop and launch, which is an expensive position to be in. Photographers have diaries, so booking one at the end means waiting for their availability rather than yours. And the design was chosen partly on the assumption of certain imagery, so a theme built around large photography needs large photography rather than whatever exists.
Content And Copy
Everything on a shop that is words had to be written by a person. Establishing which person is the single most useful thing this block can do.
What has to exist. Category descriptions that help somebody choose. Product descriptions answering what customers actually ask, the largest item by far. Policy pages, with proper advice taken on the wording rather than copied from another shop. An about page, delivery and returns detail, support pages.
Who writes it. Somebody internal, the agency at a cost, else a freelance writer. All three are fine. What is not fine is leaving it unassigned, which is the default outcome when nobody raises it.
What happens to a launch date when nobody has. One of two things. The date moves, carrying the cost of a project held open. Or the shop launches with placeholder text and gaps, which then remain exactly as they are for years, because the urgency evaporates the moment the site is live.
What makes it manageable. Start before anybody asks. Work in batches by category rather than randomly. Do the best sellers first, so any shortfall lands in the tail of the catalogue rather than across all of it.
Decisions And Who Makes Them
A build reaches a point where it cannot continue without an answer. These are the questions that stop it.
Delivery rules, including every exception. Weight bands, regions, thresholds, bulky items and what happens to a mixed basket.
Returns terms and category names. What you accept, within what period, at whose cost. Then the actual words your categories use, agreed rather than assumed.
What happens to discontinued products. Removed, hidden, kept with an alternative offered. This one is almost never decided in advance and it affects a great many pages.
Stock display. Whether shoppers see levels, plus what an out of stock product does.
Then the part that matters more than the list. Name one person who can decide. A project with three opinions and no decision stops silently, because everybody assumes somebody else is resolving it.
That person does not need to be the most senior in the business. They need to be available and genuinely empowered, since a question requiring three diaries to align takes a fortnight to answer and the build waits for all of it.
Testing And Approval
Approval is not a reaction to how the shop looks. It is a statement that the shop works, which means somebody has to establish that it does.
What to check yourself. Every page type, on a phone as well as a desktop, since designs get presented on large screens because they look better there. A genuine order paid with a real card. A genuine refund. What happens when a payment is declined, a form is filled in wrongly and a search returns nothing.
What nobody thinks to check. A product with a very long name. A category containing three items. An out of stock product. The awkward delivery cases from block six. And every automatic email, written once then read by every customer you have.
Follow this literally: place an order as though you had never seen the site and did not know what anything was called. Everything you hesitate over is a finding, whether or not you could explain why.
Launch
On the day. The domain points at the new shop. Redirects go live where a site is being replaced. The block preventing indexing is removed, the most commonly forgotten step in this industry, which produces an invisible shop looking perfect to everybody using it. Tracking is confirmed. Then somebody watches.
The first fortnight. Small things surface that no testing would have found, because real customers behave in ways test scripts do not. A display issue on an unusual device. A delivery rule meeting an edge case. A form field somebody uses differently. Expect a handful rather than reading them as a failed launch.
What is not normal. Checkout failing. Orders not arriving. Tracking absent. Whole categories missing. These differ in kind rather than degree and warrant immediate attention rather than a place on a list.
If you are replacing an existing shop. Expect a period of unsettled search visibility. Addresses have changed, redirects have to be followed and processed, so positions move about before they settle. It takes weeks rather than days and it is normal. Knowing that in advance is the difference between patience and panic. Migrations are their own discipline and sit in our site migrations guides.
After Launch
The project ends and the shop begins. That distinction is where most client and agency disagreements start.
Support covers things that are broken. Something not working as agreed, a fault under conditions nobody anticipated, an error nobody caught.
It does not cover things that are new. A feature nobody discussed, a change of mind after seeing it live, an addition somebody thought of afterwards. Both kinds of request are entirely reasonable. They are different requests. A project where that was never made explicit produces two parties each convinced the other is being unreasonable.
Training. Somebody shown how to add a product, change a price, process a refund and edit content, rather than sent documentation nobody opens.
What the first three months actually look like. Month one is small fixes and settling. Month two brings the first data worth reading, because a fortnight of traffic tells you very little. Month three is when the first structural questions appear, usually about categories that are not performing or products nobody can find.
That third month is also when the conversation about ongoing work should happen, before any support period ends rather than after it, so no gap opens where nobody is responsible for the shop.
What Causes Delay
Two lists. Publishing only the first would make this page a defence rather than a warning, so here is both.
On the client's side. Product data arriving in pieces, then corrections, then a second file contradicting the first. Photography not booked until the build is finished. One person able to approve, with that person away. Payment account applications started late. Delivery rules nobody will settle. Content nobody was assigned to write.
On ours. Scope not pinned down at proposal stage, which becomes uncomfortable conversations later where the client is made to feel unreasonable. Questions saved up and asked in batches rather than raised the moment they arise. Assumptions made about a business rather than checked, which surface during testing when they are expensive. Testing left until the end and then compressed. And the failure that causes most of the first list: not telling the client clearly enough what was needed and when.
We have been on both sides of several. The reason for publishing the second list is that most items on the first are preventable by an agency warning properly at the start, which is the entire purpose of this page.
A realistic timeline for your own project, with what moves it in either direction, is in how long it takes to build an ecommerce website.
You will know what
we need.
We set out what is required from you before a project starts rather than discovering it in week six. We tell you what remains outstanding at handover rather than describing everything as finished.
What a build covers:
Ongoing management afterwards sits inside our fixed monthly fee. Build work is quoted per project.
Twenty guides.
One subject.
This page covers the project itself. The rest of the series covers what a build costs, how long it takes, which platform suits which business and why the search ceiling is set during the build.
