Website Planning, Development and Launch

Introduction

A website is not simply a collection of web pages. It is a business, communication and digital marketing system through which an organisation presents its value, attracts visitors, supports customer journeys, collects data and delivers services. A successful website therefore requires more than attractive visual design. It depends on disciplined planning, clear requirements, realistic scope, appropriate technology, coordinated stakeholders, reliable content, quality assurance and continuing improvement.

Website projects commonly fail for predictable reasons: unclear objectives, uncontrolled scope, late stakeholder involvement, inadequate content preparation, unrealistic budgets, weak testing or the assumption that launch is the end of the project. A structured process reduces these risks and connects website decisions to organisational and marketing outcomes.

This chapter presents a practical process from initial requirements through development, testing, launch and maintenance. It is intended for digital marketing professionals who may manage a website project directly, work with designers and developers, or act as an informed client or vendor manager.

Learning Objectives

By the end of this chapter, you should be able to:

1. translate organisational and marketing goals into website requirements;
2. define website scope, deliverables, assumptions and constraints;
3. prepare a practical budget and allocate stakeholder responsibilities;
4. use information architecture, wireframes and prototypes to validate solutions;
5. plan content creation, migration, search optimisation and governance;
6. coordinate development and evaluate quality, accessibility, security and performance;
7. prepare and execute a controlled website launch;
8. establish maintenance, measurement and vendor-management processes; and
9. identify ethical, legal and operational risks in website projects.

1. The Website Project as a Managed System

A website project converts a strategic need into a digital service. It can be represented as a sequence of related decisions:

Business purpose → user needs → requirements → structure and prototype → content and technology → testing → launch → measurement and improvement

The sequence is not strictly linear. Testing may reveal a requirement that must be reconsidered, and analytics after launch may lead to changes in content or navigation. Nevertheless, formal stages provide control and make responsibilities visible.

A useful distinction is between project work and operational work. Project work creates or substantially changes the website. Operational work keeps it accurate, secure, available and effective after launch. Treating maintenance as an afterthought creates outdated content, security vulnerabilities and declining search visibility.

Website objectives and success measures

Objectives should describe an outcome rather than a technical activity. “Install a content management system” is an activity; “enable marketing staff to publish approved campaign pages without developer support” is an outcome.

Objectives may include:

• increasing qualified leads;
• improving online sales or bookings;
• reducing customer-service enquiries;
• strengthening brand credibility;
• providing accessible information;
• supporting recruitment or stakeholder communication; and
• improving the discoverability of products and services.

Each objective should be associated with measures. For example, a lead-generation website may monitor completed enquiry forms, qualified leads, conversion rate, cost per lead and form-abandonment rate. A website should not be judged only by page views, because high traffic may have little value if visitors are irrelevant or cannot complete important tasks.

A basic conversion rate is:

The denominator must be defined consistently. A form-conversion rate may use form-page sessions, whereas an overall website conversion rate may use users or sessions. These measures are not interchangeable.

2. Requirements Discovery and Stakeholder Analysis

Requirements gathering

Requirements state what the website must do or provide. They should be collected from evidence rather than assumptions. Common discovery methods include:

• stakeholder interviews and workshops;
• review of existing analytics and search data;
• customer surveys, interviews and usability observation;
• competitor and sector analysis;
• content audits;
• technical and security assessments; and
• analysis of customer-service questions and sales objections.

Requirements are commonly divided into four categories.

Functional requirements describe what the system does. Non-functional requirements describe how well it does it. Important non-functional requirements include accessibility, security, reliability, scalability, maintainability, privacy, browser compatibility and performance.

Requirements should be testable. “The website should be fast” is vague. “The project team will monitor agreed performance indicators on representative pages and devices before launch” is more useful, although precise targets should be established for the specific organisation and technology.

Stakeholder roles

Stakeholders include anyone who influences, uses, funds, operates or is affected by the website. They may include senior sponsors, marketing staff, content authors, sales teams, customer-service staff, information-technology personnel, legal advisers, accessibility specialists, customers and external vendors.

A RACI matrix clarifies responsibility:

• Responsible: performs the work;
• Accountable: owns the final decision or result;
• Consulted: provides relevant expertise or input; and
• Informed: receives updates.

