Corporate Website Design Stages: Timeline and Owners

Most disputes on a website project start with one sentence: “The site is ready.” The vendor shows the homepage, but the client hasn't seen the forms, the service copy or admin access yet. Define the corporate website design stages with a clear output and owner from day one, and that misunderstanding never happens. The short answer is this: every stage has a reviewable output and someone who signs it off. How long each stage takes depends on whether its prerequisites are ready.

As a project manager, I spend most of my time on exactly these boundaries: where one stage ends and who has to accept it. That's why I've written this guide as a map. Before you sign a contract, walk through the corporate website design stages with your vendor using it.

What are the corporate website design stages, and what does each one produce?

In brief, the corporate website design stages are discovery, page architecture, interface design, development, content entry and testing, and finally training and handover. Their outputs are, in order, a scope document, a sitemap, an approved design, a working build, a test report and a handover package. But moving to the next stage isn't only about finishing the work. A named person has to approve the output, and the next stage's prerequisites have to be ready.

So think of the corporate website design process as a chain of outputs, not a list of activities. “We're working on the design” can't be reviewed. “The mobile design for the services page has been sent for approval” can be seen, assessed and accepted.

Say the director of a trading company sees the desktop homepage on the test environment and assumes the job is done. At that very moment, the contact form might not be connected to any email address. Half the pages might still hold placeholder text, and no one at the company might have an admin login. A beautiful page means one intermediate output is ready. It doesn't mean the whole site is.

My suggestion is to make this table the basis of your kickoff meeting and your shared map of the corporate website design stages. Fill in the last column with people's names, not something generic like “the marketing department.” When approval belongs to a department, it effectively belongs to no one.

What information should be ready before you start?

Before the corporate website design stages formally begin, five things need to be clear: the site's goal, its main audience, your key services, what you want visitors to do and who makes the final call. A good vendor will ask about all of these in the first meeting. If they don't, bring them up yourself.

At this point, ordering a corporate website usually comes down to four simple steps:

1. You send a brief describing what you need

2. You receive and review the vendor's proposal

3. Both sides agree on scope and each other's commitments

4. The project formally starts with a kickoff meeting

At the same time, go through your assets, because the technical team will need them in the first few weeks:

• Your logo as a high-quality file

• Colour and font guidelines, if you have them

• Images you have the rights to use

• Service descriptions, even as drafts

• Contact details and an exact address

• Domain and hosting status: whose name is it under, and who holds the access?

Not all of this has to be complete on day one. You can start a project without all the copy. Still, for each missing item, write down an owner and a delivery date. What really holds a project back is having no content structure and no one responsible for it.

If several managers at your company weigh in, appoint one representative. Suppose the sales director wants green and the CEO wants blue. That disagreement needs to be settled inside the company, and only one consolidated piece of feedback should reach the team. Otherwise the design team gets stuck between two contradicting messages, and every review round is wasted.

Discovery and locking down the project scope

Discovery is the first of the corporate website design stages, and everything else is built on its output. The project scope is a clear list of what's inside the agreement and what stays outside it. There's one point people usually miss, though: the number of pages isn't the same as the number of page templates.

For example, ten service pages with the same structure count as one template. But the homepage, the contact page and the careers page are each separate templates. Every template needs its own design and testing time, so an estimate that only counts pages is off from the start.

The project manager runs this stage, working with the technical team. The scope document is approved by someone on your side who actually has decision-making authority. Why do I stress authority so much? Because approval from a specialist whose manager later changes their mind isn't really approval.

The output of this stage is a document that covers at least the following:

• A list of pages and the main templates

• Features, such as forms, search or a news section

• The site's languages

• Connections to other systems

• Who is responsible for producing content

• How many review rounds each stage includes

• Acceptance criteria for each feature

The test for moving on is simple: every feature needs a scenario you can actually test. “Partnership enquiry form” isn't enough. Write down which email address the form goes to after submission, which fields are required and what message appears if the phone number is incomplete.

Also spell out what's outside the agreement. Translation, photography, video production or connecting to a new system are out of scope if the document doesn't mention them. This is also where you define the difference between a “defect fix” and a “new request.” A defect fix means something that was agreed isn't working properly; a new request means something that was never agreed. You'll lean on these two definitions again and again through the rest of the corporate website design stages.

We cover the contractual details of this part in our guide to writing a professional website design contract. And if you want to know how each feature affects cost, see budgeting for a corporate website design.

Page architecture and the content preparation plan

Page architecture means how pages are arranged and linked so visitors can find what they need easily. At this stage we usually sketch a simple first layout, a wireframe. It's black and white and only shows where elements go; there's no colour or typography yet.

Among all the corporate website design stages, this is the cheapest place to make changes. Moving a section in a wireframe takes a few minutes. The same change after development might take several days.

