Website Planning, Requirements and Technology Choices

Introduction

A website is not merely a collection of pages. It is a business system through which an organisation communicates, creates value, collects information, supports transactions and builds relationships. For a digital marketer, website planning is therefore a strategic activity. Decisions about the domain name, hosting environment, content management system (CMS), e-commerce functions, integrations and suppliers influence search visibility, conversion, security, operating cost and the ability to respond to changing customer needs.

Website planning translates business intentions and user expectations into implementable requirements. A useful plan connects five elements:

1. Business purpose—what the organisation wants to achieve.
2. User value—what visitors need to accomplish.
3. Functional requirements—what the website must do.
4. Non-functional requirements—how well it must perform.
5. Technology and supplier choices—how the requirements will be delivered and maintained.

A technically sophisticated website can still fail if it solves the wrong problem. Conversely, a simple website can be highly effective when it is aligned with users, measurable objectives and organisational capability.

Learning Objectives

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

• translate business and user needs into website requirements;
• distinguish functional from non-functional requirements;
• plan information architecture, content and user journeys;
• evaluate domains, hosting and CMS platforms;
• identify e-commerce functions and essential integrations;
• compare build, buy and hybrid delivery approaches;
• apply practical criteria to vendor selection; and
• recognise security, accessibility, privacy, governance and maintenance responsibilities.

1. From Business Strategy to Website Requirements

1.1 Starting with the business problem

Planning should begin with a business problem rather than a preferred technology. A business may want to increase online sales, reduce telephone enquiries, generate qualified leads, improve customer self-service, publish trusted information or support a membership community. Each objective implies different website capabilities.

For example, an online retailer requires product discovery, stock information, checkout, payment processing and fulfilment integration. A professional consultancy may instead need authoritative content, case studies, lead forms, calendar booking and a customer relationship management (CRM) connection. Selecting an enterprise commerce platform for the consultancy could create unnecessary cost and complexity.

Business objectives should be expressed in measurable terms. “Improve the website” is too vague. A stronger objective might be “increase completed enquiry submissions from qualified visitors while maintaining an accessible and trustworthy experience.” The objective does not prescribe a solution; it establishes the outcome against which alternatives can be assessed.

1.2 Understanding users and stakeholders

Users are not a single homogeneous group. A website may serve prospective customers, existing customers, employees, suppliers, journalists and regulators. Internal stakeholders may include marketing, sales, customer service, information technology, legal, finance and senior management.

Useful discovery methods include:

• interviews with customers and staff;
• analysis of search queries, website analytics and support requests;
• observation of existing tasks;
• competitor and sector review;
• surveys and usability testing; and
• workshops that map user journeys and organisational processes.

A persona can summarise a significant user group, but it should be based on evidence rather than stereotype. A journey map identifies stages such as awareness, comparison, decision, purchase, use and support. At each stage, planners should ask what the user is trying to do, what information is required, what barriers exist and what evidence would create confidence.

1.3 Requirement categories

A requirement states a necessary capability or quality. Requirements should be specific enough to guide design and testing, but not so prescriptive that they prevent better solutions.

Functional requirements are often expressed as user stories: “As a prospective learner, I want to filter courses by subject and delivery mode so that I can find a suitable option.” Acceptance criteria make the story testable: the visitor can select filters, results update correctly, and the selected criteria are visible.

Non-functional requirements deserve equal attention. They may concern performance, availability, accessibility, security, scalability, maintainability, portability and compatibility. “The site should be fast” is weak; “key pages should meet the organisation’s agreed performance threshold under expected traffic” is more useful, provided the threshold and measurement method are defined.

1.4 Prioritisation and scope

Not every desirable feature belongs in the first release. A practical prioritisation method classifies requirements as:

• Must have—essential to launch or compliance;
• Should have—important but with a possible workaround;
• Could have—valuable if resources permit; and
• Won’t have now—explicitly deferred.

This prevents scope from expanding without control. A minimum viable website is not an incomplete website; it is the smallest release that delivers a meaningful, safe and measurable outcome. Deferred features should be recorded in a product backlog with owners and review dates.

A requirements traceability matrix can connect each requirement to its source, priority, proposed solution, test and owner. This is especially useful when several suppliers are involved.

