Contents of the article

Website project brief: example content, scope, and checklist

Oura Works

13 minute read

Illustration of a flow example — preparing the brief and prioritizing the scope

A website project brief explains the business objectives, initial conditions, users, scope, dependencies, and how to receive the results of the work. This document helps internal teams and service providers discuss the same project before selecting a design or comparing bids.

The phrase “we need a modern website” is not enough to estimate the work. A company website with five pages of information has different needs than a bilingual CRM-connected catalog. Both may look simple from the outside, but the materials, management, access and inspection are different.

You don't need to know all the technical details before creating a brief. Start with clear business decisions. Highlight areas that still need to be explored, then use the initial discussion to complete the information. The following guide is Oura's recommended work; company examples and project content are simulations.

Summary before requesting a quote

Describe the problem you want to solve and important visitor actions.
Inventory of pages, materials, domains and systems that have been used.
Separate mandatory requirements, options, and work pending inspection.
Determine material ownership, access, decisions, and acceptance of work results.
Include a time limit along with the business reason.
Compare offers across similar scope, assumptions and deliverables.

1. What is the difference between a brief, proposal and acceptance criteria?

The brief comes from the needs of the project owner. The proposal describes the work the provider is offering, including scope, estimates, dependencies, and terms that need to be agreed to. Acceptance criteria describe how the team checks that the promised deliverables are available and functional.

The three complement each other. The brief may state that the customer needs to request a quote for some product. The proposal then explains whether the feature uses an RFQ cart, a per-product form, or another method. Acceptance criteria define the scenarios that must be successful in the option.

Don't assume a wish list in a brief automatically translates into price-inclusive work. Ask the provider to indicate needs that are in the bidding, those that are not yet in place, and those that require additional information. These notes help avoid differences in expectations once the project is underway.

Documents	Questions answered	Example content
Briefs	What does the business need?	Buyers can send requests for multiple products
Proposals	What jobs are offered?	Catalog and RFQ form according to scope
Acceptance criteria	How are results checked?	The selected item is received by the destination system correctly
Change log	What changed after the deal?	Adding a new language or goal system

2. How to explain the goals and initial conditions?

Start with a paragraph about the business: key services or products, markets, service areas, and sales channels. After that, write down the current website problems with examples that can be checked. “Customers often don't understand the differences in service” is more helpful than “website is not good”.

Include URLs, relevant pages, and information that is not yet available. If there is visit or inquiry data, explain the period and definition. The number of contact clicks is not necessarily the same as the number of sales conversations. Guide GA4 lead measurement helps differentiate these stages.

The project goal should be to link the problem to the results of the website's work. For example, buyers can compare two services and choose the right consultation route. Sales targets can be a business context, but don't make them the only way to receive development results: sales are also influenced by offer, market and follow-up.

Also include things that have worked well. Technical material that customers trust, pages with relevant inquiries, or efficient admin flows can be maintained. This information prevents new projects from eliminating capabilities that are still needed.

3. Who are the users and actions that need help?

Group users based on needs, not just age or job title. On a B2B website, operations people might look for specifications; procurement looks for delivery capabilities and procurement processes; leaders assess the suitability and risks of investments. They can read the same page with different questions.

Write down the main actions for each group: view specifications, download materials, request a demo, send an RFQ, or contact the team. Choose actions that the business can follow up on. The “schedule demo” button requires a schedule owner as well as a clear confirmation process.

If user information is not yet available, mark it as hypothetical. You can review sales inquiry notes or have conversations with potential users. GOV.UK interview guide explains the use of open-ended questions and real-life experiences. Adapt the method to your business research needs.

In the brief, the research results can be summarized as questions that the website must answer. The design team then has a basis for organizing information, rather than guessing what buyers will find interesting.

The goals and needs of the reader direct the brief and structure of the website. — Example of brief materials before design. Panels are illustrations, not summaries of client projects.

4. How to create a page list without locking the design?

Create an inventory of pages by function. For each page, describe the reader, key information, evidence, and next action. This list helps assess the contents and needs of the template before discussing the final appearance.

Separate the number of pages from the number of unique designs. Ten services may use one page pattern with different content, or require several patterns because the type of information is different. Mention both needs when comparing offers. The number of pages alone does not describe the entire work.

Mark relationships between pages. Articles can answer initial questions, service pages explain offerings, and case studies provide context for the work. Visitors need to be able to move to the next piece of information via relevant links. Read business website structure to organize this relationship.

Briefs may include visual references along with reasons: order of information, navigation, or how to show the product. Avoid “make exactly this” instructions without explaining the need; a structure that is suitable for one business model may not be suitable for your processes.

Page layout separates issues, services, evidence, and reader actions. — Example of page function inventory; does not lock the design or force every project to have the same structure.