The UX designer owns the structure. Content, however, is owned on your side: you prepare the copy and images as agreed. A designer can't explain on your behalf exactly what value your company's services bring to customers.

The output of this stage is the sitemap, the main templates and a content inventory. Keep the content inventory as a simple table:

Judge approval from the visitor's point of view. Someone landing on a service page should find the information they need and a way to get in touch. A page without a clear purpose should be removed or merged into another page.

That's why you should separate two kinds of page. A services overview page only needs a few lines of introduction and a link to each service. A single service page, on the other hand, should show the customer's problem, how you work, a sample output and a request button. I'd suggest preparing the real copy for one of these representative pages early; a design tested with real text holds fewer surprises.

Content preparation can run in parallel with design. Still, keep one risk in mind. If a page's copy doubles in length after the design is approved, its layout may have to change too.

Interface design and mobile sign-off

The user interface (UI) is the part of the site you see and interact with: colours, type, buttons and menus. Responsive design means the page layout adapts itself to the screen size. On corporate sites a large share of visits come from mobile, so the mobile version is not an afterthought.

The UI designer owns this stage's output. You check that the design fits your brand, and the technical team checks that it can be built. Don't underestimate that technical check; an effect that looks lovely in a mockup can slow the site down once it's built.

The output includes designs for representative pages on mobile and on large screens. The open and closed states of the menu, the form layouts and the error messages should be designed too. An error message seems like a minor detail, right up until the day a user can't work out why their form didn't go through.

The criteria for moving on are these: text reads comfortably on mobile, information appears in a logical order and the contact button is visible straight away. Long content shouldn't break the layout either, so try two-line headings and long service names in the design itself.

In fact, this is where the quality of your feedback affects the project timeline more than anywhere else in the corporate website design stages. No designer can act precisely on “make the design more attractive.” But “the request button can't be found on mobile” points to the problem and leaves the solution to the specialist.

Vague feedback burns time; precise feedback solves the problem.

A common mistake also happens here: don't treat approval of the homepage mockup as approval of every template. And the number of review rounds, plus how approvals are recorded, for instance a written message in the project channel, should be settled in advance.

Development and connecting the agreed features

In development, the technical team turns the design into pages and features that actually work. This happens on a staging environment, a version of the site that's only available to you for review before it goes public.

The development team does the work, and the project manager tracks whether it matches the scope. Your part is to provide the necessary access securely. For example, don't send your hosting password in a general messaging group; create a separate account with limited permissions.

A page opening without visible errors isn't enough. The output of this stage is a staging version with a content management panel, working forms, access roles and the agreed integrations. So the test for moving on is running the main scenarios with test data.

Suppose the enquiry form is meant to feed straight into a customer relationship management system (CRM). Three prerequisites here are outside the development team's control: the integration documentation, test access and responsive support from that system's provider. That's why the first question I usually ask at kickoff is who the third party's technical contact is.

So it makes sense to move independent tasks forward in parallel, such as building the admin panel alongside designing secondary pages. Building a feature that depends on an unapproved design, though, risks rework. Sometimes it's worth it to make up time; just make that decision knowingly and record the risk.

Content entry and pre-launch testing

First, be clear about who enters the content into the site; this should be in the contract. The QA team is responsible for testing. But the accuracy of the information, from phone numbers to service names, is down to your representative. How would the technical team know your head office moved last year?

The output of this stage is pages with final content, a defect list and a retest report after fixes. These are the minimum tests we run in the corporate website design stages before launch:

• Forms, from submission to the message arriving at its destination

• All internal and external links

• Display on several mobile screen sizes

• Correct text direction for text, numbers and tables

• Access levels in the admin panel

• Downloadable files, such as catalogues, actually opening

Accessibility means the site is usable by people with different abilities. A few simple checks go a long way: moving through a form using only the keyboard, every field having a label and enough contrast between text and background. For more precise criteria, the web accessibility standards resources are a reliable reference.

Not all defects carry the same weight. A blocking defect stops the launch, such as customer enquiries not arriving. A low-risk fix, like a small change to a button colour, can be done after launch. So separate the two in your test report, so a critical defect doesn't get lost behind ten cosmetic issues.

A beautiful site that loses customer enquiries is not ready to launch.

Next, check the settings that affect visibility in search engines. If you're redesigning an existing site, old page URLs must redirect to the new pages. A backup and a way to roll back to the previous version should also be ready before launch.

We've put the full list in pre-launch technical SEO checks for corporate websites. You can find the official details in the technical documentation on site presence in Google Search.

Training, handover and the start of support

Don't mix up three events: technical handover, client approval and public launch. The technical team might hand over on Monday, you approve on Wednesday and the launch slips to the following week. So put each one in the plan separately.

The project manager prepares the handover package with help from the technical team. Your representative records receipt of each item and final acceptance. The handover package, the last output of the corporate website design stages, usually includes:

• A content management guide

• A training session for your content owner

