Proven Web Design and Development Process, Real Steps

The web design and development process runs six phases from discovery to launch and post-launch retainer. Each phase has a defined input, a defined output, and a named owner who signs off. Skip one to save two weeks in month one and you buy back six weeks of rework in month six. Every real project follows this six-phase pattern, adjusted for team size and scope depth. This guide walks through what actually happens in each phase and what the deliverables look like when a team is doing the work honestly.

You will see the same phases on a 12-page charity site, a 60-page corporate rebuild, or a 200-page enterprise platform. What changes is depth, timeline, and parallelism. Use the phase notes below to sanity check whichever agency is pitching your next build. If their process document skips wireframes or treats QA as the last three days of coding, you are looking at a team planning to hand you technical debt on day one. The rest of this guide walks every phase in order, with the deliverables, the owners, the review cycles, and the failure modes each phase quietly hides when a team is rushing.

Phase one is discovery and it sets every downstream cost in the web design and development process

Discovery runs one to three weeks and produces two documents. The first is a scope document. The second is a project plan with named owners on every deliverable. Discovery inputs are the requirement form, the stakeholder interviews, a competitive audit on 5 to 8 sites, and a content inventory of the current site. Discovery outputs are the sitemap, the primary user journeys, the integration list, the KPI list, and the timeline. Every one of those becomes an input to the next phase. Any agency that promises a homepage mockup inside week one is skipping discovery and betting they can guess the scope. That bet loses in month three.

Stakeholder interviews cover marketing, sales, product, customer service, and one executive sponsor. Every interview runs 30 to 45 minutes and asks the same six questions so the answers compare cleanly. What does the site need to do more of. What does it need to do less of. Who is the site really for. What does success look like in twelve months. What is the biggest constraint. What has the current site been getting wrong. Any discovery phase that skips the stakeholder interviews is going to hit month two with a redesign nobody in the client org actually wanted.

The competitive audit runs on 5 to 8 direct competitors and 2 or 3 out-of-category sites the client admires. For each site the team notes primary conversion goal, navigation shape, hero pattern, proof strategy, pricing surface, and any feature that keeps showing up. That short audit surfaces the design language your buyers already recognize and the gaps you can beat. Any team that skips the out-of-category examples is going to design a site that looks exactly like every other agency in the same vertical.

Scope document as the discovery deliverable

The scope document lists every page template, every integration, every content type, every review cycle, and every exclusion. Exclusions matter as much as inclusions. If email marketing setup is out of scope, the scope document says so in plain English. If multi-language is out of scope, the scope document says so. Any agency that leaves exclusions vague is planning a change-order in month four. A tight scope document reads in fifteen minutes and closes the “did we scope that” argument before it starts.

Project plan with named owners on every deliverable

The project plan lists every deliverable, every reviewer by role, every review window in business days, and every dependency. Named owners means the person who owns sign-off, not the team the person sits on. “Marketing” does not sign off on a homepage. Julia in marketing signs off on the homepage. That specificity is what makes the plan enforceable. Any project plan without named owners will hit a Friday afternoon debate over who owns approval and the launch slips a week.

Phase two is information architecture, the web design and development stage that decides every navigation call

Information architecture runs two to four weeks and produces the sitemap, the wireframes, and the content model. The sitemap defines every page and every navigation path. Wireframes lock the structure of every unique template before a single pixel of visual design gets made. The content model defines every reusable module (hero, feature grid, testimonial, CTA band, FAQ, comparison table, pricing table) so the design system phase has a real list to build from. Any agency that jumps to high-fidelity mockups without wireframes is designing on vibes and will redraw every page twice.

Wireframes get reviewed by the client leadership team, not by the marketing manager alone. The reason is that wireframes decide what makes the primary navigation, what gets buried, and what gets a dedicated landing page. Those are executive decisions dressed up as design decisions. Any wireframe review that skips executive review will land visual design that the CMO rejects at week seven and the project loses two weeks. Front-load the decision. Get the executive sponsor in the wireframe review.

Sitemap tied to the content model

Every page on the sitemap gets tagged with the modules it uses. A service page uses hero, feature grid, proof strip, comparison table, pricing table, FAQ, CTA band. A blog post uses hero, body, protip, FAQ, related posts, CTA band. Once the sitemap and the content model line up, the design system phase has a finite list to build. That finite list is what keeps the design system phase from turning into an art project.