2. Information Architecture, Content and Experience

2.1 Information architecture

Information architecture (IA) organises content so that people can find, understand and use it. It includes navigation, page hierarchy, labels, metadata, internal search and relationships between content types.

A good IA reflects user language and important tasks, not merely internal departmental structures. Card sorting can reveal how users group topics; tree testing can assess whether they can locate items in a proposed hierarchy. Navigation should be predictable, labels meaningful and important actions easy to identify.

A basic content model might define:

• Course: title, description, outcomes, duration, fee, dates and related courses;
• Article: headline, author, publication date, topic, body and related resources; and
• Product: name, SKU, price, images, stock status, specifications and delivery information.

Content modelling is important because a CMS stores structured content, not simply visual pages. Well-structured content can be reused in search results, landing pages, mobile applications or email campaigns.

2.2 Content governance

A website requires continuing editorial work. Governance should establish who creates, reviews, approves, publishes, updates and retires content. A content lifecycle commonly includes planning, drafting, review, approval, publication, measurement, revision and archiving.

Governance should also define tone of voice, image rights, accessibility standards, metadata, version control and escalation procedures. Without ownership, content becomes outdated and user trust declines.

2.3 User experience and conversion

User experience (UX) concerns the complete quality of interaction, including usefulness, clarity, accessibility, confidence and emotional response. Conversion is the completion of a desired action, such as purchasing, registering, downloading or submitting an enquiry. Conversion optimisation should not manipulate users into actions they do not understand. Clear value propositions, transparent costs, concise forms, evidence such as reviews, and appropriate calls to action generally support both usability and ethical marketing.

3. Domain Names and Digital Identity

A domain name is the human-readable address used to reach a website. It contributes to brand recognition, memorability and trust, although a domain alone does not guarantee search ranking or credibility.

Selection criteria include:

• relevance to the organisation and audience;
• ease of spelling, pronunciation and recall;
• suitable top-level domain and geographic meaning;
• absence of trademark conflict;
• protection against confusingly similar names; and
• availability of related social and campaign identifiers where appropriate.

The organisation should normally control the registrar account, renewal credentials and domain transfer authorisation. Registration details, renewal dates and responsible owners should be documented. Automatic renewal reduces accidental expiry, but payment methods and notification addresses must be kept current.

DNS (Domain Name System) records connect a domain to services. Common records include A or AAAA records for server addresses, CNAME records for aliases, MX records for email routing, and TXT records for verification and email-security policies. Changes should be controlled because an incorrect DNS configuration can interrupt the website or email.

A secure website should use HTTPS, normally through a valid TLS certificate. Certificate management, redirect rules and canonical domain selection are technical details with marketing effects: broken redirects and duplicate versions can damage user experience and search indexing.

4. Hosting and Technical Architecture

Hosting is the infrastructure on which website software, databases and media operate. The main approaches include:

The correct choice depends on traffic patterns, data sensitivity, technical skills, availability expectations, geographic needs, budget and integration requirements. “Cloud” is not automatically secure, inexpensive or infinitely scalable. Responsibility is shared: the provider may secure physical infrastructure, while the organisation remains responsible for accounts, permissions, application configuration, content and data handling.

Important hosting questions include:

• What availability commitment and service-level agreement are offered?
• How are backups created, protected, tested and restored?
• How are security patches and vulnerabilities handled?
• Where is data stored and processed?
• What support hours and response times apply?
• How can the organisation export data and migrate away?
• How are traffic spikes and denial-of-service events managed?

A backup that has never been restored is an assumption, not evidence of recoverability. Recovery objectives should be agreed. The recovery point objective identifies the maximum acceptable amount of lost data, while the recovery time objective identifies the maximum acceptable restoration time.

5. Choosing a CMS Platform

A CMS enables authorised users to create, manage and publish digital content. A traditional or coupled CMS combines content management and presentation in one system. A headless CMS manages content through an application programming interface (API), allowing delivery to websites, applications and other channels. A decoupled approach separates the editing and presentation layers while retaining stronger connections than a fully headless model.

5.1 Evaluation dimensions

A CMS should be evaluated against requirements rather than popularity. Relevant dimensions include:

• editorial usability and workflow;
• roles, permissions and approval controls;
• content modelling and reuse;
• templates and design flexibility;
• search engine optimisation controls;
• accessibility support;
• media management;
• multilingual or multisite capability;
• performance and caching;
• security update process;
• API and integration capability;
• analytics and experimentation support;
• total cost of ownership; and
• portability of content and data.

Open-source software may reduce licence fees and provide a broad ecosystem, but the organisation may still pay for hosting, development, security, support and upgrades. Proprietary software may offer coordinated support and features, but can create subscription costs and vendor dependency. Neither category is automatically superior.

5.2 Total cost of ownership

Technology cost includes more than purchase price. A simple planning model is:

Here, TCO is total cost of ownership over the selected period; C₀ is initial implementation cost; O_t is operating cost in period t; L_t is licence or subscription cost; I_t is integration and improvement cost; S_t is support, security and training cost; and R is any relevant residual value or avoided cost. The model is a planning aid, not a precise forecast. Costs should use a consistent time period and should include taxes, migration, accessibility remediation and staff time where material.

6. E-Commerce Functions and Integrations

An e-commerce website is a transaction system, not simply a product catalogue. Core functions may include:

• product or service catalogue;
• categories, filters and search;
• pricing, promotions and tax handling;
• stock or capacity management;
• basket and checkout;
• payment authorisation and settlement;
• customer accounts and order history;
• delivery, collection or digital fulfilment;
• refunds, cancellations and notifications;
• fraud monitoring and transaction records; and
• reporting and reconciliation.

Payment-card information should generally be handled by a specialist payment service provider rather than stored unnecessarily by the organisation. Compliance obligations depend on the business model, location, payment flow and data handled. Legal advice may be necessary for consumer rights, tax, contracts, subscriptions and international sales.

Integrations connect the website to other systems. Common examples include CRM, email marketing, enterprise resource planning, inventory, accounting, identity management, customer support, analytics, search, shipping and marketing-automation platforms.

An integration specification should define the data exchanged, direction of flow, frequency, authentication, error handling, ownership, retention and reconciliation. For example, if an order is sent to an inventory system but the response fails, the organisation needs a visible exception process rather than silently losing the order.

APIs are useful but do not remove integration risk. Version changes, rate limits, data-quality problems and supplier outages must be considered. Webhooks can communicate events in near real time, whereas scheduled imports may be simpler and more resilient for some processes.

7. Build, Buy or Use a Hybrid Approach

The build-versus-buy decision compares strategic differentiation, cost, control, speed and risk.

Build may be appropriate when the requirement is genuinely distinctive, existing products cannot meet it, or full control is strategically important. It requires development capability, testing, documentation, maintenance and succession planning.

Buy or subscribe may be appropriate for common capabilities such as email delivery, payments, appointment booking or standard commerce. It can provide faster deployment and specialist maintenance, but may limit customisation and create recurring costs.

Hybrid approaches combine packaged components with custom configuration or extensions. Many practical websites use a CMS, a payment provider, analytics services and custom integrations rather than building every component.

A capability should not be custom-built merely because it is technically possible. Custom software can become a hidden dependency when its original developers leave, documentation is poor or upgrades are avoided. Conversely, forcing a distinctive business process into a rigid package can create workarounds and poor user experience.

8. Vendor Selection and Procurement

Vendor selection should be evidence-based and consistent. A typical process is:

1. define objectives, scope and requirements;
2. identify the market and create a longlist;
3. issue a request for information or proposal;
4. evaluate written responses against agreed criteria;
5. conduct demonstrations using realistic scenarios;
6. complete technical, financial, security and reference checks;
7. negotiate terms, responsibilities and exit provisions; and
8. approve the contract and implementation plan.

Demonstrations should use the organisation’s actual tasks. A polished generic presentation can conceal poor editorial workflows or expensive customisation.

A weighted scoring model supports transparent comparison:

In this model, S is the total vendor score; w_i is the weight assigned to criterion i, with all weights normally summing to 1; and r_i is the vendor’s rating for that criterion on an agreed scale. The model assumes criteria are sufficiently defined and that ratings are applied consistently. It should support—not replace—professional judgement, risk review and due diligence.

