By Mehdi HassanMany descriptions of the website design process put copywriting near the end, somewhere between "development" and "content population". That single ordering decision causes a lot of avoidable rework. This guide walks through the seven stages we use, what each one produces, how to give feedback at each stage, and why the words come second, right after discovery. If you're a startup planning a new site, read it alongside our guide to website design and development for startups.
What is the website design process?
The website design process is the sequence of stages that takes a website from an idea to a live, working site: research, writing, structure, design, build, testing and launch. A good process makes each stage produce something concrete that the next stage depends on.
The point of a process isn't ceremony. It's to make decisions in the order that keeps them cheap. Changing a sentence in a document takes a minute. Changing it after it's been designed takes an hour. Changing it after it's been built, tested and launched can take a day. A well-ordered process front-loads the decisions that affect everything else, especially who the site is for and what it says, so later stages are mostly execution.
Make expensive decisions while they're still cheap.
What are the 7 stages of the website design process?
The seven website design stages are discovery, messaging and copy, structure and wireframes, visual design, development, QA and launch preparation, and launch and post-launch. Each one has a clear deliverable.
Stage | Main question | Deliverable you approve |
|---|---|---|
1. Discovery | Who is this for, and what must the site do? | Discovery summary, goals, sitemap draft |
2. Messaging and copy | What does each page say? | Copy document for every page |
3. Structure and wireframes | How is each page organized? | Wireframes built from the real copy |
4. Visual design | How does it look and feel? | Desktop and mobile designs, component library |
5. Development | How is it built and edited? | Working site on a staging environment, CMS |
6. QA and launch prep | Does everything work everywhere? | Tested site, redirect map, tracking checks |
7. Launch and after | Is it live, and is it improving? | Live site, handover, 90-day plan |
Many agencies describe similar phases. Where processes differ is in when copy happens and what each stage hands to the next. For a client-side view of the same journey, see what happens in a web design project from kickoff to launch.
What happens in the website discovery phase?
The discovery phase defines who the site is for, what it must achieve and what already exists. It ends with a short written summary that every later decision can be checked against.
Discovery covers the business and product, the primary and secondary buyers, the main action the site should drive, the current site's content and performance, competitors and the technical requirements. For a redesign, it includes a content audit: which pages get traffic, which convert and which can go. Our website content audit template shows how to run one.
- Inputs: sales call notes, customer interviews, analytics access, brand files, the current sitemap.
- Outputs: a discovery summary, a draft sitemap, page goals and a list of technical requirements.
- The decision it settles: who the site is for and what each page must prove.
Skipping discovery doesn't save time; it moves the questions to later stages, where answering them costs more. Our guide to the website discovery phase lists the questions and explains why this stage saves money.
Why does copy come at stage two of the process?
Copy comes at stage two because the words decide the structure of every page. When the message is written before wireframes, layouts are built around what the page actually needs to say, so they don't break when real copy arrives.
In many processes, design uses placeholder text and copy arrives at stage five or six. The real headline is twice as long as the box drawn for it, a key feature needs a diagram that has no slot, and a whole section turns out to be unnecessary. The design gets reworked, the build gets delayed, and the copy gets cut to fit. Writing first removes that loop. It also forces the hard decisions, like what you're claiming and what proof you have, to happen early, when they're cheap.
Stage two produces a copy document with headlines, section claims, body copy, calls to action and FAQs for every page. It doesn't have to be final polish, but it has to be real words with real lengths. Who writes it is its own decision; we compare the options in who should write your website copy.
How do wireframes and visual design work in the process?
Wireframes turn the approved copy into page structure, and visual design gives that structure its look. Wireframes answer what goes where; visual design answers how it feels and reads.
Stage 3: structure and wireframes
Each section of the copy doc becomes a block on the page, sized for its actual words and proof. Missing proof shows up as an empty slot, which is far better to discover now than after design. Wireframes also set the navigation and the path from each page to the next action. Keep them simple and grey, so feedback stays on structure and not on color.
Stage 4: visual design
Visual design applies the brand: typography, color, imagery, spacing and motion. It produces desktop and mobile designs for every page, plus a component library so new pages reuse the same parts. This is also where accessibility is designed in rather than fixed later, with color contrast, focus states and readable type sizes, as covered in our accessible design basics. Interaction details, like the micro-interactions that make a site feel premium, get specified here so the build can include them.
How to give feedback on wireframes versus designs
On wireframes, comment on order, emphasis and missing content: whether the most important claim is high enough, whether a section needs proof, whether a buyer would know what to do next. Avoid comments on color or fonts, because they aren't decided yet.
On visual designs, comment on whether the design makes the message clearer, whether anything feels off-brand, and whether the mobile version holds up. Describe the problem rather than prescribing the fix: "this section feels less important than it is" helps more than "make it blue". Our guide to giving website design feedback has more examples.
What happens in the development stage?
In the development stage, the approved designs become a working website on a staging environment, with a CMS your team can edit, forms connected, tracking in place and performance checked.
Development is more than translating mockups into code. The developer decides how the content is modeled in the CMS, which parts are editable, how components are reused, how pages render for search engines and AI crawlers, and how fast it loads on a real phone. The platform matters here: a visual builder like Framer or Webflow suits teams that want to edit visually, while a coded build in Next.js suits sites with custom data or integrations. If you're weighing a move between them, our breakdown of Framer to Next.js migration cost covers what changes.
Everything is built and reviewed on staging first, never on the live site. Our guide to website staging environments explains why that matters and how to use one well. This stage ends with a working staging site you can click through on your own devices.
What happens in QA and launch preparation?
QA and launch preparation check that everything works across devices and browsers, that search and tracking are set up correctly, and that nothing from the old site gets lost. It's the stage most often rushed, and the one whose mistakes are most visible.
Functional testing
Every link, form, button and interactive element on every page, on real phones and desktop browsers.
Content check
Final copy in place, no placeholder text, images with alt text, legal pages live.
Search setup
Page titles, meta descriptions, a sitemap, headings in order and structured data where it helps, such as an FAQ section with schema.
Redirects
For a redesign, every old URL with traffic or links mapped to its new home and tested.
Tracking
Analytics and conversion events firing correctly, with consent settings tested so data isn't silently dropped.
Performance and accessibility
Speed on a mid-range phone and keyboard navigation through every page.
Our website QA testing guide explains how to test properly, and the website launch checklist gives you 50 items to tick before going live.
What happens at launch and after the website goes live?
At launch, the site goes live, the redirects switch on and the team checks that search engines can crawl it. After launch, the first weeks are for fixing issues, watching data and planning the first improvements.
Launch day itself should be boring: a planned switch, a short list of checks and someone watching for errors. The handover happens around the same time, with accounts and source files confirmed in your name and a recorded CMS walkthrough for your team. The more important work starts afterwards. Watch search console for crawl errors, check that conversions are recording, and collect what sales and support hear about the new site. Our guide to the first 90 days after launch breaks that period into weekly priorities.
Some teams keep improving the site through an ongoing arrangement rather than one-off projects. If that's you, a web design subscription or retainer model covers continuous design and development; ours is $6,000 a month.
How long does the website design process take?
The website design process takes as long as its decisions take. Page count, who writes the copy, how fast feedback comes back and whether there's a migration affect the timeline far more than design or build effort.
A single focused page can move through every stage in a short sprint when the brief is clear and one decision-maker reviews daily. A multi-page site takes longer because each stage has more to approve. Migrations add work for content import, redirects and SEO checks. We don't quote a fixed duration for full websites before scoping; we agree the timeline on the intro call once the page count and content are clear.
Factor | Speeds the process up | Slows it down |
|---|---|---|
Decision-maker | One person with authority, reviewing quickly | A committee with conflicting priorities |
Copy | Written early by the team designing the site | Arriving after design approval |
Content and assets | Ready at kickoff | Gathered during the build |
Scope | Locked page list with a change process | New pages added informally |
Migration | None, or planned from discovery | Discovered late, with no redirect map |
How do you keep a website project on track?
Keep a website project on track by locking each stage before starting the next, naming one decision-maker, and handling new requests through a clear change process instead of informal additions.
Most projects that run over budget don't fail in one big moment; they drift through small additions that nobody priced. A new section here, an extra page there, a direction change after designs are approved. Our guide to change orders and scope creep covers how to keep the grey area small. The other lever is feedback quality: specific, consolidated feedback from one person moves a project faster than scattered comments from many.
