From Requirements to Launch: How to Avoid Misunderstandings Throughout a Web Project

Abstract words are a first source of confusion:

• modern;
• professional;
• intuitive;
• dynamic;
• fast;
• complete.

These words express an ambition, but they do not define what the website must allow people to do.

A company may ask for a “client portal.” To them, that might mean viewing invoices, downloading documents and tracking an order. For the technical team, the phrase immediately raises other questions: should accounts be created, passwords managed, several roles defined, personal data stored, or external software connected?

Misunderstanding begins when these questions remain implicit.

Differences in vocabulary also matter. The client describes the business in industry terms. The designer thinks in journeys, content and visual hierarchy. The developer thinks in data, rules, integrations and error cases. Each person holds part of the solution, but no document replaces the conversations needed to connect these viewpoints.

A useful requirement does more than describe a page. It connects a person, an action and an outcome.

Instead of writing:

The website will include a professional contact page.

It is better to specify:

A visitor must be able to select the subject of their request, provide contact details, write a message, receive a confirmation and allow the relevant team to receive the request.

This wording reveals several decisions:

• the required fields;
• which fields are mandatory;
• the recipients;
• the confirmation after submission;
• spam protection;
• data handling;
• mobile behaviour;
• the person responsible for follow-up.

The Government Digital Service recommends connecting each need to the relevant user, the expected action and its purpose. It also recommends defining acceptance criteria that explain concretely when the need has been met. GOV.UK — Writing user stories

This approach can be applied to the main elements of a project:

• pages and navigation;
• search;
• forms;
• payments;
• member areas;
• appointment booking;
• catalogues;
• multilingual content;
• newsletters;
• CRM;
• analytics;
• administrator roles;
• maintenance.

The goal is not to turn the client into a technician. It is to make expectations concrete enough for every stakeholder to verify the same result.

Alignment must be built in stages.

It defines the pages, their hierarchy and the main navigation paths. This is the time to verify whether visitors will be able to find services, projects, contact details and other important information.

It shows what a page must contain before colours and images capture everyone’s attention:

• title;
• introduction;
• proof;
• offer presentation;
• form;
• call to action;
• supporting content.

A wireframe makes it possible to discuss structure without confusing that discussion with decoration.

The mockup introduces colours, typography, images, spacing and hierarchy. It should be assessed against the original need: does the visitor understand the offer? Is the main button visible? Does the content remain easy to read on mobile?

A mockup can show a form without specifying its routing, a button without a destination, or a member area without access rules. Development must translate visual elements into working behaviours.

Prototypes are especially useful for creating a shared understanding and testing interactions before committing to the final build. The Government Digital Service nevertheless reminds teams that a prototype is not yet production-ready: security, performance and robustness must be addressed in the final version. GOV.UK — Making prototypes

A single final approval concentrates too much risk. If the client discovers at the end that the sitemap does not reflect the business, everything that depends on that structure may need to be reworked.

Intermediate approval points reduce that risk:

1. approve the need and objectives;
2. approve the scope;
3. approve the sitemap;
4. approve the wireframes;
5. approve the visual direction;
6. approve the main features;
7. conduct acceptance testing before launch.

Each approval must answer a specific question. “It looks good” is not sufficient approval for a mockup. The client must also confirm that the expected content, actions and journeys are present.

An approval record should identify:

• the item reviewed;
• its version;
• the person responsible for the decision;
• the feedback provided;
• the decision made;
• the remaining actions.

This prevents an approved mockup from being challenged several weeks later without distinguishing a genuine defect from a change in preference.

Not all feedback represents the same kind of change.

The result does not match what was agreed.

Example: the button was supposed to open the quote page, but it leads to the home page.

An existing requirement needs clarification without substantially changing the work.

Example: identifying which team member should receive a form whose routing was already planned.

An element that was not included in the original scope is added.

Example: requesting a CRM connection that had never been mentioned.

The request changes the solution enough to affect effort, dependencies, schedule or budget.

Example: turning a brochure website into a multilingual platform with user accounts and payments.

These distinctions make it possible to discuss change without accusing the client of having “asked incorrectly” or the provider of being “inflexible.” The conversation becomes more constructive: what is the impact of the decision, and how should it be incorporated?

Microsoft’s guidance on change management recommends recording changes to requirements, acceptance criteria and related artefacts. It also recommends making change requests visible in project tracking so their effect on scope can be assessed. Microsoft Learn — Manage Agile requirements