A RACI matrix does not replace communication. It prevents a common failure in which many people provide opinions but nobody has authority to decide.

Requirements prioritisation

When time or budget is limited, requirements must be prioritised. The MoSCoW approach classifies requirements as Must have, Should have, Could have and Won’t have in this release. A “Must have” should be genuinely essential; if everything is labelled essential, prioritisation has failed.

A requirements register should record the requirement, rationale, owner, priority, acceptance criteria, dependencies and status. Acceptance criteria describe the evidence needed to regard the requirement as complete.

3. Scope, Deliverables, Budget and Schedule

Defining scope

Scope establishes the boundary of the project. It should specify:

• included page types and templates;
• target audiences and supported user journeys;
• languages and geographic markets;
• integrations, such as CRM, payment, booking or marketing platforms;
• content creation, editing and migration responsibilities;
• supported devices and browsers;
• accessibility and compliance expectations;
• training and documentation; and
• post-launch support.

The scope statement should also list exclusions. For example, a first release may exclude a mobile application, advanced personalisation or historical content that has little current value. Explicit exclusions help manage expectations.

The minimum viable website is the smallest release that delivers meaningful value while meeting essential quality, legal and operational requirements. It is not permission to launch an unsafe, inaccessible or incomplete service.

Change control

Scope creep occurs when additional work is added without corresponding adjustment to time, budget or resources. A change-control process asks:

1. What is the proposed change?
2. Why is it needed?
3. What value or risk does it address?
4. What effort, cost and dependencies does it create?
5. Which existing work will be delayed or removed?
6. Who has authority to approve it?

A signed change request and an updated decision log create an auditable record. Agile projects may manage changes through a prioritised backlog, but agility still requires prioritisation and capacity control.

Budgeting

A website budget should include more than design and development fees. Typical cost categories are discovery, project management, information architecture, user research, copywriting, photography, video, design, development, hosting, domain services, software licences, integrations, accessibility review, security testing, migration, training, analytics and post-launch support.

A simple total-cost model is:

The planning period must be stated, and recurring costs must be distinguished from one-time costs. A contingency is a reserved amount for identified uncertainty, not an unrecorded fund for uncontrolled additions. Estimates should show assumptions, such as the number of templates, pages, integrations and revision rounds.

Budget decisions should consider total cost of ownership. A low initial quote may become expensive if the organisation cannot update content, requires frequent vendor support or faces high hosting and licensing charges.

Scheduling and dependencies

A schedule should show tasks, owners, dependencies, review points and approval deadlines. Content preparation often becomes the critical path because page structures cannot be finalised without knowing what information must be presented. Other dependencies may include brand approval, legal review, data migration, API access and hosting configuration.

Milestones commonly include discovery approval, sitemap approval, prototype approval, content readiness, development completion, user acceptance testing, launch readiness and post-launch review.

4. Information Architecture, User Journeys and Prototyping

Information architecture

Information architecture organises content so that users can find, understand and act on it. It includes page hierarchy, navigation labels, categorisation, search, metadata and internal linking.

A sitemap is a structural model of the website. It should reflect user tasks and organisational priorities, not merely internal departmental divisions. Card sorting can help reveal how users group information; tree testing can assess whether users can locate items in a proposed hierarchy.

A user journey describes a sequence from need to outcome. For example:

Search result → service page → evidence or pricing → enquiry form → confirmation → sales follow-up

Mapping this journey helps identify missing information, unnecessary friction and measurement points.

Wireframes and prototypes

A wireframe represents layout and hierarchy without attempting to provide final visual polish. It allows early discussion of content priority, navigation, calls to action and responsive behaviour. A prototype may be clickable and can simulate key journeys.

Prototyping is valuable because changes are cheaper before development. It also exposes disagreements that may otherwise emerge late. However, a prototype is not proof that the final system will be technically feasible, accessible or performant. Technical feasibility and content realism must be checked.

A useful review process asks:

• Can the intended audience identify what the page is about?
• Is the primary action visible and understandable?
• Does the sequence match the user’s task?
• Are labels familiar and consistent?
• What happens on small screens and with keyboard navigation?
• Are error, empty and confirmation states represented?

5. Content Strategy and Migration

Content as a project workstream

Content should be planned alongside design and development. Each page requires a purpose, audience, owner, content type, search intent, call to action, evidence source, review date and status.

