Website technical specification: what to define before design and development begin

A useful website technical specification does more than list pages, colours and buttons. It connects the business objective, user needs, content, functionality, data flows and measurable quality criteria in one agreed document. Before design starts, the team should know who the website is for, what visitors need to accomplish and what outcome the business intends to measure. Before development begins, the parties should agree on the CMS, integrations, security, SEO, performance, accessibility, infrastructure and acceptance process.

The specification is not intended to predetermine every pixel or tell developers how to structure every line of code. Its purpose is to reduce ambiguity. Decisions made early prevent layouts from being redesigned when functional constraints emerge and reduce the risk of delivering a polished website that does not fit the company’s actual workflow.

What a website technical specification is

A website specification is an agreed description of what is being built, why it is being built, who it serves and how the completed result will be accepted. It gives management, marketing, content authors, designers, developers and external vendors the same point of reference.

It does not need to be a hundred-page document. A compact specification can be sufficient for a small company website if it leaves no material uncertainty about scope. A more complex platform will require supporting artefacts such as a data model, role matrix, integration diagrams, prototypes and detailed acceptance scenarios.

The most important rule is that requirements must be understandable and testable. “The website must be modern and fast” gives general direction but does not define completion. A better requirement might state that key public pages must be usable on agreed mobile devices and that performance will be assessed using defined Core Web Vitals and testing scenarios.

Start with the business objective

Before discussing the home page, navigation or animation, answer one question: what should the website change in the business?

Possible objectives include generating qualified enquiries, explaining services more clearly, enabling customer self-service, accepting bookings, selling products, reducing support work or entering another language market. Several objectives may coexist, but they need an order of priority. Otherwise every department will try to place its own message on the home page and visitors will not know what to do next.

The objective should be accompanied by success indicators. These may include submitted enquiries, completed bookings, calls initiated from the website, document downloads, completed self-service processes or qualified contacts. There is no need to promise a numerical increase without supporting data. The specification should simply define what will be measured, which analytics setup will collect it and who will review the results after launch.

Audiences and key user journeys

“Our customers are all businesses” is not a usable audience definition. The project needs a small number of relevant segments with different needs, knowledge levels and decision drivers. A company owner may want to understand value and credibility quickly, while a technical evaluator may look for integration, security and implementation details.

For each important segment, describe the primary journey:

• where the visitor is likely to arrive from;

• which question they need to resolve;

• what information supports the decision;

• which action the website should enable;

• what may prevent the visitor from completing that action.

These journeys shape the information architecture and prototype. If the website is intended to collect enquiries, “include a contact form” is not enough. The brief should state where the form appears, which fields are genuinely required, what happens after submission and where the enquiry is delivered inside the company.

Scope and site structure

The specification should separate the mandatory first release from later ideas. This protects the project from constantly adding new requirements to an already approved budget and schedule.

Create a sitemap covering the main sections, page types and hierarchy. A company website might include a home page, service overview, individual service pages, company information, case studies, a blog, contact details and legal pages. Define repeatable templates as well as individual pages. One service page and twenty pages generated from the same content model do not represent the same implementation scope.

State what is excluded as clearly as what is included. Copywriting, translation, photography, payments, a customer portal or content migration may be outside the agreed delivery. Recording exclusions prevents both sides from assuming that a task was “probably included”.

Content, languages and migration

Good design cannot be produced without understanding the real content. Heading length, table density, image proportions, the number of languages and mandatory legal notices directly affect layout.

Before design starts, agree on:

• the content types the website will contain;

• who supplies copy, images, video and documents;

• which assets already exist and which must be created;

• how content will be reviewed and approved;

• which languages are included at launch;

• whether all languages have identical content;

• whether existing content and URLs must be migrated.

When replacing an existing website, the specification should include a content inventory and redirect plan. Existing URLs should not simply disappear. Decide which URLs remain, which are consolidated and where permanent redirects should lead. This reduces broken links and helps preserve existing search visibility.