Possible criteria include functional fit, usability, accessibility, security, integration capability, implementation approach, support, financial stability, total cost, portability and environmental or social responsibility. A mandatory requirement should be treated as a pass/fail condition rather than allowed to disappear inside an average score.

Contracts should address service levels, data ownership, confidentiality, security responsibilities, breach notification, subcontractors, accessibility, intellectual property, change control, support, disaster recovery, audit rights, termination assistance and data export. Vendor lock-in is reduced when data formats, APIs, documentation and migration responsibilities are clear.

9. Security, Privacy, Accessibility and Governance

Security is a continuous management responsibility. Basic controls include strong authentication, least-privilege access, multi-factor authentication for administrative accounts, timely updates, secure development practices, vulnerability monitoring, logging, backups and tested incident procedures.

Common web risks include injection, broken access control, insecure authentication, exposed secrets, vulnerable dependencies and misconfigured cloud storage. Marketing teams do not need to become security engineers, but they must ensure that campaigns, forms, tracking tools and third-party scripts are assessed before deployment.

Privacy requires purpose limitation, data minimisation, transparency, appropriate retention and controlled access. Forms should request only information that is necessary. Consent, where required, should be informed and freely given rather than hidden in confusing design. Cookies, analytics and advertising technologies may create additional obligations depending on jurisdiction.

Accessibility is both an ethical responsibility and a practical requirement. Content should support keyboard operation, readable contrast, meaningful headings, text alternatives for informative images, clear error messages, captions where needed and compatibility with assistive technologies. Accessibility should be tested with automated tools and human users; automated checking alone is insufficient.

Governance assigns accountability. A website should have named owners for content, technical operations, analytics, privacy, security and supplier relationships. Change management reduces the risk that an urgent campaign introduces broken links, inaccessible content or unapproved data collection.

10. Measurement, Testing and Continuous Improvement

Requirements should be testable before launch. Testing may include:

• content and link checking;
• responsive and cross-browser testing;
• accessibility testing;
• usability testing with representative users;
• performance and load testing;
• security testing;
• integration and payment testing;
• analytics and consent verification; and
• backup and recovery testing.

A launch checklist should include redirects, metadata, indexing controls, tracking events, error pages, legal content, contact routes and rollback procedures. Launch is a controlled transition, not the end of planning.

Measurement should reflect objectives. A lead-generation site might monitor qualified enquiries and completion rates; a service site might monitor successful self-service and reduced support demand; an e-commerce site might monitor revenue, margin, checkout completion, refunds and repeat purchase. Metrics must be interpreted carefully. A high conversion rate may be undesirable if it results from misleading design or attracts unsuitable customers.

A simple conversion rate is:

The denominator must be defined consistently. Visits, sessions, users and eligible product views are not interchangeable. Tracking systems may also be affected by consent choices, browser restrictions and duplicate events.

Applied Case: Illustrative Scenario—Harbour Skills Institute

Background

Harbour Skills Institute, a fictional training provider, offers short professional courses. Its existing website contains static course pages and a downloadable application form. Staff answer repeated questions about dates, fees and availability by email.

Problem

The institute wants to increase enrolments and reduce administrative workload. Marketing proposes immediately purchasing a large e-commerce platform. However, discovery reveals that courses have limited cohorts, some require approval before payment, and the finance system must issue invoices. The main user groups are prospective learners, employers purchasing places and returning learners.

Analysis

Research identifies three high-priority journeys: comparing courses, requesting advice and enrolling on an available course. Requirements include searchable course information, filters by subject and delivery mode, accessible forms, cohort-capacity information, approval workflow, online payment for suitable courses, invoice creation, CRM recording and email reminders. Non-functional requirements include mobile usability, secure processing, clear ownership and the ability for non-technical staff to update course dates.

Approach and solution

The institute selects a managed CMS with structured course content, a booking component and an external payment provider. The CMS connects to the CRM and finance system through an integration service. The first release excludes a complex learner portal and automated employer procurement because these are not essential to the immediate objective. A content governance process assigns each department responsibility for reviewing course information monthly.

Vendors are evaluated using weighted criteria: requirements fit, accessibility, integration, security, usability, total cost and exit capability. Demonstrations require each vendor to create a course, change capacity, submit an enquiry and export content. The preferred supplier is not the cheapest, but provides stronger workflow controls and clearer migration terms.