A content inventory records existing pages and attributes such as URL, title, format, traffic, backlinks, business value, accuracy and action. The audit may lead to four decisions:

• retain and improve;
• rewrite or consolidate;
• redirect to a stronger page; or
• remove when it has no continuing value.

Migration is not simply copying text into a new system. It may involve rewriting, metadata mapping, image optimisation, URL changes, redirects, document review, permissions and legal checks.

Search and structured content

Search visibility depends on relevance, usefulness, technical accessibility and trust. Digital marketers should coordinate page titles, headings, descriptions, internal links, descriptive image alternatives and structured data where appropriate. Search optimisation should not lead to keyword stuffing or content written only for algorithms.

A redirect map is essential when URLs change. It should identify old URLs, new destinations, redirect status and validation results. Broken links, duplicate pages and lost high-value URLs can damage both users’ experience and search performance.

Content governance

Governance defines who may create, review, approve, publish and retire content. It should include editorial standards, brand rules, accessibility requirements, legal review, version control, publication workflow and review frequency. Time-sensitive content should have an owner and expiry or review date.

6. Development and Technical Coordination

Development converts approved structures, content and designs into a working website. Depending on the project, it may involve a content management system, custom application, e-commerce platform, headless content system or combination of services.

The choice should reflect requirements rather than fashion. Relevant criteria include:

• content authoring and workflow;
• integration capability;
• security and update model;
• performance and scalability;
• accessibility support;
• search and metadata control;
• data portability;
• vendor dependence;
• training needs; and
• total cost of ownership.

Development should use separate environments where practical: development, testing or staging, and production. Content and configuration should be promoted through a controlled process. Access should follow least privilege, meaning each person receives only the permissions needed for their role.

Digital marketers need not write all the code, but they should understand important technical concepts. Responsive design adapts presentation to different screen sizes. A content management system separates content administration from page presentation to varying degrees. An API enables systems to exchange data. Analytics tagging records defined user interactions, but it must be implemented with privacy and consent requirements in mind.

Third-party services introduce dependencies. A payment provider, map service, customer relationship management platform or marketing tool may fail, change its interface or process personal data. Contracts and technical designs should specify ownership, service expectations, data handling, exit arrangements and fallback behaviour.

7. Quality Assurance, Accessibility, Security and Performance

Quality assurance is a planned activity, not a final visual inspection. Testing should use representative devices, browsers, content types and user journeys.

Functional and content testing

Functional testing checks links, forms, search, filters, authentication, calculations, transactions, emails and integrations. Content testing checks spelling, accuracy, headings, dates, terminology, image alternatives, downloads and legal statements. Test cases should record the expected result, actual result, evidence, severity, owner and resolution.

Defects can be classified by severity. A critical defect may prevent payment, expose confidential information or make a core service unavailable. A minor defect may involve a low-impact visual inconsistency. Severity should be based on user and business impact, not merely development effort.

Accessibility

Accessibility enables people with different abilities and technologies to use the website. Good practice includes semantic structure, keyboard operation, visible focus, sufficient contrast, descriptive link text, captions or transcripts where needed, meaningful alternative text and clear error messages. Accessibility should be tested with automated tools and human review, including keyboard and assistive-technology testing where appropriate.

Accessibility is both an ethical responsibility and, in many jurisdictions and sectors, a legal or regulatory obligation. It should be addressed during requirements, design, content creation and development rather than treated as a final compliance certificate.

Security and privacy

Security measures may include secure configuration, software updates, strong authentication, access control, encryption in transit, backups, logging, vulnerability management and incident-response planning. Personal data should be collected only for legitimate purposes, protected appropriately and retained no longer than necessary under applicable law and organisational policy.

Consent mechanisms must be understandable and should not manipulate users into accepting unnecessary tracking. Privacy notices should explain relevant processing in clear language. Marketing teams must coordinate with legal and data-protection specialists, especially when using analytics, advertising pixels, profiling or international data transfers.

Performance testing

Performance affects user experience, conversion and search visibility. Important factors include image size, font loading, script execution, server response, caching, content delivery and third-party requests. Testing should cover realistic network conditions and representative devices rather than relying only on a fast office connection.

A useful performance measure is page weight:

The units must be consistent, such as kilobytes or megabytes. The measure alone does not describe the complete user experience; a small page can still be slow if its scripts block rendering or its server responds slowly. Performance should therefore be assessed with multiple indicators and defined test conditions.

8. Launch Planning and Release Management

Launch is a controlled transition from the existing service to the new one. A launch checklist should confirm:

• business and stakeholder approval;
• content and redirect completion;
• forms, transactions and integrations;
• analytics and consent configuration;
• accessibility and security review;
• backups and rollback procedure;
• domain, hosting and certificate configuration;
• search-engine directives and sitemap submission;
• monitoring, support contacts and escalation routes; and
• staff training and communications.

A cutover plan states the sequence, timing, owners and decision points. The team should define launch criteria in advance. If a critical defect remains unresolved, postponement may be safer than release.

A rollback plan explains how to restore the previous version or disable a faulty feature. It should be tested or at least rehearsed sufficiently to be credible. After launch, the team should monitor availability, errors, forms, transactions, redirects, analytics, search indexing and customer feedback.

The first post-launch review should distinguish technical defects from expected fluctuations. A fall in traffic may result from tracking failure, indexing problems, changed URLs or genuine changes in demand; assumptions should be tested using evidence.

9. Maintenance, Measurement and Continuous Improvement

A website requires an operating model. Routine activities include software updates, backups, security monitoring, broken-link checks, content review, accessibility checks, performance monitoring, analytics governance and staff support.

A maintenance calendar can assign frequency, owner and evidence of completion:

Measurement should connect website activity to objectives. A balanced dashboard may include acquisition, engagement, conversion, service outcomes, accessibility and technical health. Data should be interpreted carefully: attribution models are imperfect, tracking may be incomplete, and correlation does not prove that a website change caused a business result.

Improvement can use a controlled cycle: identify a problem, form a hypothesis, make a change, measure the result and decide whether to retain, revise or reverse it. A/B testing may be appropriate where traffic, governance and experimental design are adequate. It should not be used to test changes that create unacceptable legal, accessibility or user risks.

10. Vendor and Project Management

External vendors may provide strategy, design, development, hosting, content or specialist testing. Vendor selection should consider relevant experience, accessibility capability, security practice, communication, references, technical approach, documentation and ability to support the organisation after launch.

A strong statement of work defines deliverables, acceptance criteria, milestones, assumptions, dependencies, review rounds, intellectual-property ownership, data protection, confidentiality, warranty, support, service levels and termination or transition arrangements. Payment should be connected to verifiable milestones rather than vague claims of progress.

The client organisation must retain strategic ownership. A vendor can recommend a platform, but the organisation should understand why it is suitable, how data can be exported and what happens if the relationship ends. Avoiding vendor lock-in is particularly important for domains, content, analytics data, design assets and customer information.

Project governance should include a regular status report covering accomplishments, upcoming work, risks, decisions required, budget, schedule and issues. Risk registers should identify probability, impact, mitigation, owner and status. Good governance is not bureaucracy for its own sake; it creates timely visibility and supports informed decisions.

Applied Case: Illustrative Website Relaunch for a Training Provider

Background

A fictional professional training provider had an outdated website with duplicated course pages, an unclear enquiry process and poor mobile usability. Marketing staff could not update pages without vendor assistance. The organisation wanted to increase qualified course enquiries and reduce repetitive telephone questions.

Problem analysis

Analytics showed that many visitors reached course pages but left before submitting an enquiry. Interviews revealed that prospective students wanted to compare schedules, delivery modes, fees and entry requirements. A content audit found conflicting dates and obsolete downloadable brochures. Stakeholders also disagreed about whether the main navigation should reflect internal departments or learner tasks.

The project team established two primary objectives: improve completion of course enquiries and make essential course information easier to find. The scope included a revised information architecture, course templates, migration of priority content, enquiry integration and staff training. A mobile application and full archive migration were explicitly excluded.

Approach and solution

The team created learner journey maps and tested two navigation models with representative users. A course template was prototyped before visual design was finalised. The content team created a structured inventory and classified pages as retain, rewrite, consolidate or remove. Each course page received an owner and review date.