Design requirements go beyond colour choices

The design section should include brand assets, usage rules, the desired character and practical constraints. If the business has a logo, colours, licensed fonts, a photography direction or brand guidelines, provide them before the first screens are designed.

Reference websites are useful when each reference explains exactly what works: navigation logic, content hierarchy, use of imagery or a calm visual rhythm. Five links accompanied only by “we want something similar” create more guessing than clarity.

Define the design deliverables as well. Which pages and interface states will be designed? How will mobile layouts be represented? Will there be a clickable prototype? How many feedback rounds are included? Forms need more than empty fields: they also require error, success, loading and service-unavailable states.

Describe functionality as actions and outcomes

A list such as “search, filters, calculator, login” is too general for a reliable estimate. Each material feature should identify the user, starting condition, actions, outcome, error cases and CMS controls.

For example, an enquiry form may need to specify:

• required and optional fields;

• validation and error-message principles;

• protection against automated spam;

• who receives a notification and in what format;

• whether the data enters email, a CRM or both;

• what the visitor sees after submitting;

• how long the data is retained and who may access it;

• how the integration will be tested.

This level of detail lets the designer map the full interaction, helps the developer estimate the logic and enables the client to understand what will actually be delivered.

CMS and the content-management process

“We need an easy CMS” is subjective. Define what the internal team must be able to do without a developer. Should editors be able to create service pages, change navigation, manage SEO fields, save drafts, schedule publication, restore an earlier version and inspect an activity history?

Define roles and permissions. Administrators, editors, translators and external authors do not necessarily need the same access. If content requires approval, document the statuses and owners: draft, review, approved, published and archived.

For multilingual websites, establish how translations are linked, what happens when a translation is missing and whether different languages may use different page structures. These decisions affect both the CMS data model and SEO.

Integrations and data flows

If the website connects to a CRM, ERP, inventory platform, email marketing service, payment provider or calendar, naming the service is not enough. Define the source of data, transfer direction, fields, authentication method, synchronisation frequency and failure handling.

One question is especially important: which system is the source of truth? If a customer’s phone number is corrected in the CRM but the old value remains in the CMS, a rule must determine which value prevails. The brief should also cover external downtime. Is the submission queued for retry? Does an administrator receive an alert? What does the visitor see?

Non-functional requirements: quality users can feel

Non-functional requirements describe overall system quality rather than an additional button. They are often postponed until the end even though they can affect architecture and design from the beginning.

Performance and supported devices

Define priority devices, browsers and network conditions. Google’s Core Web Vitals can provide a shared performance reference, but the measurement environment and representative page templates must also be agreed. Laboratory tests and real-user data are different, so an acceptance criterion should say how and when the measurement is taken.

Accessibility

Accessibility should be designed into the project. WCAG 2.2 affects contrast, keyboard navigation, focus states, form errors, heading hierarchy, alternative text and interactive behaviour. The specification should name the intended conformance level, testing scope and responsibility for keeping content accessible after handover.

Technical SEO

SEO foundations belong in the architecture, not in a final pre-launch patch. The specification should cover indexable public pages, URL rules, title and meta-description controls, canonical references, sitemap.xml, robots.txt, multilingual hreflang, structured data, the 404 page and redirects. Google identifies three minimum technical conditions for indexability: Googlebot is not blocked, the page returns HTTP 200 and the page contains indexable content. Meeting them does not guarantee indexing, but a website cannot establish search visibility without the technical foundation.

Security

Security requirements should reflect risk rather than consist of one sentence saying that the site must be secure. Define authentication, permissions, session handling, input validation, upload restrictions, audit logging, updates, backups, incident notification and secret storage. For more complex projects, the OWASP Application Security Verification Standard can be used as a structured basis for security requirements and verification.

Analytics, privacy and consent

The analytics plan should be tied to the business objective. Define key events such as starting and submitting a form, clicking a phone number, completing a booking or making a purchase. Agree which tools will be used, who receives access and how tracking tags are managed.