• The agreed access credentials

• Domain and hosting ownership status

• Design files and licences for fonts and images

• A backup

• Signed handover minutes

Measure training with a small test. Your content owner should edit a page and replace an image in front of the team. If they can't, training isn't finished; just holding a session doesn't count.

Support should be contractual, not verbal. Put the start date, the channel for logging issues, response hours and the difference between a defect fix and new development in writing. Agree the length and level of support separately for each project.

Also settle one point that's often forgotten: who tests the forms and checks the site's status right after it's moved to production? The first hours after launch are the most sensitive hours of the project.

How is the timeline for a corporate website estimated?

Four things determine how long a corporate website takes: the scope, the team's capacity, dependencies and the time spent waiting for approvals. That's why, when someone asks “How long does a corporate website take?”, a single fixed number for every site isn't the right answer.

First, separate effort from calendar time. Designing one page might be two days of work. But if your feedback arrives a week later, those same two days of work stretch over roughly ten days.

The other concept is the critical path: the chain of tasks where any delay moves the end date. On most corporate sites this path runs straight through the corporate website design stages: scope approval, template design approval, development and testing. Content usually sits on this path too, even when no one's paying attention to it.

That's why simply adding up the time for all the corporate website design stages is usually misleading. A simpler, more realistic model looks like this:

1. List the prerequisites and write down when each one will be received.

2. Line up dependent tasks one after another.

3. Place independent tasks alongside them in parallel.

4. Set a review deadline for each approval point.

5. Build in a time buffer for post-testing fixes.

Ask the vendor one key question: does the start date count from contract signing or from receiving the prerequisites? The answer can shift the delivery date of a corporate website noticeably.

A few other factors add time: designing from scratch, multiple languages and integrations with external systems. Using ready-made components cuts design time but also limits flexibility. The exact effect of each factor can only be stated after the scope has been reviewed.

A sample timeline with clear assumptions

To make this model concrete, let's walk through an entirely hypothetical six-week scenario. This number is neither a market average nor a commitment from Niasa; it just shows how assumptions shape a plan. The hypothetical site is single-language, with 8 pages, 3 main templates and a simple contact form. There's no data migration and no external integration.

The plan's assumptions are:

• The visual identity already exists.

• The content owner is named, and final copy arrives by the end of week two.

• The client sends consolidated feedback within two working days.

• The team's capacity is reserved for this period.

• Revision rounds are limited and agreed in advance.

Notice that development in week three only starts on templates whose designs have been approved. Overlapping the corporate website design stages doesn't mean removing approval points. Take this plan's three approval points seriously: the end of week one, before each template is developed and before launch.

Now suppose the final copy arrives four days late. The total delay isn't necessarily four days. If the team builds templates that don't depend on the copy in the meantime, the impact shrinks. But if the copy turns out longer than expected and changes the design, the delay can be even greater.

Managing changes and responsibility for delays

Every change request should have four parts: a description of the change, the reason for it, its effect on time and cost, and the approver's decision. Record this agreement in writing before any work starts; a change accepted verbally ends up, a few weeks later, in a “that was supposed to be included” argument.

For example, suppose that after the design is approved you decide the site needs an English version too. That's not just translation. The layout has to be reviewed for left-to-right text, the content management system has to support two languages and every test has to be repeated for the second language. The further along the corporate website design stages you are, the more expensive a change like this gets.

Log delays by cause, too. Client delays on content, a vendor's inaccurate estimate and a third-party disruption are three separate issues. Don't pin responsibility on one side without evidence; that only erodes trust. Use this template to log each blocker:

If there's a dispute, the reference points are the baseline version of the plan and the dates approvals were recorded. And don't treat client silence as approval without a prior agreement. If silence is meant to count as approval after a few days, write that into the contract from the start.

Sometimes you have a fixed external deadline, like a trade show. In that case the right move is to shrink the scope of the first release, not to drop testing from the corporate website design stages. You could, for instance, push the news section to the next release. What I don't recommend is launching a site with a broken form or a half-finished services page.

What information should you send to get an accurate plan?

To get an accurate plan, send a short brief covering eight fields. Copy this template and write your answer next to each field:

Don't send passwords or sensitive access details at this stage; no vendor needs them for an initial estimate.

In return, ask the vendor for a plan that shows the start prerequisites, the owner of each output, the approval points and the parallel tasks for each of the corporate website design stages. It should also state the conditions under which the plan will be re-estimated. A plan that only has an end date isn't a plan yet.

If you'd like to go through this brief with us, the Niasa corporate website design services page is the place to start. We review your brief, ask questions about scope and prerequisites, and then present a proposed delivery plan along with its assumptions. The final plan still depends on that review and on agreeing the scope.

Your next step is simple: fill in the eight fields above, name your final decision-maker and send us the project brief. The clearer that brief is, the more realistic the plan you'll get for your corporate website design stages.