A sound website-design process is not a parade of deliverables. It is a sequence for making the business decisions while they are still cheap to change: who the site is for, what it must explain, which proof is real, what a visitor should do, what the build must support, and what evidence will prove the finished site is ready to launch. This article owns which business decisions must be settled, by whom, and with what evidence; the small-business website timeline guide owns duration, waiting, and critical-path timing.

That boundary matters because a phase list is not enough. “Discovery, design, development, launch” tells a buyer when labels change. It does not tell them which unanswered question is about to turn into rework, who gets to resolve it, or what approval should exist before the next stage begins.

Use the process below as a decision map, not an agency workflow. Different providers may combine stages or use different names. The buyer’s job is to make sure the important decisions have a named owner and an observable exit condition.

The decision-by-stage map

Stage Decision that must settle here Business must provide or decide A capable provider should make visible Do not responsibly defer… Evidence that lets the stage close
1. Frame the job What business problem is the site meant to solve, for whom, and through what primary action? Priority audience, service or offer, geography or availability, material constraints, one decision-maker. A concise project brief that distinguishes a repair, restructure, migration, or new build. The primary buyer, the intended next action, or a known hard constraint. A written statement that the business can recognize as true.
2. Plan the paths Which pages and routes are needed for each important buyer decision? Which services, situations, proof, policies, and contact paths are genuinely distinct. Page jobs, navigation and URL plan, primary and secondary routes, and a list of existing URLs that need an outcome. Page purpose, final destination for a kept old URL, or a route that affects the build. A page map that names why each destination exists.
3. Establish the truth What can the site say and show without asking a reader to guess? Current facts, scope limits, real proof, permissions, qualified review for consequential claims, and the final factual approver. A source-and-approval list, complete draft content for the key pages, and clear gaps rather than persuasive placeholders. Material exclusions, claims that need proof, or facts only the business can verify. Approved facts and usable draft content, with open gaps explicitly held.
4. Choose the interaction and visual system How should the message, proof, and next action work on real screens? Brand assets, preferences that are truly decisions, and prompt approval from the named decision-maker. Representative page patterns, hierarchy, mobile and keyboard states, form/error/success states, and a reason for each important design choice. The meaning and size of core content, the primary action, or a required state a mockup does not show. Approval of the system and representative content, not a reaction to a homepage picture alone.
5. Build and connect What must work behind the visible pages, and who owns each dependency? Access to accounts and vendors, intended recipients, data and privacy requirements, and timely answers about third-party systems. A named implementation scope, dependency list, test environment or equivalent, and a clear distinction between configuration and unscoped investigation. A required form, booking, payment, analytics, migration, or account-control question. Included paths are working against agreed test conditions; unknown dependencies are held or separately scoped.
6. Verify, launch, and hand over What counts as ready, what is kept from the old site, and who can operate the result? Final fact approval, launch authorization, ownership and access recipients, and a named person to accept the evidence. A launch checklist, test evidence, URL/redirect results where relevant, account and access record, and a post-launch observation plan. A known broken path, missing asset/account control, or untested redirect from an important old URL. The agreed evidence exists and the responsible people can find it.

The map has a deliberate asymmetry. The business decides business truth and business risk. The provider turns those decisions into a coherent plan, makes dependencies visible, and shows what was actually tested. Neither side can do the other’s job by calling the project “collaborative.”

Stage 1: settle the job before you debate the look

The earliest decision is not the color palette. It is the problem the site needs to solve. A local service company may need a clearer path for unfamiliar visitors; a professional firm may need to make a complex offer legible; an established company may need to preserve useful search paths while changing the site. Those are different projects even if every proposal calls them a five-page redesign.

Ask the provider to finish one sentence: This site is for ***, who need to decide ***, and the first useful action is ___. Then add the constraints that could change the answer: a fixed deadline, a required platform, regulated claims, a legacy domain, a booking system, several reviewers, or an existing site that cannot simply disappear.

If this cannot be written down, design is being asked to settle a business decision in public. That is expensive for everyone.

Stage 2: decide page jobs before page count

A page inventory is a list only when it has no reason behind it. A real page plan gives each destination a reader, a question, proof, and a next action. It also exposes the routes that compete with one another: a page can be a service explanation, a qualification path, a proof destination, a contact path, or a policy requirement. It cannot responsibly be all five only because the project has a page allowance to fill.

For a redesign, this stage must also look backward. Google’s current site-move guidance says to map old URLs to their new destinations and to test redirects after implementation. That is a process requirement, not an SEO promise. The earlier a project decides which old pages deserve a clear successor, the less likely it is that a launch day becomes a scavenger hunt for missing links.