Wireframe review cadence

Wireframes review in two rounds. Round one covers structure and hierarchy. Round two covers copy blocks and interaction notes. Every round runs three to five business days. Any wireframe phase that runs a single review cycle at the end is going to miss half the structural feedback and hit visual design with a shaky foundation. Two rounds is the floor, not a nice-to-have. Bake it into the project plan on day one.

Phase three is visual design and the design system, the phase that decides how fast every future page goes live

Visual design runs three to eight weeks and produces the design system plus the high-fidelity mockups for every unique template. The design system covers color, typography, spacing, elevation, motion, iconography, and every reusable module from the content model. Every mockup gets built out of the design system components, not as a one-off. Any team that designs the homepage as a bespoke artifact and then tries to back-fit a design system later is going to spend two weeks reconciling the two.

Mockups review in two rounds like wireframes. Round one covers direction, meaning does this feel like the brand. Round two covers detail, meaning do these buttons, forms, and states hold up on every module. Any team that runs a single review cycle at the end of visual design is going to hit build with a stack of unresolved design questions and the front-end team will make ten of them on their own.

Design system scope inside the visual design phase

The design system covers four layers. Primitives are color tokens, type scale, spacing scale, and elevation ramps. Components are buttons, inputs, cards, tabs, and accordions. Patterns are hero, feature grid, proof strip, CTA band, FAQ, comparison, and pricing. Page templates are homepage, service page, blog post, blog index, case study, and contact. Every one of those gets documented with usage rules and states. That documentation is what lets the build phase run without a design review on every module.

Mockup fidelity for the client review

High-fidelity mockups get delivered as clickable Figma prototypes on desktop and mobile viewports. Real copy blocks, not lorem ipsum. Real photography, not placeholder gray boxes. Real button labels, not “click here”. The moment mockups review with placeholder content the client reviews the placeholders instead of the design. That is a wasted review cycle. Put the real copy in the mockups from round one, and revise it in parallel during build.

Phase four builds the site inside the web design and development project plan

Build is the phase everyone thinks is the whole project. It is one of six phases and takes four to twelve weeks depending on scope. Front-end and back-end usually run in parallel once the design system is locked. Front-end turns Figma components into HTML, CSS, and JavaScript. Back-end wires up the CMS, integrates third-party tools (CRM, email, analytics, search, e-commerce), and configures the hosting. Every module built off the design system means every future page inherits the same visual language without a new decision. That is the compounding return on the design system phase.

The web design and development project plan schedules a mid-build demo at week two of build. The client sees the homepage in staging, running live, on real devices. Not a Figma prototype. Real code. This demo catches the design-to-code gap early. Colors that read differently in browser than in Figma. Motion that feels slower on real devices. Font weights that fall back on Windows. Every issue caught at the mid-build demo saves two rounds of pixel-nudging at QA. See web.dev on responsive typography for the browser-side patterns that most agencies miss until QA.

CMS block model built off the design system

Every named module from wireframes becomes a real CMS block. WordPress builds them as Gutenberg blocks or ACF pattern blocks. Headless builds create React components fed by a CMS API. Every block gets editorial controls that a content editor can operate without a developer. Color variants, text alignment, image swap, CTA copy. Any build that hardcodes the homepage in a template and forces the client to edit PHP for every copy tweak is an agency-dependent build, not a client-friendly one.

Integration timing inside the build phase

Integrations get scoped in discovery, locked in the requirement form, and built during the back-end sprint. HubSpot, Salesforce, Mailchimp, Klaviyo, Stripe, Calendly, GA4, Search Console, PostHog, Segment. Every integration is its own mini-project with its own testing plan. Any build that leaves integrations for the last two days before launch is going to launch with a broken form flow. Integration testing runs before QA, not during. Each integration needs its own rollback plan in case the vendor changes an API contract mid-build.

Phase five is QA, the web design and development stage most teams shortchange

QA runs one to three weeks and covers cross-browser testing, cross-device testing, accessibility audit, performance audit, SEO audit, and content proofing. Any QA phase that runs under one full week is a launch checklist masquerading as QA. Real QA finds the modal that only breaks in Safari on iOS 16. Real QA catches the alt text missing on 40% of blog images. Real QA measures LCP, CLS, and INP on 20 real URLs, not a synthetic Lighthouse run in an incognito window. Any agency that skips QA to save five days is planning a hot-fix sprint the week after launch.