5. What materials need to be prepared?

Inventory of copies, official logos, photos, specifications, videos, documents and evidence that may be published. Note the owner and status of each. Existing materials may not be ready to appear: photos may require permission, service information may need to be checked, and documents may contain data that should not be made public.

Explain who wrote and approved the copy. If the provider assists with writing, the business team still needs to provide facts, scope limits, and sources of expertise. Technical terms and product information should be checked by someone who knows them.

Material	Example status	Responsible person	Decision before release
Official logo	Available	Brand team	Versions and usage rules
Services page	It needs to be written	Marketing and service expert	Facts and coverage limits
Job photos	Needs to be reviewed	Project owner	Permission for publication and information
Product specifications	Partially available	Product team	Latest document version
Case studies	Anonymous	Delivery team	Source, period, and permission

Make this list part of your schedule. If important content is incomplete, choose whether to wait for the job, use marked temporary content, or limit initial launch. These decisions need to be visible to the entire team, not just tucked away in conversation.

6. What information is required for integration?

Write the system name, account owner, connection destination, data transferred, and success conditions. “CRM integration” could mean sending new inquiries, updating contacts, labeling sources, or synchronizing multiple directions. Each has different inspection needs.

Attach available API documentation and permitted access limits. Mention any licenses, vendors, or package features that may be dependencies. If it is not yet known, write “needs examination”, not “definitely can be connected”. Examples of data for briefs are simply field names and formats; Customer personal data is not required.

Also discuss failure conditions: destination system not responding, data incomplete, repeated delivery, or changed credentials. Determine who receives problem notes and how the process is tracked. This design helps differentiate connections that simply send from processes that can be managed.

For forms, differentiate the submit click from the system's acceptance of the request. Analytics tracking follows agreed success conditions. Identity data for CRM follow-up is not automatically an acceptable parameter to send to analytics services.

The website form passes event recording and receipt to CRM and the sales team. — Examples of integrations that need to be written in the brief. Fictitious entries in the panel are not real prospect data.

7. How to include migrations and old websites?

Note domains, hosting, CMS, important URLs, forms, download files and available access. Notify the provider if the domain or infrastructure is managed by another vendor. Changes require coordination with the owner of that access.

If the URL changes, set up a mapping of the old page to the new destination. Google migration guide discusses URL mapping, redirects, and post-move monitoring. Migration can also introduce temporary search fluctuations; changes need to be planned and checked.

In the brief, specify the content that is moved, archived, or no longer used. Avoid redirecting all old URLs to the homepage just because it's faster. Transfer destinations should follow the relevant replacement page if available.

Define backup processes, review environments, move times, and release decision owners. Rollback notes need to describe the trigger conditions as well as their recovery capabilities. Don't use the word “backup” as a substitute for talking about what is actually saved and can be restored.

8. How to divide mandatory requirements and options?

Separate initial launch work from subsequent development. Mandatory needs are functions that are necessary for the initial purpose; option to help with additional work; Uncertain dependencies require examination before final estimates.

Use business reasons for each priority. The catalog may be mandatory because sales sends the link every day. The advanced search feature can be an option if there are still few products. Two-way integration can be delayed if there is no operational process owner.

Simulation needs	Priority	Reasons or dependencies
Service page and RFQ	Initial launch	Support request for quote
Content management by admin	Initial launch	The team needs to update the material
Additional languages	Separate options	Translated materials are not yet available
Two-way CRM sync	Needs inspection	API and duplication rules have not been confirmed
Customer account area	Next stage	Users and access rights need to be researched

Priority is not a promise that options will be cheap to add later. Ask the provider to explain technical decisions that may impact subsequent development. That way, you understand the consequences of choosing a limited launch now.

9. Who makes decisions and how is the schedule drawn up?

Assign one coordinator from your team, then explain who checks the facts, designs, systems, and final results. Several people can provide input, but conflicting decisions need to be resolved before being presented to the production team.

Include important dates and the business reason: exhibition, campaign, domain transfer, or registration period. After that, check material dependencies, access, approvals, and testing. A release date without dependency readiness is not yet a reliable work schedule.

Agree on how to collect feedback: a list of notes, pages or versions reviewed, owner of the feedback, and completion status. Distinguish corrections to agreed needs from new needs. Scope changes need to discuss their impact on work, cost, and schedule.

For investments, you can provide ranges you are comfortable discussing or ask for options based on priority. Compare what is acceptable under each option, third party costs, support requirements, and what is still subject to inspection. The cheapest nominal does not explain all project responsibilities.

The brief goes through review, staging, and handover before the work is completed. — Example of sharing decisions and examinations. The flow needs to be adjusted to the project scope.

10. How to write acceptance and handover criteria?