Outcome

The solution gives users current course information and a simpler enrolment path while reducing repetitive enquiries. The institute establishes baseline measures before launch and reviews them monthly. It also discovers that some users abandon the payment process because employer invoicing is unclear, leading to a later improvement in the enrolment journey.

Learning points

The case illustrates that technology selection follows requirements, not the reverse. It also demonstrates the value of phased delivery, structured content, integration planning, vendor demonstrations based on real tasks and continuous measurement. A platform decision is successful only when people, processes, content and technology work together.

Contemporary Developments

Several developments affect website planning. Composable architectures allow organisations to combine specialised services, but they increase integration and governance responsibilities. Headless delivery supports multiple channels, yet requires stronger design-system and content-modelling capability. Artificial intelligence can assist with content drafts, search, translation, personalisation and support, but outputs require human review for accuracy, bias, privacy and brand integrity. AI-generated content should not be treated as authoritative without editorial accountability.

Privacy-preserving measurement is becoming more important as browsers, laws and users limit third-party tracking. Organisations are therefore investing in first-party data, contextual measurement, clear value exchange and server-side or aggregated approaches where appropriate. Sustainability is also relevant: efficient media, lean code, appropriate hosting and reduced unnecessary data transfer can lower environmental impact while improving performance.

Challenges and Limitations

Website planning involves uncertainty. User research may be incomplete, requirements may conflict and suppliers may overpromise. Weighted scoring can create false precision, while total-cost estimates may omit internal staff time or future migration. Platform features change, integrations fail and regulations evolve. A technically valid solution may still fail if content is unavailable, staff are not trained or users do not trust the organisation.

The appropriate response is not to seek certainty before acting. It is to make assumptions visible, test high-risk decisions early, pilot where appropriate, document ownership and review performance after launch. Good planning is iterative and evidence-based.

Best-Practice Checklist

• Begin with business outcomes and user tasks.
• Separate functional, non-functional, content, technical and legal requirements.
• Prioritise requirements and define acceptance criteria.
• Model content for reuse and assign editorial ownership.
• Keep domain and supplier accounts under organisational control.
• Evaluate hosting for security, recovery, support and exit capability.
• Select a CMS against actual workflows, not popularity alone.
• Treat integrations, payment processes and data flows as core design concerns.
• Compare build, buy and hybrid options using total cost and strategic value.
• Use realistic vendor demonstrations and documented scoring.
• Design for privacy, accessibility and security from the beginning.
• Test analytics, recovery, integrations and user journeys before launch.
• Measure outcomes and improve continuously.

Chapter Summary

Website planning translates organisational goals and user needs into requirements that can guide design, procurement, development and evaluation. Effective planning distinguishes business, user, functional, non-functional, content, technical and legal requirements. Information architecture, structured content and governance determine whether a website remains understandable and maintainable.

Domain and hosting decisions affect identity, reliability, security and control. CMS selection should consider editorial workflows, content modelling, accessibility, integrations, security, portability and total cost of ownership. E-commerce requires coordinated catalogue, checkout, payment, fulfilment, customer-service and reporting functions. Integrations must specify data flows, authentication, errors and ownership.

Build, buy and hybrid approaches each involve trade-offs. Vendor selection is strongest when requirements are testable, demonstrations use realistic tasks, scoring is transparent and contracts address security, service levels, data ownership and exit. Finally, accessibility, privacy, security, measurement and continuous improvement are not optional additions; they are essential dimensions of professional website management.

Key Terms

Domain name: Human-readable address used to access a website.

DNS: System that maps domain names to network services and addresses.

Hosting: Infrastructure and services used to operate a website.

CMS: Software for creating, managing and publishing digital content.

Headless CMS: CMS that manages content separately from its presentation layer.

Information architecture: Organisation and labelling of content and navigation.

Functional requirement: Capability or behaviour a system must provide.

Non-functional requirement: Quality, constraint or performance characteristic required of a system.

User story: Short statement of a user need expressed from the user’s perspective.

Acceptance criteria: Conditions that determine whether a requirement is satisfactorily delivered.

Content model: Definition of content types, fields and relationships.

API: Defined mechanism through which software systems exchange data or services.

Webhook: Automated message sent when a specified system event occurs.