Every project gets a QA punch list sorted by severity. Critical bugs (broken flows, missing content, accessibility fails) block launch. Major bugs (visual regressions, minor form issues, content typos) fix inside launch week. Minor bugs (spacing tweaks, hover states, browser-specific quirks on IE-mode) go into the post-launch backlog. This triage is what separates a real QA process from a chaotic launch week where every issue feels equally urgent to whoever spotted it last.

Accessibility audit as a QA workstream

Accessibility gets a dedicated QA workstream, not a Lighthouse tab check. Axe DevTools runs on every unique template. WAVE scans 20 sample pages. A keyboard-only pass covers the top 10 conversion flows. A screen reader pass with VoiceOver on macOS and NVDA on Windows covers the homepage and one deep interior page. Color contrast checks every button, link, and text-on-image module. Any QA phase that treats accessibility as a Lighthouse score is going to launch a site that will trigger an ADA complaint inside twelve months.

Performance audit on real URLs

Performance testing runs on 20 real URLs, not a homepage synthetic test. Google’s page-experience metrics get measured on 4G mobile, cable desktop, and slow 3G if the audience includes rural regions. Any page failing LCP under 2.5 seconds gets a fix, usually image optimization or a critical CSS split. Any page with a CLS above 0.1 gets an image dimension fix. Any interactive-heavy page failing INP under 200ms gets a JavaScript audit. Skip the fixes and the launch scores 60 on mobile inside PageSpeed the day after launch.

Launch runs a real web design and development checklist, not vibes

Launch day is boring when the checklist has been maintained since kickoff. Every serious web design and development checklist covers redirects (every old URL mapped to the new one), DNS cutover (TTL lowered 48 hours in advance), SSL (HTTPS enforced, HSTS header set), analytics (GA4 verified with Realtime showing the launch traffic), Search Console (property verified, sitemap submitted), backups (full pre-launch snapshot taken), monitoring (uptime and error alerts wired to the on-call channel), and communication (a launch note to the client team so support is not blindsided). See Google Search Central on site moves with URL changes for the redirect and Search Console steps every clean migration follows.

Small teams often try to launch in the afternoon of a workday. Bad idea. Launch in the morning of a workday. If something breaks, the whole team is awake to fix it. Never launch on a Friday. Never launch the day before a holiday. Never launch during a client’s own busy season. These sound obvious. Every agency that has been running for five years has broken all three of them at least once. Learn from the scars.

Redirect map before DNS cutover

Every old URL gets a 301 to the new equivalent. Any URL that no longer exists (blog posts pulled, service pages consolidated) gets a redirect to the nearest topical page, not a bulk 404. A clean redirect map preserves inbound link authority and keeps organic traffic intact through the transition. Any launch that skips the redirect map is going to lose 20% to 50% of organic traffic in month one and blame the algorithm. The map lives as a spreadsheet with old URL, new URL, redirect type, and a QA pass column.

Analytics verified in Realtime on launch day

GA4 gets a Realtime check five minutes after DNS propagation. If the visitor counter does not tick up, the tag is broken. Same for Search Console. Same for any other tracking (Meta Pixel, LinkedIn Insight, PostHog, Segment). Any launch that trusts the tags without a Realtime check is planning a Wednesday morning revelation that the site has been running dark for 72 hours and there is no attribution data.

Every web design and development process ends in a retainer

Launch is not the end of the web design and development process. Launch is the start of the retainer. Every serious project drops into a retainer that covers content updates, security patches, performance monitoring, accessibility maintenance, and monthly reporting. The retainer runs 15% to 30% of the build cost annually. Below 10% is reactive-only. Above 40% is padding scope. Any client who skips the retainer will need a full rebuild inside 24 months since nothing on the internet stays working without maintenance.

Our client the home services client is the classic long-run retainer story. We started with a full rebuild across marketing, SEO, paid media, and content. Every quarter after launch the retainer added a new campaign, refreshed the top pages, and reported the numbers to their leadership team. Annual revenue climbed from $1.5 million to $6.8 million over the nine-year partnership, a 353% increase, backed by 784% traffic growth and 637% growth in marketing-qualified leads. That number does not happen on a one-and-done build. It happens since the site got treated as a live product, not a launched artifact.

Retainer workstreams that matter

