Before A Website Rebuild, Map The Work The Site Must Actually Do
Every troubled rebuild we are called into has the same origin story. The old site feels dated, someone opens a spreadsheet of competitor screenshots, and within two weeks there is a Figma file full of hero sections and a launch date nobody can defend. The design conversation started before the work conversation, and the new site ships looking current while quietly preserving every structural problem that made the old one hard to use and harder to update.
This article is our pre-design mapping method. It is not a discovery questionnaire and it is not a sitemap exercise. It is a short, concrete pass over five kinds of work the site must do, written down before anyone argues about fonts. If you are choosing between platforms as well, our Drupal, WordPress, Shopify, or custom comparison picks up exactly where this map leaves off.
Why Design-First Rebuilds Keep Failing
A website is not a poster. It is a machine that takes content in at one end and produces enquiries, orders, bookings, or credibility at the other. When a rebuild starts with visuals, the team makes dozens of load-bearing decisions implicitly: how many content types exist, who edits them, what happens to old URLs, which forms feed which inboxes. Each decision lands on the designer's plate by default, and a designer working from screenshots is not equipped to make it. The predictable result is a beautiful site whose contact form emails a former employee, whose blog takes a developer to update, and whose "simple" landing page changes take three weeks.
The fix is procedural, not creative: write the work map first. It costs a few focused hours, and it turns the design phase from guesswork into execution.
The Rebuild Work Map
Walk these five rows in order, for every section of the current site and every section the new one needs. Be specific enough that a stranger could act on the answer.
| Map row | The question it answers | What good looks like |
|---|---|---|
| Content | What must the site say, in how many distinct types? | A counted list: pages, articles, products, cases, each with an owner. |
| Operations | Which tasks must a non-developer do monthly? | Publishing, price changes, job postings — each with the tool that does it. |
| Integrations | What must the site talk to? | CRM, email platform, booking, analytics — with direction and failure behavior. |
| Ownership | Who is allowed to break it? | Named roles for editing, publishing, and approving, not departments. |
| Update paths | How do security and platform updates arrive? | A stated cadence and a stated budget line, before launch. |
The last two rows are the ones teams skip, and they are the ones that decide whether the site is still healthy two years later. A site nobody is allowed to touch and nobody is paid to update is a relaunch waiting to happen. For a ready-to-print version of the mapping table, use the web build scope snapshot we publish alongside this method.
A Worked Example: One Row, Two Very Different Sites
Take the integrations row for two clients who both asked for "a new company website with a contact form". The first runs events and needs every form submission to create a tagged record in their CRM, trigger a confirmation sequence in their email platform, and fail loudly — an emailed alert, not a silent drop — if either connection is down. The second is a two-person consultancy where the form only needs to arrive reliably in one shared inbox.
Design-first planning treats these as the same feature: a contact form with a name field and a send button. The work map exposes the difference immediately. The first site carries three integrations with failure behavior and monitoring; the second carries one. One deserves a custom build budget line; the other is a morning of configuration. The worked calculation that settles the argument: the first client's map showed 11 integration points across the whole site, at roughly two to four hours of build and test each — 25 to 45 hours of integration work that no mood board was ever going to surface. That number, not taste, is what their rebuild estimate should stand on.
From Map To Estimate Without The Usual Surprises
Once the map is written, estimating becomes arithmetic. Content rows give you the migration count. Operations rows tell you how much editorial tooling to build. Integrations rows convert directly into hours with a stated failure behavior per connection. Ownership and update paths become maintenance scope instead of post-launch arguments. This is also the moment to set the quality bar in measurable terms: if organic traffic matters, state the performance targets explicitly — the Core Web Vitals thresholds Google publishes at web.dev are a sane default — so the design phase can be checked against them instead of retrofitted.
Two failure modes remain common even with a map in hand. The first is mapping the site you wish you had rather than the one you operate: every row should be answerable from current reality, with wishes listed separately. The second is treating the map as a one-time document. Sites drift; the map should be revisited at least twice a year, and any row that no longer matches reality is the row your next redesign will be about.
Map First, Design Second
The sequence is the whole argument. Write the work map in a week, cost it honestly, and let design respond to it rather than replace it. Rebuilds that start this way are boring in the best sense: fewer surprises at launch, estimates that survive contact with reality, and a site the client can actually operate without calling the agency for every comma.