If duration is the question, use the small-business website timeline guide. This map stays with the earlier question: whether the decisions a schedule depends on have a named owner and exit condition.

Stage 3: treat content as verified material, not decorative fill

A project cannot design around truth it has not found. At this stage, separate four types of material:

  • Business facts: services, locations, eligibility, process, prices or price drivers, credentials, policies, and contact expectations.
  • Proof: permissioned reviews, images, examples, credentials, process evidence, and other support that can stand beside a claim.
  • Constraints: exclusions, availability, privacy limits, legal or regulated review, and facts that are not ready for publication.
  • Editorial decisions: hierarchy, plain-language explanation, page-level objections, and the action that best fits the reader’s state.

The business must verify the first three. A provider can research, organize, interview, and draft; it cannot safely certify a company’s operating facts from an old brochure. The useful standard is not “all copy done before design starts.” It is “enough honest, shaped material exists to make a design decision without pretending placeholder text is approved content.”

Stage 4: approve the system, including the states people actually use

Visual approval should answer a practical question: can a buyer understand the message, locate the next action, and use the important path on the screens and inputs that matter? A polished mockup may not show focus order, field labels, error messages, confirmation states, long service explanations, an empty result, or the mobile version of the same interaction.

W3C’s planning guidance recommends including accessibility throughout and evaluating early and regularly. In process terms, that means neither throwing accessibility at a checker at the end nor making a universal compliance claim from a single review. It means deciding early that headings, content order, keyboard paths, labels, contrast, error handling, and real interaction states are part of the system being approved.

At this stage, avoid feedback that asks for a stronger visual effect without naming the problem. Useful feedback names the reader problem: the service is still unclear, the proof is too far from the claim, the action asks for too much too soon, or the mobile path hides a needed detail. That gives the provider something to resolve.

Stage 5: make dependencies and responsibility visible

The visible site is only part of the build. A contact path may depend on a form, validation, storage, notification, an inbox, a scheduler, or another external system. A redesign may depend on domain and DNS access, analytics, a content-management platform, licensed assets, redirects, and old URLs. The project should name which of these are included, who controls them, what access is available, and which unknowns need investigation rather than a casual promise.

This is also where titles stop being sufficient. “We handle the build” is not useful if no one can say whether that includes a known booking integration, a form handoff, a migration task, or account access. The goal is not to pad a scope with every hypothetical. It is to surface the dependencies that could block the agreed site from doing its stated job.

Stage 6: close with evidence, not a launch announcement

Launching is a decision gate. The named approver needs more than a homepage preview: the important routes should be checked, the business facts should be current, and the handover should name who controls the accounts, content, assets, and operating information the project created or depends on.

For a site move, confirm the old-to-new mapping and redirects that the plan requires. For contact paths, test the path under the agreed conditions and confirm the resulting evidence rather than assuming a success message proves the full handoff. For the visible site, review the desktop and mobile views, keyboard paths, labels, and error and confirmation states that were part of the scope. The exact evidence should match the project. The principle does not: a launch is ready when the agreed criteria have evidence, not when everyone is tired of looking at staging.

What a buyer should ask at each approval

Use these questions to keep the decision map active during a project:

  1. What decision is this stage meant to close? If no one can answer, the deliverable may be activity without a gate.
  2. What fact or approval is still missing? Name it before it becomes an emergency.
  3. Who can make the binding decision? A list of reviewers is not an owner.
  4. What would change if we defer it? Some decisions can wait; a primary action, unverified claim, or required integration usually cannot.
  5. What evidence will show the decision was implemented? This prevents “approved” from meaning only “we saw a screenshot.”

The questions to ask a web designer before hiring gives a broader buyer checklist. Bring the map to that conversation and ask the provider to point to the actual decision owner, input, and evidence at every stage.

Keep a decision record, not just a phase list

At the close of each stage, keep a short record of the decision, its named owner, the evidence that supports it, and anything deliberately held for later. That record is more useful than a polished status deck when a question reappears in build or at launch.

It is not an RP internal SOP, a fixed delivery schedule, or a substitute for a written scope. It cannot decide a client’s business truth, validate legal or regulatory claims, or make a third-party system behave. Its narrower job is to help a buyer see whether a proposed process settles consequential decisions early enough and preserves enough evidence to close the project responsibly.

The best process is not the one with the most phases. It is the one in which no one reaches launch still wondering who was supposed to decide the buyer, the page job, the proof, the primary action, the ownership boundary, or the evidence of completion.

Sources