If the website processes personal data, define the purpose, required fields, recipients, retention period and deletion process. Cookie and tracking technologies should be connected to appropriate consent management. Where necessary, a privacy specialist or lawyer should confirm the legal basis and notices; a developer cannot determine every legal ground for processing on behalf of the business.

Infrastructure, ownership and maintenance

Before development begins, establish where the website will run and who manages the technical environment. The specification should identify responsibility for the domain and DNS, hosting requirements, development and staging environments, SSL/TLS certificates, email delivery, backup frequency, restoration tests and monitoring.

Agree on ownership as well. Who owns the design files, source code, content, licences and third-party service accounts? The business should receive access and documentation sufficient to prevent the solution from depending on one person’s password or private account.

Maintenance means more than fixing defects. Define who installs security updates, monitors backups, responds to incidents and implements post-launch changes. Warranty defects, new features and routine content work should have separate rules.

Acceptance criteria and testing

A specification is complete only when it can be turned into an acceptance test. Every critical function needs an expected result. For example: after a valid form submission, the enquiry is saved in the CRM, the responsible person is notified and the visitor sees confirmation; if the connection fails, the record is not lost and an administrator is alerted.

The test plan should cover:

• functional and integration scenarios;

• mobile and browser checks;

• content and link review;

• accessibility tests;

• performance measurements;

• technical SEO checks;

• security checks appropriate to the risk;

• a practical CMS trial by content editors;

• backup restoration when it is part of the delivery.

State who performs each check, where defects are recorded, how priority is assigned and who gives final approval.

Schedule, responsibilities and change control

The schedule should include client decisions, content delivery, translation, testing and approval dates, not only design and development milestones. If content is delivered two weeks late, the original launch date cannot remain unchanged without another adjustment.

A simple responsibility matrix should show who makes business decisions, approves design, prepares content, supplies integration access and accepts the final work. One person should have authority to consolidate conflicting internal feedback.

The specification should also define the change process. A new idea is not a problem when the team assesses its effect on scope, price and timing. Problems arise when new functionality is treated as a clarification of the original requirement.

Vague and testable requirements

A practical specification structure

For most company websites, the following outline is sufficient:

1. Project context and business problem.

2. Objectives, priorities and success indicators.

3. Audiences and key user journeys.

4. Scope, sitemap and exclusions.

5. Content, languages, migration and owners.

6. Design direction, devices, prototype and review process.

7. Features, user scenarios and failure states.

8. CMS, roles, workflows and data model.

9. Integrations and data flows.

10. Performance, accessibility, SEO and security.

11. Analytics, privacy and consent.

12. Infrastructure, backups and maintenance.

13. Testing and acceptance criteria.

14. Schedule, responsibilities, deliverables and change control.

The document may be supported by a sitemap, content inventory, prototype, integration diagram and role matrix. The number of attachments matters less than whether the team can make consistent decisions without relying on different assumptions.

Who should prepare the specification

The client does not need to know every technical detail. The business understands its objectives, customers, internal processes and constraints. The delivery partner helps translate those needs into architecture, requirements and acceptance criteria.

The strongest specification therefore tends to emerge from a structured discovery process rather than a blank template. A template helps the team remember questions, but it cannot replace conversations with the people who will publish content, process enquiries and maintain the system.

Conclusion

A website technical specification is a decision document. Before design, it should establish the goal, audience, journeys, content structure and project boundaries. Before development, it should establish functionality, CMS behaviour, integrations, quality requirements, infrastructure and acceptance.

If two people can interpret a requirement in completely different ways, it is not ready. If it can be connected to a business need, designed, implemented and tested, it helps the project progress without avoidable rework.

When planning a business website in Latvia, you do not need to arrive with a finished technical document. A clear description of the current situation and desired outcome is enough to begin; a professional delivery process should turn that information into an implementable specification.