The project used a RACI matrix, a prioritised backlog and weekly risk reviews. Development occurred in a staging environment. Test cases covered course search, filters, enquiry forms, confirmation messages, keyboard navigation, image alternatives, redirects and analytics events. The launch plan included a redirect map, backup, rollback procedure and staff training.

Outcome

The new site provided clearer course comparison, fewer duplicate pages and a manageable publishing workflow. Post-launch monitoring identified an incorrect form notification during the first week; the issue was corrected through the agreed support process. The organisation then reviewed enquiry quality rather than relying only on traffic growth.

Learning points

The case illustrates that successful website work depends on coordinated requirements, content, structure and operations. Prototype testing reduced design risk, while content ownership and migration planning prevented the new site from reproducing old problems. The launch was treated as a controlled release, not as the completion of responsibility.

Challenges and Limitations

No website process eliminates uncertainty. Requirements may change because of regulation, market conditions or new technology. User research may involve a limited sample. Analytics may be affected by consent choices, browser restrictions or incorrect implementation. Performance results depend on devices, networks and locations. Accessibility testing cannot be reduced to an automated score, and legal compliance depends on jurisdiction and context.

Teams must therefore document assumptions, test critical risks early and avoid presenting estimates or metrics as absolute truths. Professional judgement remains necessary. The best process is proportionate: a small informational site does not need the governance of a complex financial platform, but every site needs clear ownership, quality control and a responsible maintenance plan.

Contemporary Developments and the Role of AI

Headless content systems, composable platforms, automation, personalisation and generative artificial intelligence are changing website work. AI can assist with content outlines, metadata suggestions, translation drafts, code support, test-case generation and content classification. However, generated material may contain factual errors, biased language, inaccessible phrasing, copyright risks or confidential information. Human review, source verification, privacy controls and editorial accountability remain essential.

Automation should support—not replace—requirements analysis, stakeholder judgement, accessibility review or approval. Organisations should define which data may be entered into AI tools, how outputs are checked and who remains accountable for publication. Technology should be selected because it improves a validated user or business outcome, not merely because it is fashionable.

Best-Practice Checklist

Before approving a website launch, confirm that:

1. objectives and success measures are documented;
2. audiences, journeys and requirements are understood;
3. scope, exclusions, budget and responsibilities are agreed;
4. structure and prototypes have been reviewed with appropriate users;
5. content owners, migration decisions and redirects are recorded;
6. development environments, access controls and integrations are managed;
7. functional, content, accessibility, security and performance testing is complete;
8. analytics and privacy controls are lawful and meaningful;
9. launch, rollback, support and escalation plans are ready; and
10. post-launch maintenance, measurement and improvement have named owners.

Chapter Summary

Website planning is a managed process that links organisational objectives to user needs, requirements, content, technology and measurable outcomes. Effective projects begin with discovery and stakeholder analysis, classify functional and non-functional requirements, define scope and control change. Budgets must include one-time costs, recurring costs, uncertainty and total cost of ownership.

Information architecture, user journeys, wireframes and prototypes allow teams to validate structure before expensive development. Content requires inventory, ownership, migration decisions, search consideration and governance. Development should use suitable platforms, controlled environments, secure access and documented integrations.

Quality assurance includes functional, content, accessibility, security and performance testing. Launch requires approval, monitoring, rollback and operational readiness. After launch, maintenance, analytics, governance and continuous improvement preserve value. Vendors should be managed through clear deliverables, acceptance criteria, ownership and support arrangements. Ethical, legal and privacy responsibilities apply throughout the lifecycle, including when AI tools are used.

Key Terms

Requirements: Statements of what a website must provide or achieve.

Functional requirement: A required system behaviour or capability.

Non-functional requirement: A quality or constraint requirement, such as security or accessibility.

Scope: The defined boundary of work included in a project.

Scope creep: Uncontrolled expansion of project work.

Stakeholder: A person or organisation that affects or is affected by the website.

RACI: A responsibility model identifying Responsible, Accountable, Consulted and Informed roles.

Acceptance criteria: Conditions used to judge whether a deliverable is complete.

Information architecture: The organisation and labelling of content and navigation.

User journey: The sequence of steps a user takes to achieve an outcome.

Wireframe: A simplified representation of page layout and hierarchy.

Prototype: An interactive or simulated representation used for evaluation.