Every retainer covers monthly content updates, monthly analytics reporting, quarterly accessibility audit, quarterly performance audit, quarterly SEO refresh on the top 20 URLs, and ongoing security patching. Any retainer that only covers plugin updates is a maintenance plan, not a real retainer. The retainer is where the site earns compounding returns. Skip it and the site starts drifting inside eight months. Retainer hours flex up during quarterly campaigns and down between them, which keeps the spend honest.

Reporting cadence for the client team

Every month the retainer produces a two-page report. Traffic trends, top pages, top search queries, form submission counts, campaign performance, and a punch list of what launched this month. The report goes to the client project lead and the executive sponsor. Any retainer that produces a 40-page Google Analytics dump instead of a two-page summary is not doing the work the client actually needs. Executives read two pages. They do not read forty.

Team sizes across the web design and development phases

Team size shapes the process as much as scope does. A three-person team runs a small site with tight overlap. One person covers discovery and content. Another covers design and front-end. A third covers back-end and QA. A six-person team runs a mid-size project with dedicated roles for producer, discovery lead, designer, front-end, back-end, and QA. A twelve-person team runs an enterprise build with parallel workstreams for design system, content, engineering, integrations, QA, and project management.

Every team size runs the same six phases. What changes is how much parallelism the team can support and how many review cycles fit inside each phase. A three-person team is faster in some ways (fewer handoffs) and slower in others (fewer parallel workstreams). A twelve-person team moves faster on large builds but needs a strong producer to keep the workstreams from drifting apart. Any web design and development project plan that runs the wrong team size for the scope will overrun on timeline, budget, or both.

Three-person team shape

Three-person teams fit builds under $40K. One person covers strategy and content. One covers design and front-end. One covers back-end and QA. Everyone reviews everyone. Timeline runs 8 to 14 weeks on a 15-page site. Any three-person team that tries to run a 60-page enterprise site is going to burn out inside six weeks. Match team size to scope. Add a part-time QA lead for the last two weeks so the same eyes that built the site are not the only ones testing it.

Six-person team shape

Six-person teams fit builds from $40K to $120K. Producer, discovery lead, designer, front-end developer, back-end developer, QA lead. Every role has clear ownership. Reviews stay tight. Timeline runs 14 to 22 weeks on a 40 to 80 page site. Most real agency work sits at this team size since the returns on parallelism outweigh the coordination cost. A dedicated producer keeps the calendar honest and the handoffs clean.

What belongs on the web design and development requirement form

The web design and development requirement form is a two-page intake the client fills out before the discovery call. It captures business goals, primary audience, competitor examples, content summary, integration list, brand assets, hosting environment, launch date, budget band, and constraints. Every answer feeds the discovery workshop directly and speeds scoping.

Some agencies push a 20-page requirement form up front and lose the deal at page eleven. Others take a five-minute intake call and skip the paper trail. Both extremes fail. Deliver a two-page form. Follow with a 45-minute call. Together they capture 90% of the scoping signal in under two hours of client time. Any web design and development requirement form that takes longer than two hours to fill is signaling process theater, not real discovery.

Business goals section on the form

The business goals section captures three answers. What does the site need to do more of. What does it need to do less of. What does success look like in twelve months in a real measurable number. Vague answers here forecast vague scope. Concrete answers here forecast tight scope. Any requirement form that skips the measurable success question is going to hit month six with no way to prove the build worked.

Integration list section on the form

The integration list captures every third-party system the site needs to talk to. CRM. Email platform. Payment processor. Booking tool. Analytics stack. Search. Live chat. Every integration adds days to the back-end sprint. A form that lists 12 integrations forecasts a build that runs three weeks longer than a form that lists three integrations. Better to know at intake than to discover at week nine.

Start your own web design and development process the right way

Start with the requirement form and the discovery call. Those two together tell you the scope, the team size, the timeline, and the budget band. From there you can plan the six phases in real detail. Any project that starts with a Figma prototype before the requirement form is a project that will be redesigned at week nine. Any project that starts with the requirement form and a discovery workshop stays inside the scope from day one.

When you are ready to scope the real build, our web design and development services covers the full stack from discovery through retainer. If your scope calls for a WordPress-specific build, see our WordPress website development services. For fixed-scope small-business builds, our website design packages map the small-team tier. For deeper reading on how design and code roles split, see our post on web design vs web development, and on how to pick a partner, our post on how to choose a web design and development company. For member-driven site work, see our association and nonprofit web design and development post for the added phases that pattern adds.