Web Design Process: Complete Guide From Discovery to Launch

What the typical "7-step" guides get wrong about the web design process

If you search for "web design process," you'll find dozens of articles breaking it down into seven steps, nine steps, or sometimes eleven steps, each with clean diagrams and tidy phase names that suggest building websites is a linear march from discovery to launch. Digital Silk has their seven-step version with strategy, planning, UX/UI, style guide, development, QA, and maintenance. Source: Digital Silk Web Design Process. Framer publishes a nine-step model that moves from brief to project plan to sitemap to design system to prototype to launch. UXPin offers an eight-step approach heavy on ideation, research, and wireframing. Source: UXPin Design Process. These guides aren't wrong exactly, but they're incomplete in a way that matters enormously when you're actually trying to ship client websites on time and on budget.

Here's what I've learned after running this process with more clients than I can count: the phases themselves are not the hard part. Anyone can list the phases. The hard part is what happens between phases, specifically how feedback gets collected, how approvals get made, and how scope gets controlled when stakeholders inevitably change their minds halfway through the project. Most web design process guides mention feedback as a bullet point somewhere in the middle, as if it's a minor administrative task rather than the single biggest variable in whether your project ships in two weeks or drags for two months. This guide is going to fix that gap by treating feedback and approvals as a system that runs through every phase, not as an afterthought you figure out when problems arise.

The web design process I'm going to walk you through has eight phases, which is consistent with what you'll find elsewhere, but with one crucial addition: every phase ends with a concrete deliverable and an explicit approval gate. The deliverable is something you can actually show someone and get a yes or no on. The approval gate is the moment when the client signs off on that specific phase, which gives you permission to move forward and protection if they try to reopen decisions later. Without these gates, you're not running a process; you're running a suggestion box where anyone can change anything at any time, and that's how projects die.

[IMAGE: Process comparison - prompt: "Side by side: 'typical process guide' showing linear steps vs 'real process' showing phases with approval gates and feedback loops"]

Phase 1: Discovery and goals

Discovery is where most agencies either set themselves up for success or create problems they'll spend the entire project solving. The purpose of this phase is to eliminate guesswork by defining what the website is for, who it's for, and what success looks like in terms that everyone can agree on and measure. You're not designing anything yet. You're not wireframing. You're not even thinking about colors or typography. You're having conversations that establish the foundation everything else will be built on, and if you skip this phase or rush through it, every decision downstream becomes an argument because there's no shared understanding to reference.

I've seen agencies lose months to scope creep that started in discovery, usually because they failed to document the boundaries of what was included and what wasn't. The client assumed the project included a blog migration, an e-commerce integration, and custom animations on every page because nobody explicitly said it didn't. The agency assumed those things would be separate phases or change orders because they weren't in the original conversation. Neither side was lying or acting in bad faith; they just hadn't done the work of writing down what "the website" actually meant. Discovery is where you do that work, and the deliverable is a written brief that captures goals, audience, constraints, key pages, technical requirements, and a clear definition of what "done" means for this specific project.

Discovery deliverables:

• Project brief with goals and success metrics
• Target audience definition
• Page inventory (what pages exist or will exist)
• Scope boundaries (what's included and explicitly excluded)
• Approval authority map (who signs off on what)
• Timeline with milestone dates

The approval gate: The client signs off on the brief. Not on designs, not on wireframes—just on the brief that captures what you're building. This signature matters more than any other signature in the project because it's what you'll reference every time someone asks for something that wasn't in the original plan. Get the brief signed before you move to research.

Phase 2: Research and strategy

Research is where you test everything you learned in discovery against reality. The client told you who their audience is, but do you actually understand how that audience behaves online, what competitors are doing well, and what positioning opportunities exist? The client has ideas about what pages they need, but have you validated that structure against SEO research, user journey analysis, and conversion best practices? This phase exists to catch the gap between what clients think they need and what will actually work, and to surface those gaps early enough that you can address them without redesigning things later.

The biggest mistake I see agencies make in research is treating it as an internal-only phase that clients don't participate in. They do all their research, develop recommendations, and then present a strategy document that the client has never seen before, hoping the client will trust their expertise and approve everything. Sometimes this works, but often the client pushes back on recommendations that contradict their assumptions, and now you're in an argument about strategy when you should be moving into information architecture. The fix is to involve clients in research by sharing findings incrementally, discussing tradeoffs together, and building the strategy collaboratively rather than presenting it as a fait accompli.

Research deliverables:

• Competitive analysis (what competitors do well and poorly)
• SEO keyword research (what terms to target)
• User journey mapping (how visitors move toward conversion)
• Content audit (what exists, what's missing, what needs updating)
• Technical requirements document (integrations, CMS needs, hosting)
• Strategy summary with recommendations

The approval gate: The client signs off on the strategy document, which locks in the direction for everything that follows. If they want to change strategy after this point, that's a new engagement, not a revision to the current one.

[IMAGE: Research phase - prompt: "Diagram showing inputs (client assumptions, competitor data, keyword research) flowing into strategy document"]

Phase 3: Information architecture

Information architecture is where you turn goals and strategy into structure. You're deciding what pages exist, how they relate to each other, what each page is responsible for, and how users will navigate between them. This is arguably the most underrated phase in the entire process because when it goes wrong, everything that follows goes wrong with it. I've seen beautiful designs fail because the underlying architecture was confused, and I've seen simple designs succeed because the structure was so clear that users never had to think about where to go next.

The primary deliverable for this phase is a sitemap that shows every page, its place in the hierarchy, and its relationships to other pages. But a sitemap alone isn't enough. You also need to document what each page is supposed to accomplish: is this page meant to educate, convert, reassure, or route people to other pages? When you define page roles explicitly, you prevent the common problem of pages that try to do too many things at once and end up doing none of them well. The homepage that tries to be a product page, a blog index, a company story, and a conversion funnel simultaneously is a homepage that converts nobody because it overwhelms everyone.

Architecture deliverables:

• Visual sitemap showing all pages and hierarchy
• Page role definitions (purpose of each page)
• Navigation structure (primary nav, footer nav, utility nav)
• URL structure plan
• Content requirements per page (what content each page needs)

The approval gate: The client approves the sitemap and page roles. This is the last point where major structural changes are cheap. After this phase, changing the fundamental architecture means reworking wireframes, designs, and potentially development, which means scope discussions and timeline adjustments.

Phase 4: Wireframes

Wireframes answer the question "where does the content go and what's the order?" without getting distracted by visual style. They're deliberately ugly because their job is to focus attention on layout, hierarchy, and flow rather than colors, fonts, or imagery. When clients debate design details at the wireframe stage, that's a sign you haven't set expectations properly about what wireframes are for. The point is to agree on structure and sequence before you invest time in making things look beautiful, because it's much cheaper to move boxes around in a wireframe than to redesign a polished mockup.

I've watched projects go sideways because agencies showed high-fidelity mockups before getting wireframe approval, and the client focused entirely on visual details while ignoring fundamental layout problems. They approved designs that looked great but didn't work because nobody ever agreed on where the content should go or how users would navigate through it. The wireframe phase exists specifically to prevent this by separating the "what goes where" conversation from the "what does it look like" conversation. These are different discussions, and mixing them together creates confusion that slows everything down.

Wireframe deliverables:

• Low-fidelity wireframes for core page templates
• Annotated user flows showing navigation paths
• Mobile wireframes (not just desktop scaled down)
• Content placement specifications
• Interactive prototype (optional but recommended)

The approval gate: The client signs off on wireframes, which locks in layout and content hierarchy. After this point, moving sections around or adding new content blocks is a change request, not a revision.

[IMAGE: Wireframe example - prompt: "Side-by-side wireframe and final design showing how wireframe structure translates to finished page"]

Phase 5: Visual design system

The visual design system phase is where you define the reusable rules that will govern every page: typography scale, spacing system, color roles, component styles, and interaction states. Most guides just call this "design," but I think that undersells what's actually happening. You're not just designing a homepage mockup; you're creating a system of rules that can be applied consistently across dozens of pages. Teams that skip the system and go straight to mockups end up with inconsistent styling that feels "off" even when nobody can articulate exactly what's wrong, and they spend the rest of the project chasing consistency problems that a design system would have prevented.

The deliverable for this phase has two parts: a small style guide documenting the design tokens and component patterns, and a high-fidelity mockup of at least one key page (usually the homepage) that demonstrates the system in action. The style guide ensures developers can implement the design consistently without asking clarifying questions about every button state and spacing value. The mockup gives the client something concrete to approve, which is important because abstract style guides don't generate the same emotional response as seeing their brand actually applied to a real page.

Understanding web design principles makes this phase much more productive, because you can articulate why specific design choices work rather than defending them based on subjective preference.

Design system deliverables:

• Typography scale (heading sizes, body text, captions)
• Color palette with semantic roles (primary, secondary, accent, error, success)
• Spacing system (consistent increments for padding and margins)
• Component library (buttons, forms, cards, navigation patterns)
• High-fidelity mockups of key pages
• Responsive breakpoint specifications

The approval gate: The client approves both the style guide and the key page mockups. This is the point where major visual direction changes become expensive, so make sure the client understands that approving the design system is approving the overall look and feel, not just one page.

Phase 6: Development

Development is where approved designs become a real website. The deliverable isn't just "code exists"; it's a staging environment that behaves like production and contains real content, not placeholder text. I cannot emphasize this enough: if you build with lorem ipsum because the client hasn't delivered their content yet, you will redesign after real content lands. Headlines that were six words become twelve words. Paragraphs that fit perfectly in the design become walls of text that break the layout. Product descriptions that were supposed to be three sentences become seven sentences plus a bullet list. Build with real content or don't build at all.

This phase is where feedback tools become critically important because now clients are reviewing a working website rather than static mockups, and their feedback will be more detailed and more frequent. If you're collecting feedback via email, you're going to spend more time translating "the thing on the left looks weird" into actionable tasks than actually implementing changes. A visual feedback tool that lets clients pin comments directly on the staging site eliminates that translation work entirely and keeps all feedback in one place where nothing gets lost. We talk about this extensively at website feedback tool if you want to understand how to set up the feedback layer properly.

Development deliverables:

• Staging site with real content
• CMS configuration (if applicable)
• Form functionality
• Third-party integrations
• Responsive implementation across breakpoints
• Performance optimization

The approval gate: Internal team sign-off that the build matches the approved design system and templates. This is not the same as client approval; this is your team verifying that you've built what was designed before you expose it to client feedback.

[IMAGE: Development phase - prompt: "Screenshot of staging site with visual feedback pins showing client comments attached to specific elements"]

Phase 7: QA and UAT

Quality assurance is where teams think they're doing "a last check" when they should be running a systematic checklist. The difference matters because "checking" is passive and subjective, while "running a checklist" is active and repeatable. I've seen agencies ship sites with broken forms, dead links, and layout bugs on mobile because their QA was "someone looked at it and thought it was fine" rather than "someone tested every form submission, clicked every link, and viewed every page at every breakpoint."

The QA checklist every project should run:

• Verify all forms submit correctly and trigger expected notifications
• Click every internal link and confirm there are no 404s
• Test at mobile, tablet, and desktop breakpoints on actual devices
• Check performance on a real 4G connection
• Verify images are properly compressed and optimized
• Confirm tracking codes are installed and firing correctly
• Test redirects from old URLs (if migrating from existing site)
• Test authentication flows or password-protected sections
• Verify SSL certificate is properly configured
• Test in multiple browsers (Chrome, Safari, Firefox, Edge)

User acceptance testing is where the client reviews the staging site and provides feedback on anything that doesn't match their expectations. This is the most dangerous phase for scope creep because now the site is real and clickable, and clients suddenly have opinions about things they never mentioned during wireframes or design approval. The key to surviving UAT is setting clear expectations: the scope of UAT is "broken or inconsistent," not "I changed my mind." If they're reporting bugs or inconsistencies with approved designs, those are legitimate UAT issues. If they're requesting new features or different layouts than what was approved, those are change requests that need to be scoped and scheduled separately.

QA/UAT deliverables:

• Completed QA checklist with all items verified
• Bug log with issues found and resolved
• UAT feedback consolidated and addressed
• Final client approval for launch

The approval gate: Go/no-go decision from both the internal team and the client. Is the site ready to launch?

Phase 8: Launch and post-launch

Launch is a controlled release, not a magic finish line. The deliverables include final deployment to production, DNS configuration, SSL verification, analytics confirmation, and a handover document that explains how the client can make basic content updates. But launch is also day one of iteration, not the end of the project, and the healthiest teams treat it that way by creating a post-launch backlog of improvements that were discovered during the project but intentionally deferred to hit the launch date.

Launch deliverables:

• Production deployment
• DNS and SSL configuration
• Analytics verification
• Handover documentation
• Training session (if applicable)
• Post-launch backlog of deferred improvements

Post-launch protocol (first 48 hours):

• Monitor server performance and uptime
• Check analytics are tracking correctly
• Verify forms are submitting in production
• Confirm email notifications are working
• Check site appears correctly in Google Search Console
• Monitor for any user-reported issues

The approval gate: Formal launch confirmation, followed by a post-launch review meeting within 1-2 weeks to assess performance and prioritize the improvement backlog.

The missing chapter: how feedback actually works across phases

Most web design process guides treat feedback as something that happens during QA when the client reviews the staging site. In reality, feedback is a system that runs through every phase, and getting it wrong at any point creates problems that compound downstream. Here's how I think about feedback across the process:

Discovery feedback is about confirming understanding. "Did I capture what you meant? Did I miss anything important?" The goal is accuracy, not perfection.

Research feedback is about validating direction. "Do these findings align with your experience? Do these recommendations make sense?" The goal is buy-in before strategy is locked.

Architecture feedback is about structure validation. "Does this sitemap reflect what you want to build? Are the page roles correct?" The goal is agreement on what exists.

Wireframe feedback is about layout approval. "Is this hierarchy correct? Is this the right flow?" The goal is structural sign-off before visual design.

Design feedback is about aesthetic approval. "Is this the look and feel you want? Does this represent your brand?" The goal is visual direction lock.

Development feedback is about bug identification. "Is this broken? Is this inconsistent with what was approved?" The goal is catching issues, not reopening decisions.

QA feedback is about final polish. "Is everything working correctly? Is this ready to launch?" The goal is go/no-go confirmation.

Each type of feedback has different rules for what's in scope and how quickly you need to respond. The biggest mistake is treating all feedback the same way, which either means you're too responsive early in the project (making changes before they're necessary) or not responsive enough late in the project (dismissing legitimate issues as out of scope). For the operational implementation of feedback rounds with deadlines and scope boundaries, see web design workflow.

[IMAGE: Feedback system - prompt: "Matrix showing feedback types by phase: what's in scope, who provides it, expected turnaround time"]

Why phase gates prevent the most common project failures

Phase gates aren't bureaucracy—they're protection. When a client wants to change the site structure during development, you can reference the approved architecture from Phase 3 and have a productive conversation about whether the change is worth the cost. When a stakeholder joins late and wants to revisit design decisions, you can show them the approved mockups from Phase 5 and explain that reopening those decisions has timeline and budget implications. Without documented approvals, every conversation becomes a negotiation where you have no leverage.

The most common failure mode I see is the "endless revision loop" where feedback never stops arriving and approval never quite happens. The client keeps saying "just one more change" and the agency keeps accommodating because they don't have a clear mechanism for saying "this phase is complete." Phase gates create that mechanism by making approval explicit: here's the deliverable, do you approve it yes or no, and if yes we're moving to the next phase.

This doesn't mean you refuse all changes after approval. It means changes after approval are change requests with scope and timeline implications, not free revisions. The distinction matters because it creates clarity about what's included in the project and what's additional work.

Frequently asked questions

How long does the web design process take?

It depends entirely on scope, but the phases stay the same whether the timeline is two weeks or three months. A simple five-page marketing site might move through all eight phases in two to three weeks. A complex e-commerce site with hundreds of products might take three to six months. The biggest predictor of timeline isn't design complexity or development difficulty; it's how quickly decisions get made and approved. A process with clear deliverables and enforced deadlines ships faster than a process where feedback can arrive "whenever."

What are the deliverables in each phase?

Discovery produces a signed brief. Research produces a strategy summary. Architecture produces a sitemap with page roles. Wireframes produce approved layout templates. Design produces a style guide and approved high-fidelity mockup. Development produces a staging site with real content. QA produces a completed checklist and resolved issue log. Launch produces a live site, handover documentation, and post-launch backlog. If your process doesn't produce artifacts you can sign off on, it's hard to avoid rework.

What's the difference between web design process and web development process?

The design process includes discovery, strategy, architecture, wireframes, and visual design. The development process focuses on implementing those decisions in code, building features, and deploying infrastructure. In practice, these blur together, especially on smaller teams where the same people do both. But the separation matters conceptually because design decisions are cheap to change early and expensive to change late, while development decisions are more expensive overall but tend to have clearer right-or-wrong answers.

How do you handle late feedback that contradicts approved decisions?

This is where phase gates pay off. If a client approved wireframes and then wants to change the fundamental layout during QA, you have documentation showing they already signed off on that layout. The conversation shifts from "is this a good idea?" to "here's what it would cost to revisit an approved decision." You're not saying no; you're saying yes with scope and timeline implications. Teams that don't have phase gates can't have this conversation because there's no record of what was approved and when.

Can I skip phases for smaller projects?

You can compress phases, but skipping them entirely usually creates problems. A five-page site still needs discovery (what are we building?), architecture (what pages exist?), and design (what does it look like?). You might combine wireframes and design into a single phase, or do research and architecture in the same conversation, but the underlying questions still need answers. The projects that go wrong are usually the ones where someone assumed a phase wasn't necessary and then paid for that assumption later.

What's the most commonly skipped phase?

Research and strategy. Teams rush from discovery directly into wireframes because research feels like overhead when you "already know what the client wants." But the research phase is where you catch the gap between what clients think they need and what will actually work. Skipping it means you build what was requested, which isn't always what was needed, and then you have difficult conversations later about why the site isn't performing.

‍