Acceptance criteria use verifiable scenarios. Avoid just “catchy design” or “good SEO.” For example: product information appears according to approved material; the form sends the correct fields to the destination system; editors can update content according to role.

W3C WAI discusses labels, instructions, validation, and notification of results on forms. Include relevant checks on project requirements. Using a checklist alone does not prove that all websites meet a certain level of compliance.

Example criteria	Examination scenario	Recipient of results
Inquiry form	Success, failure, and resubmission	Operational team
Product page	Material, variants and links according to the brief	Product team
Content management	The editor role updates the permitted content	Website admin
URL switching	Important URLs to replacement pages	Website team
Important event	Recorded on agreed success conditions	Marketing and developer

The handover explains access, documentation, deliverables, and post-release responsibilities. Include who manages the domain, hosting, CMS, licensing, backups, and content changes. Continued support and improvements need to follow the agreement, not the assumption that everything is included forever.

Pages are reviewed on desktop, tablet, and mobile with form and performance checks. — Example of acceptance criteria review. Drawings are not proof that all requirements of a project have passed the test.

11. Example of a concise brief for a service company

Implementation services companies need websites that help prospective clients compare services and send RFQs. The initial condition is a short company profile, while specifications and process explanations are still sent by sales separately. Simulation:

Initial goal: provide a service page with scope, process, anonymous proof, FAQ, and request a quote action. Primary users: operational teams, procurement, and decision makers. The first launch includes a homepage, three services, about the company, case studies, as well as an RFQ form.

Materials are prepared by marketing and checked by service experts. Domains are managed internally. CRM integration becomes an option after API documentation is reviewed. Acceptance criteria include material suitability, RFQ flow, editor rights, and accepted inquiry measurements.

This brief has no set price or duration. Providers need to assess design requirements, system condition, material readiness, and inspection scenarios before preparing a proposal. Use the format as a framework, then adapt it to your business conditions.

Decision example: contact form connected to CRM

The text “CRM integration” does not yet explain when the work was accepted. The brief needs to mention the valid sending point, the data being transferred, the recipient, and the behavior when the destination service fails. These details are formulated together with those who manage the system, with access as needed.

Example conditions	Behavior that needs to be agreed upon	Proof of receipt
The form is valid and the destination is accepted	Record the inquiry and display confirmation	Test recording on permitted systems
The destination cannot accept	Handle failures according to process	Does not display false success
User resubmits	Review the duplication rules	Results according to agreed definitions

This example does not define a universal technical architecture. The choice of queue, retry, or manual process follows the system and scope. Importantly, the criteria can be observed by business as well as technical teams. Don't ask vendors to send personal data to Analytics just to prove that the integration works.

Checklist before the brief is distributed

The business profile and main problems have been explained.
The purpose of the website is related to user actions.
Users, questions and information needs are mapped.
Pages and materials have clear owners.
Mandatory requirements, options, and dependencies are separated.
System integration as well as inspection permits are recorded.
Old website URLs and accesses are inventoried.
Schedules have known reasons and dependencies.
Coordinators and approvers are appointed.
Acceptance criteria use concrete scenarios.
Access and responsibilities after release are discussed.
Uncertain sections are marked for discussion.

Conclusion: make the project easy to understand before working on it

Useful briefs provide direction to decisions without pretending to know all the technical answers. When objectives, materials, dependencies, and checks are clear, conversations with providers are more productive and offers are easier to compare.

If you want to review the completeness of the requirements, discuss the website brief with Oura Works. We can help formulate the work based on business conditions and priorities, then discuss the scope through a proposal.

FAQs

Is it necessary to design before creating a brief?

Not necessarily. Describe users, information, actions, and references along with reasons. Designs can be drawn up once the needs are understood. If you already have a design, attach the version and parts that are still open for changes.

Can a project be started when the content is incomplete?

It can be discussed, but the status of the material affects the work. Determine who writes, who checks, and when the material is ready. Temporary content needs to be marked so that it is not considered an approved public copy.

How do you state your budget if you don't know the price?

Describe investment priorities and limits that are comfortable to discuss if available. You can also request multiple scope options. Request a quote separating work, third party costs, assumptions, and undetermined needs.

How to determine the number of revisions?

Discuss the review stage, the outputs examined, how feedback is collected, and the rules for changing requirements. The number of revisions alone does not explain whether a submission is a correction or a new scope addition.

Who should manage the domain?

Determine the account owner and the party managing it through agreement. The business team needs to know access, validity periods, payments, and the transfer process if managers change. Don't leave responsibilities unclear.

When may project estimates change?

Estimates may change as requirements, amount of material, integration, access, or review schedule change. Have changes recorded and their impact before additional work is undertaken, so the team has a common basis for decisions.