A project does not need a twenty-page report after every conversation. It does, however, need a shared memory.

An important decision should not remain only in:

• a phone call;
• a voice note;
• a WhatsApp conversation;
• one person’s memory.

After an important discussion, a short record may be enough:

• decision;
• reason;
• person approving it;
• possible impact;
• next action;
• deadline.

The tool matters less than the discipline. It may be an email, a shared document, a card in a project-management tool or a tracking table.

What matters is that the client and provider can retrieve the same decision.

Consider a hypothetical SME that replaces a contact form during the project with a booking request including a calendar and payment. A simple message saying “add booking” does not reveal all the consequences: availability, confirmation, cancellation, payment, refunds, notifications and data protection.

A documented decision makes those consequences visible before they become surprises.

Acceptance testing is not a quick tour of the home page. It verifies that the website matches the approved scope and works in the expected situations.

For every feature, the team should be able to answer two questions:

1. What result do we expect?
2. How will we verify it?

Microsoft presents acceptance criteria as a clear definition of what “done” means, which can be used to estimate the work and prepare tests. Microsoft Learn — Manage Agile requirements

• desktop;
• tablet;
• mobile;
• target browsers;
• no horizontal overflow;
• readable content.

• menu;
• internal links;
• buttons;
• downloads;
• external links;
• language versions.

• labels;
• required fields;
• error validation;
• CAPTCHA or anti-spam protection;
• recipients;
• confirmation response;
• mobile display;
• personal-data handling.

• headings;
• contact details;
• prices where published;
• images;
• alternative text;
• documents;
• translations;
• legal notices.

• SEO title;
• meta description;
• URL;
• H1/H2/H3 hierarchy;
• indexing;
• redirects;
• social sharing;
• Search Console monitoring.

• page loading;
• baseline performance;
• security;
• backups;
• administrator permissions;
• integration behaviour.

• issues recorded;
• owner for each correction;
• items explicitly postponed;
• client approval of the version to be launched.

The W3C recommends integrating accessibility throughout the process and evaluating the product early and regularly. It also notes that automated tools cannot fully replace human evaluation. W3C WAI — Planning and Managing Web Accessibility, W3C WAI — Evaluating Web Accessibility

The Government Digital Service likewise recommends regularly testing usability, stability, security and service behaviour under different conditions. GOV.UK — Quality assurance: testing your service regularly

Publishing is a milestone, not the end of the website’s life.

Before launch, confirm:

• the backup;
• domains and certificates;
• redirects;
• forms;
• access credentials;
• analytics tools;
• indexing;
• account ownership;
• the rollback procedure;
• responsibilities after launch.

After publishing, Search Console and analytics tools help show how the website is discovered and used. Google distinguishes visibility data from search results and interaction data on the website; the two reveal different aspects of performance. Google Search Central — Using Search Console and Google Analytics data for SEO

It is also important to distinguish the following four concepts.

A behaviour does not match the approved functionality.

Someone needs help using an existing feature correctly.

The website must remain secure, compatible, backed up and operational.

A new capability or a change in need must be designed, estimated and planned.

This distinction prevents every new idea from being described as a “small fix” and every request for help from being treated as a technical defect.

To maintain alignment from beginning to end:

1. listen to the business need and restate it without jargon;
2. define what users must be able to accomplish;
3. set the scope and what it excludes;
4. approve the sitemap and user journeys;
5. approve the structure before the visual direction;
6. translate features into acceptance criteria;
7. record decisions and change requests;
8. carry out structured acceptance testing on the relevant devices;
9. organise launch, maintenance and future enhancements.

The requirements document establishes a shared starting point. Approvals and documentation then keep that starting point from being lost during delivery.

A web project is not protected by a document that everyone signs and then forgets. It is protected by a chain of understandable, verifiable decisions.

The need guides the scope. The scope guides the structure. The structure guides the design. The design guides development. Acceptance criteria guide testing. Documented decisions frame changes.

This continuity is what allows the client and provider to remain on the same team through launch.

• GOV.UK Service Manual — Writing user stories
• GOV.UK Service Manual — Making prototypes
• Microsoft Learn — Manage Agile requirements
• W3C WAI — Planning and Managing Web Accessibility
• W3C WAI — Evaluating Web Accessibility
• GOV.UK Service Manual — Quality assurance: testing your service regularly
• Google Search Central — Using Search Console and Google Analytics data for SEO