Content migration: The planned transfer, revision and mapping of content to a new website.

Redirect map: A record connecting old URLs to their new destinations.

Quality assurance: Planned activities used to verify website quality.

Accessibility: The degree to which people with diverse abilities can use a website.

Page weight: The total size of resources transferred for a page.

Rollback: The process of restoring a previous version after a failed release.

Total cost of ownership: The full cost of acquiring, operating, maintaining and eventually replacing a solution.

Governance: The policies, roles, controls and decisions that guide website management.

Review Questions

Short Answer Questions

1. Distinguish between a functional requirement and a non-functional requirement.
2. What is the purpose of a RACI matrix?
3. Why should website scope include exclusions?
4. Name four activities that should be included in content migration.
5. Why is rollback planning important at launch?

Long Answer Questions

1. Explain how organisational objectives can be translated into website requirements and measurable outcomes.
2. Discuss the role of information architecture, user journeys and prototypes in reducing website project risk.
3. Describe a comprehensive website quality-assurance process, including accessibility, security and performance.
4. Explain how a website budget should account for total cost of ownership and uncertainty.
5. Discuss the responsibilities of an organisation when managing an external website vendor.

Analytical / Application Questions

1. A retailer wants to launch a new website in six weeks, but product content, redirect mapping and payment testing are incomplete. Analyse the risks and recommend a launch decision and mitigation plan.
2. A public-sector website receives high traffic but few completed applications. Design an investigation using requirements evidence, user journeys, analytics and usability testing.
3. A small organisation is considering an AI tool to rewrite all website content. Evaluate the potential benefits, risks, governance controls and human-review process before approval.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-functional requirement?

A. The website shall provide a product search function.

B. The website shall allow users to submit an enquiry form.

C. The website shall protect personal data through appropriate security controls.

D. The website shall display a course comparison table.

Correct Answer: C. The website shall protect personal data through appropriate security controls.

Question 2

In a RACI matrix, who is accountable?

A. The person who performs every task

B. The person who owns the final decision or result

C. Everyone who receives a project update

D. Only external consultants

Correct Answer: B. The person who owns the final decision or result

Question 3

Which practice most directly controls scope creep?

A. Adding all stakeholder suggestions immediately

B. Removing all review meetings

C. Using documented change requests and approval authority

D. Allowing the vendor to redefine objectives

Correct Answer: C. Using documented change requests and approval authority

Question 4

What is the primary purpose of a wireframe?

A. To provide final legal approval

B. To test layout, hierarchy and user flow before detailed development

C. To replace all accessibility testing

D. To measure server response time

Correct Answer: B. To test layout, hierarchy and user flow before detailed development

Question 5

Which activity is part of responsible content migration?

A. Copying every old page without review

B. Removing all old URLs without redirects

C. Classifying content as retain, improve, consolidate or remove

D. Delaying content decisions until after launch

Correct Answer: C. Classifying content as retain, improve, consolidate or remove

Question 6

Which item should be included in a launch plan?

A. A procedure for rollback if a critical failure occurs

B. A commitment to avoid all post-launch monitoring

C. An instruction to disable backups

D. A decision to omit analytics validation

Correct Answer: A. A procedure for rollback if a critical failure occurs

Question 7

Why should performance testing use representative devices and network conditions?

A. Office networks always produce the slowest results

B. User experience varies according to devices, networks and locations

C. Page weight is unrelated to user experience

D. It eliminates the need to test functionality

Correct Answer: B. User experience varies according to devices, networks and locations

Question 8

A website has 2,000 relevant visits and 80 completed enquiries. What is the conversion rate?

A. 2%

B. 4%

C. 8%

D. 25%

Correct Answer: B. 4%

Question 9

Which is the strongest reason to assign content owners and review dates?

A. To ensure content remains accurate and accountable over time

B. To prevent all content from being edited

C. To make website navigation unnecessary

D. To eliminate the need for analytics

Correct Answer: A. To ensure content remains accurate and accountable over time

Question 10

What is an appropriate governance response when using generative AI for website content?

A. Publish all generated text without review

B. Enter confidential customer data into any free tool

C. Use human review, source verification and defined privacy controls

D. Allow AI to make final legal and accessibility decisions

Correct Answer: C. Use human review, source verification and defined privacy controls