Most web design projects do not fail because of bad design or bad code. They fail because of bad management: vague requirements, endless revision cycles, missed deadlines, budget creep, and a launch that arrives months late with everyone frustrated. The design and development are rarely the hard part — the coordination is.
This guide covers how web design projects are actually managed well, from first conversation to post-launch. Whether you are a business commissioning a website or a freelancer running client projects, these are the practices that separate smooth deliveries from painful ones.
Phase 1: Discovery — understanding before building
Every good project starts with discovery: structured conversations to understand the business, the audience, and what success looks like. This is not a formality — it is where the expensive mistakes get prevented.
A proper discovery covers: what the business does and what makes it different; who the website must convince and what those people care about; what actions the site needs to drive (enquiries, sales, bookings); what is wrong with the current site; technical constraints (existing systems, integrations, hosting); and how success will be measured. It should also surface the awkward questions early: who makes decisions, what is the real budget, and what is the actual deadline driver?
The output is a shared understanding documented in writing — a brief or proposal that both sides sign off. Verbal agreements about scope are the number-one source of project disputes. If it is not written down, it was not agreed.
Phase 2: Scope and planning — the contract with reality
Scope is the detailed list of what will be delivered: pages, features, integrations, content responsibilities, and what is explicitly not included. Good scopes are specific — "contact form with spam protection feeding enquiries to the client's email and CRM" rather than "contact page". Vague scope items become argument items later.
Planning turns scope into a schedule with milestones: design concepts by week three, development complete by week eight, testing in week nine, launch in week ten, for example. Build in contingency — experienced managers assume things will take longer than the optimistic estimate, because they always do. And identify dependencies ruthlessly: the project cannot launch if the client has not supplied photography, logo files, or final copy, so those delivery dates go in the plan with owners attached.
Content deserves special emphasis because it derails more projects than any technical issue. Decide up front who writes the copy, who supplies images, and by when. "We'll sort the content later" is how six-week projects become six-month projects. Our website development projects treat content planning as a first-class milestone, not an afterthought.
Phase 3: Design — structured creativity
Design works best as a narrowing funnel: broad exploration first, then refinement. Start with sitemaps and wireframes (structure without visual design) to agree what goes where. Then visual concepts for key pages — usually the homepage plus one or two critical templates — before rolling the approved style across the whole site.
The management discipline here is feedback. Unstructured feedback ("I don't like it", "make it pop") produces endless cycles. Structured feedback works: collect comments in one place, ask stakeholders to distinguish must-fix issues from preferences, set a fixed number of revision rounds in the agreement, and consolidate feedback from multiple stakeholders into one voice before sending it to the designer. Nothing burns time like contradictory feedback from three directors arriving on three different days.
Approve designs in writing at each stage before moving on. Design sign-off is a milestone with the same weight as a payment milestone — because reopening approved design during development is one of the most expensive things that can happen to a project.
Phase 4: Development — building in the open
Development should not be a black box. Good project management means the client sees progress regularly — a staging site they can visit, demos at milestones, plain-English updates on what was built this week and what is next. Surprises at the end of development are always bad surprises.
Technically, this phase includes building the templates and functionality, integrating third-party systems (payment gateways, CRMs, booking tools), making the site responsive across devices, and implementing on-page SEO fundamentals. Each integration should be tested as it is built, not saved up for a testing phase that then reveals six problems at once.
Change control matters here. New ideas will arise mid-build — that is normal and often good. The discipline is evaluating each one openly: what does it add, what does it cost in time and budget, and does it displace something else? Documented, agreed changes keep the project healthy; informal "while you're at it" additions quietly destroy schedules. For a related checklist mindset, see our web design and development checklist.
Phase 5: Testing, launch, and after
Testing is a phase, not an afternoon. A proper pre-launch checklist covers: functionality on all major browsers and devices, forms and checkout flows end to end, page speed, broken links, SEO basics (titles, meta descriptions, redirects from the old site), analytics and tracking, legal requirements (privacy policy, cookie consent under UK rules), and backups.
Launch itself should be planned: ideally at a quiet time, with a rollback plan if something goes wrong, and with DNS and hosting changes handled carefully to avoid downtime. Immediately after launch, monitor closely — analytics, error logs, and real user feedback — because no amount of testing catches everything.
And the project does not end at launch. Agree handover: training on the content management system, documentation, credentials transferred to the client, and a clear support arrangement for what happens next. Websites need ongoing care — which is exactly why we wrote about why website maintenance is critical for online sales.
The human side: communication and expectations
Underneath all the phases, project management is mostly expectation management. A few principles cover most situations: communicate proactively — clients forgive delays they knew about and resent surprises; be honest about bad news early, when there is still time to adapt; document decisions and agreements in writing; keep one point of contact on each side to avoid contradictory instructions; and celebrate milestones, because long projects need momentum as well as management.
For businesses commissioning work, the single most useful thing you can do is appoint one internal decision-maker with the authority to approve things. Projects with "the team will review it" as the approval process move at the speed of the slowest inbox. One empowered contact, available for quick decisions, is worth more than any project management software.
FAQs
How long does a typical web design project take?
A brochure-style small business site typically takes 4–8 weeks; a larger bespoke site or ecommerce build runs 8–16 weeks or more. The biggest variable is usually client-side: content delivery, feedback speed, and decision-making. Projects with an empowered single contact and ready content move dramatically faster.
What causes web design projects to go over budget?
Scope creep (adding features mid-build without adjusting budget), reopening approved design stages, late or missing content forcing rework, and underestimated integrations. All are management failures rather than technical ones — which is why written scope, change control, and content planning matter so much.
Who should manage a web design project — the client or the agency?
The agency or developer should manage the project day to day — that is part of what you are paying for. But the client must hold up their end: providing content on time, giving consolidated feedback promptly, and making decisions through one empowered contact. It is a partnership with clear responsibilities on both sides.
How many rounds of revisions are normal?
Two to three structured revision rounds per design stage is standard and should be agreed in writing up front. Unlimited revisions sound generous but actually produce worse outcomes — without constraints, feedback never converges and projects drift. Constraints force decisions, which is what moves projects forward.
What should be in a web design contract?
Detailed scope of deliverables, timeline with milestones, payment schedule tied to milestones, number of revision rounds, content responsibilities and deadlines, who owns the finished site and code, testing and acceptance criteria, post-launch support terms, and how changes to scope are handled and priced. If your contract lacks these, ask why.
Contact us if you want your next web project managed properly from day one — clear scope, honest timelines, and no surprises.
