In short: a good specification does not try to provide for each screen. It sets the problem to be solved, the users, the content, the functions, the constraints and the success criteria. It thus makes it possible to compare proposals on a common scope and to reduce late decisions.
The document can hold in a few pages for a business website or become more detailed for an e-commerce and an application. Its value does not depend on its length, but on its ability to make expectations verifiable. A list of graphic trends is not a specification; a clear description of the context, responsibilities and expected results is already a good basis for it.
Start with the context of the project
Present the company, its offer, its markets and the reason for the project. Is it a launch, redesign, migration or the addition of a service? Explain what works today and what is problematic, without imposing a technical solution too soon.
Add the people who will decide, those who will provide the content and those who will administer the site. This mapping prevents an essential validation from happening when the mock-ups or development are already advanced.
Formulate observable objectives
"Modernizing the site" remains too vague. Specify what the company wants to allow: obtain qualified requests, sell a selection of products, simplify appointment booking, make documentation accessible or present achievements to a defined market.
Associate each objective with a useful indicator and a source of verification. A request sent and registered, a confirmed order or a successful appointment are more interpretable than an isolated volume of visits. No indicator guarantees the commercial result, but it clarifies what the site must measure.
Describe audiences and their situations
A few concrete profiles are enough. For each, document the need, level of information, objections, the most likely device and the expected action. A professional buyer who compares three providers does not have the same path as an individual facing an emergency.
Avoid decorative personas based on a fictitious first name and tastes unrelated to the decision. Exchanges with sales teams, support and customers bring real questions to address in the pages.
Inventory the available content
List existing texts, photos, videos, documents, reviews, customer cases, product sheets and existing legal information. Indicate what can be taken up, must be rewritten or remains to be produced. For a redesign, add the current URLs, their traffic or utility, and the intended destination.
Assign a manager and date to each missing content. Without this, integration often becomes the blocking point of the schedule. Our guide to steps of a web project explains how this preparation is inserted into the entire production.
Draw the functional scope
Describe the functions by use: search for a product, filter a catalog, pay, reserve, send a request, manage an account or publish an article. For each important function, specify the necessary data, the authorized roles, the possible errors and the expected result.
Separate three levels: essential at launch, useful then and outside the scope. This priority protects the project against the continuous addition of functions. It also facilitates a phased proposal when a need can be validated with a MVP before investing more.
Document tools and data exchanges
Name the domain name, hosting, CMS, CRM, business software, payment solution, email tool and measurement accounts concerned. Indicate who owns it and who can provide access. A simple "connect the CRM" is not enough if the API, fields and synchronization rules remain unknown.
Specify the personal data processed, their purpose and the people who need to access it. Consent, retention or hosting constraints can influence the architecture; they must be addressed before the integration of a third-party tool.
Set testable quality requirements
Replace "the site will be fast and responsive" with observable controls: priority pages on mobile, supported browsers, keyboard scenarios, media weight, form behavior in case of error and performance objectives to be verified under defined conditions.
Accessibility is not just about a compliant color. Structure, focus, wording, textual alternatives and error messages are part of the acceptance testing. The W3C distinguishes between automatic assessments and human accessibility assessment, useful for organizing controls proportionate to the project.
Framework SEO, redirections and measurement
Specify the search audiences, strategic pages, content to keep, and old URLs to redirect. For a redesign, the correspondence between old and new pages must be prepared before going online; consult our guide to recast a site without losing SEO achievements.
Also define the actions to be measured, without confusing click and result. The precise plan of events, consent, and sources of truth can become a separate deliverable when multiple campaigns or systems are involved.
Clarify deliverables, responsibilities and ownership
Ask what will be given: site structure, models, code, content, documentation, access, exports and deployment procedure. Specify the number of feedback rounds, the person who validates and the expected response time on each side.
Ownership of the domain, hosting, advertising accounts, statistics and code repository must be explicit. The document must also indicate what is part of the correction guarantee, recurring maintenance or an evolution billed separately.
Give a realistic framework to the budget and schedule
A budget range helps the agency propose a proportionate architecture. Mention the known external costs: licenses, hosting, payment, translation, photo production or subscriptions. A comparable quote distinguishes the initial design from recurring expenses.
For the schedule, fill in a target date and its reason, periods of unavailability and dependencies. A fixed commercial event does not have the same flexibility as an internal preference. Our article on the site creation time details the factors that really influence the schedule.
Use a common comparison grid
Ask providers to respond to the same basis: understanding of the need, hypotheses, exclusions, method, team, deliverables, schedule, budget, maintenance and access ownership. The proposed technology must be justified by the context, not only cited as an advantage.
A serious response points out missing information and risks. It does not promise an unverifiable result. To complete your analysis, also use our criteria to choose a web agency in Nice.
The frame to be transmitted
Before the consultation, gather at least:
-
the context and the problem to be solved;
-
the objectives, audiences and expected actions;
-
the envisaged site structure and the content inventory;
-
functions classified by priority;
-
the tools, data and accesses concerned;
-
quality requirements and acceptance testing scenarios;
-
deliverables, responsibilities and validation rules;
-
the budget, recurring costs and target date.
BlackStone Digital can transform this brief into a scope of custom website creation. If your document is still incomplete, send us the context and constraints already known: the first exchange also serves to identify the missing decisions.