CRM: System used to manage customer and prospect relationships.

E-commerce: Electronic buying and selling of products or services.

Total cost of ownership: Full cost of acquiring, operating, supporting and retiring a solution.

Vendor lock-in: Difficulty or cost involved in changing from a supplier or platform.

Accessibility: Designing digital services for people with varied abilities and assistive technologies.

Recovery time objective: Maximum acceptable time to restore a service after disruption.

Recovery point objective: Maximum acceptable amount of data loss measured in time.

Review Questions

Short Answer Questions

1. What is the difference between a functional and a non-functional requirement?
2. Why should website planning begin with a business problem rather than a technology platform?
3. Identify three issues that should be considered when selecting a domain name.
4. What is the purpose of a content model?
5. Define vendor lock-in and state one way to reduce it.

Long Answer Questions

1. Explain how user research and journey mapping contribute to website requirements.
2. Compare traditional, headless and decoupled CMS approaches.
3. Discuss the main factors involved in selecting a hosting model.
4. Explain why e-commerce integrations require explicit data-flow and error-handling plans.
5. Describe a robust vendor-selection process from requirements definition to contract negotiation.

Analytical / Application Questions

1. A small consultancy wants a five-page website, a lead form, appointment booking and CRM integration. Recommend a build, buy or hybrid approach and justify your decision.
2. An online retailer experiences abandoned checkouts and inaccurate stock information. Identify possible requirements, integration risks and tests that should be prioritised.
3. Create a short set of weighted vendor-selection criteria for a training provider, and explain why each criterion is important.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-functional requirement?

A. The website sends a confirmation email after a form is submitted.

B. The website allows users to filter courses by subject.

C. The website supports keyboard navigation and accessible error messages.

D. The website stores a customer’s order history.

Correct Answer: C. The website supports keyboard navigation and accessible error messages.

Question 2

What is the main purpose of information architecture?

A. To reduce the cost of domain registration

B. To organise content so users can find and understand it

C. To replace all website security controls

D. To calculate hosting bandwidth

Correct Answer: B. To organise content so users can find and understand it

Question 3

Which DNS record is commonly used for email routing?

A. MX

B. A

C. CNAME

D. AAAA

Correct Answer: A. MX

Question 4

What is a principal advantage of a headless CMS?

A. It removes the need for content governance

B. It prevents all vendor lock-in

C. It allows content to be delivered to multiple presentation channels

D. It guarantees higher search rankings

Correct Answer: C. It allows content to be delivered to multiple presentation channels

Question 5

Which activity is most appropriate during a realistic vendor demonstration?

A. Asking the supplier to show only its standard marketing slides

B. Asking the supplier to perform the organisation’s actual editorial and user tasks

C. Selecting the supplier with the most features regardless of requirements

D. Ignoring data export and migration capabilities

Correct Answer: B. Asking the supplier to perform the organisation’s actual editorial and user tasks

Question 6

In the formula Conversion rate = (completed actions ÷ eligible visits) × 100%, what must be defined consistently?

A. The colour of the call-to-action button

B. The denominator and what counts as an eligible visit

C. The supplier’s profit margin

D. The domain’s top-level extension

Correct Answer: B. The denominator and what counts as an eligible visit

Question 7

Which practice most directly reduces unnecessary privacy risk?

A. Collecting every possible customer attribute

B. Storing personal data indefinitely

C. Applying data minimisation and collecting only necessary information

D. Giving all staff administrator access

Correct Answer: C. Applying data minimisation and collecting only necessary information

Question 8

What does the recovery time objective describe?

A. The maximum acceptable time to restore a service

B. The maximum number of website pages

C. The time needed to approve a campaign

D. The age of a domain name

Correct Answer: A. The maximum acceptable time to restore a service

Question 9

Why is a backup that has never been restored an assumption rather than evidence?

A. Backups cannot contain databases

B. Restoration may fail or take longer than expected unless tested

C. Backups are relevant only to e-commerce sites

D. Hosting providers never support backups

Correct Answer: B. Restoration may fail or take longer than expected unless tested

Question 10

Which approach combines packaged services with custom configuration or integrations?

A. Build-only

B. Buy-only

C. Hybrid

D. Manual hosting

Correct Answer: C. Hybrid