How to write a restaurant website brief
A practical brief for an independent restaurant: decide what guests need, collect the right menu and booking information, and give your designer a clear starting point.
DS Agency · 20 September 2026 · Written with AI assistance
Start with the guest's next action
Before choosing colours or animations, write down what a guest should be able to do on the site. A neighbourhood restaurant may prioritise checking the menu, finding opening hours and reserving a table. A venue that hosts events may also need visitors to enquire about a private booking. Choose one primary action and a small number of supporting actions.
Illustrative example: 'Our main goal is to help guests understand the evening menu and use our existing booking provider. Private events should go to a separate enquiry form.' This is a useful instruction because it identifies two different journeys without prescribing a page design.
Record what the website will not do. If you do not offer delivery, say so. If online payments or gift cards are outside the first release, keep them out of the initial scope. These decisions help everyone compare the same project when discussing proposals.
Collect facts in one place
Create one shared document with the restaurant's exact name, address, telephone number, public contact email, opening hours and booking link. Include any different kitchen hours or service periods. Name the person responsible for confirming these details and checking future changes.
Provide the actual menu in editable text as well as any existing designed version. Keep dish names, descriptions and prices separate so that they can be updated without rebuilding an image. Dietary and allergen information must come from the restaurant's verified records; a designer or writing tool should not infer ingredients or make claims from a dish name.
List the languages guests need. Supply approved translations or state that translation is a separate part of the project. A multilingual site also needs a plan for keeping prices, opening hours and seasonal information consistent across languages.
Decide how the menu will be maintained
A menu built as page content can be read and navigated without opening a separate document. A PDF can preserve a printed layout and may be useful as an additional download. If the restaurant changes its menu often, explain who will update it, how frequently and from which device.
Ask the designer to show the update process with one realistic example: changing a dish, a price and a service time. A system that looks convenient in a demonstration may still be unsuitable if the staff member responsible cannot use it comfortably.
Keep the first version proportional to your needs. A small seasonal menu may not need a complex content system. A restaurant group with several locations and different menus needs a clearer content structure. Put this difference in the brief before choosing the software.
Give photographs a clear purpose
Separate available photographs into food, interior, people and exterior. An exterior photograph can help a first-time visitor recognise the entrance. An interior photograph can communicate the setting, while a food photograph should accurately represent what the restaurant serves.
Provide original files where possible and identify which images you have permission to publish. Note any restrictions, credits or people whose permission must be checked. Avoid asking the designer to copy images from another restaurant's site. If new photography is needed, make it a separate deliverable with a named owner.
Include a small selection of references and explain what you like about each one: readable menus, simple booking, a warm tone or clear location information. 'Make it like this website' leaves too much undefined; a specific observation gives the designer something useful to interpret.
Describe the booking and enquiry journey
If you already use a booking provider, include its public link and explain whether you want to link out or explore an embedded booking experience. Do not place account passwords in the brief. Access can be arranged separately if the chosen implementation needs it.
For each form, specify the destination and the person who will monitor it. Decide which information you actually need to respond. A private-event enquiry might need a date, approximate group size and contact details; a general enquiry may need less. Keep response-time promises consistent with how the restaurant really operates.
Plan a real submission test before launch: send a test message, verify that it reaches the intended recipient and check what the visitor sees afterwards. A confirmation screen alone does not prove that the enquiry arrived.
Agree on what a complete handoff means
Ask for a proposed page list, the content each side will provide, the number of review stages and the process for requesting changes. Record the target date and anything that can delay it, such as missing menu translations or photography. Ask for hosting, domain and ongoing maintenance responsibilities to be explained separately.
Before accepting the site, check it on an actual phone. Read the menu, find the opening hours, follow the booking link and submit an enquiry. Check that navigation can be used with a keyboard and that essential information is readable without relying on animation. Keep a written list of issues and confirm who will resolve them.
The completed brief should make decisions clearer, not remove every future conversation. When a requirement is uncertain, label it as an open question and ask the designer to explain the options and their practical tradeoffs.
Your working checklist
- Write one primary guest action and the supporting actions.
- Confirm the address, contacts, opening hours and kitchen hours.
- Supply an editable menu with approved prices and descriptions.
- Provide verified dietary information without inferred claims.
- Choose the required languages and the owner of future updates.
- Collect original photographs and check publication permissions.
- Confirm the booking provider and destination for each form.
- Agree on pages, responsibilities, review stages and handoff access.
- Test the full guest journey on a phone and verify receipt of a real test enquiry.
About this guide
This is general project-planning guidance, not a forecast of traffic or sales. Examples are illustrative. The agency links below describe our services and portfolio; they are not independent research validating every recommendation.