The short answer
Before commissioning a website, decide who it is for, which questions it should answer and what visitors need to do. List the pages, the content already available and the people responsible for supplying anything missing. Your logo and a few websites you like are useful references. A clear brief goes further: it explains the customer or business problem the new site should solve and which work belongs in the first release.
You don't need to know all the technical details to prepare. It's more important to explain how your business works, what questions customers are asking, and where you're struggling with the current process. Your developer can use this information to recommend a suitable technical approach. Deciding only on the platform to be used at the beginning can lead to overlooking the real need.
In this guide, you can find out what information you need to collect for a new site and how to organise it. If you are revamping your existing site, you can use the same list and also add pages and data that need to be preserved. The aim is not to create a thick file, but to make decisions that will affect the project visible early.
Define the business goal first
“We want a more modern website” indicates a design direction, but does not describe the business goal. More concrete goals are to receive more relevant customer enquiries, promote a specific service, or reduce the time the team spends on repetitive questions.
Identify a main goal and several needs that support it. For example, a consulting business may want to receive consultation requests from suitable companies. In that case, clear service descriptions, relevant projects and the enquiry form should take priority. Regularly publishing content is recorded as a separate management need.
When making the goal measurable, don't make up numbers you don't have. If you do not know the current number of enquiries, you can set up a simple enquiry log first. In the first stage, a realistic starting criterion is that the form works reliably and the incoming enquiries can be evaluated.
Identify your target customer with real questions
It may not be enough to describe the customer only in terms of age, sector or company size. Also write down what problem they need to solve, what they ask before deciding and what makes them hesitate. Sales calls and incoming emails are valuable materials for this study.
For example, if customers constantly ask about delivery time, a process explanation is required. If they can't tell how your services differ from each other, a comparative section can be helpful. A question about price often includes uncertainty about what is included. A “get a quote” button alone does not resolve that uncertainty.
If you have two different customer groups, do not combine them with the same message. Small businesses and corporate purchasing teams may look for different details for the same service. You can plan separate sections that support each group's decision while preserving common information.
Build your page list around user tasks
Don't start the page list by copying the menu from a competitor's site. List the tasks the visitor will do first: understand the service, evaluate its suitability, see examples and get in touch. Then determine which pages will support these jobs.
The home page does not have to carry all the details. Service pages can explain the scope, project case studies can demonstrate the work delivered, and frequently asked questions can resolve recurring uncertainties. Having a separate task for each page reduces content repetition.
Prepare a table at the beginning. Page name, visitor's question, required content and responsible person columns are sufficient. Also mark pages that are not ready. This reveals missing content before it holds up the design work.
Collect brand files in a usable format
Find the original files of the logo instead of just sending a small image taken from the messaging app. Light and dark background options, colour codes and font information, if any, should be shared together. If there is brand guidelines, include it too.
Specify which of the old files is current. Having too many similar logos in a folder may result in the wrong version being used. Organising files with clear names seems like a small task, but it reduces repetitive editing.
If your brand identity has not yet been established, do not hide it. If logo, colour and language decisions need to be made during web design, the scope should be prepared accordingly. Applying a ready-made identity to the site and developing the identity from scratch are different efforts.
Write around your customers' questions
You can share your existing brochures and presentations, but don't assume they will be direct web copy. The website visitor usually scans sections before reading closely. Headings should describe the question, paragraphs should be short, and important information should be easy to find.
For each service, collect the following information: the purpose of the service, who it is suitable for, what is included, and what information is required in the first step. Put a concrete explanation next to adjectives such as “quality, innovative and reliable”. Detail is needed so that the visitor can evaluate their own situation.
Who will verify the text is as important as who will write it. Even if the marketing team prepares a service description, the operations team may approve the scope. A single content lead should consolidate disparate opinions and deliver consistent feedback to the design team.
Select images and evidence of your work
Visuals should help understand what the business does. Instead of including a generic stock photo in each section, consider examples of real work that can be used. A process photo, team photograph, or annotated project screenshot can provide more context.
Do not use screens containing customer documents or personal information that you do not have permission to share. Sensitive details should be hidden, preserving the purpose of the example. If the visual of an interface is just a design example, it should not be promoted as a working product.
Write a short description for each file: what does it show, which project does it belong to, where can it be used? This information facilitates visual selection and preparation of accessible descriptions. It is more useful to create a selected, annotated archive rather than submitting a large folder.
Explain functions with concrete scenarios
Instead of “Let there be a form,” explain what the form will do. Who will fill it out, what information will they provide and where will the submission go? What will the user see on a failed submission? These details help determine both the design and technical scope.
If an appointment, calculation, or customer login is required, write a sample transaction. Describe the steps the user takes from starting point to completed task. If there is a system in use, specify its name, the person responsible for access and the integration required.
Separate future features from initial release requirements. One day you may want to open a customer portal; however, if the process to be used is not clear at the moment, it may not be necessary to develop it immediately. Share your future plans, but include only the features you need now in the initial brief.
Distinguish between languages and markets
Publishing content in English is not the same as offering an international service. Clearly define in which countries, in which languages and under what conditions you can work. The language option on the site should be compatible with the actual communication capacity of the business.
Write down who will prepare the translation and which person will do the proofreading. Don't forget small text like menus, forms, error messages and emails. The customer should not encounter an error message in English when submitting a form from a Dutch page.
You may not need the same number of pages in every language. However, equivalents and language transitions of published pages should be planned consciously. Incomplete translations or language buttons that lead to an irrelevant page can make it difficult for the visitor to finish what they started.
If an existing site is being revamped, what should you protect?
List current page addresses, important content, and pages that generate enquiries. These assets should not be accidentally lost while the design is being renewed. New site preparation includes not only what will be added in the future, but also what is of value today.
Find out who has domain, hosting and admin panel access. Instead of sharing passwords on public files, choose a secure access method. Clarifying account ownership and permissions reduces delays at launch.
If a change of address is planned, new equivalents of old pages should be determined. Google's site migration guide is the go-to technical resource for planning URL changes. Don't see this as a minor tweak to be made on the last day.
Prepare the schedule and feedback process
When stating the target date, also explain why. If there is a connection such as a trade fair, product launch or contract deadline, the team can evaluate priorities more accurately. “As quickly as possible” is not enough to determine which task will be completed first.
Choose from the beginning who will evaluate the design within the business. Let one person collect feedback and resolve conflicting opinions. Incompatible comments coming from different channels may cause decisions to be reopened again and again.
Also allow time in the calendar for review and approval. The customer's response, as well as the work of the design team, affects the progress of the project. If new requests come at a stage awaiting approval, the scope and schedule should be re-evaluated together.
Determine in advance what you will check on delivery
The phrase “site completed” should have a common meaning. Publishing the necessary pages, operation of the forms, control of the mobile view and delivery of administrative access can be written as separate items. Thus, the possibility of new expectations arising in the last meeting is reduced.
If your non-technical team will be updating content, set a test task. For example, adding a new project or changing working hours. When a member of the team completes the process, it becomes clearer whether the delivery is suitable for daily use.
Also discuss post-launch support scope. A bug fix should be distinguished from a new feature request. It should be clear how support requests will be submitted, where access will be kept, and who is responsible for regular checks.
What you need in your project brief
| Topic | Information to be prepared |
|---|---|
| Purpose | Main business objective that the site will support |
| Customer | Basic questions to ask before making a decision |
| Content | Pages, texts and authors |
| Brand | Current logo and usage rules |
| Function | Sample actions for the user to complete |
| Schedule | Target date and person to approve |
| Delivery | Tasks to test and access permissions to hand over |
Test the brief against a customer task
Select a single sample visitor to see if the information you've collected is sufficient. Let's say this person is researching a specific service offered by your business and wants to know the scope before making a decision. Can the answer to this question, the appropriate project example and the contact step be found in your project brief? If it cannot be found, what is missing may not be a new page but specific information.
Do the same experiment for the teammate who will manage the content. When a new service is added, who will write the text, who will approve it and who will publish it? If these tasks are unclear, you need to discuss the content management requirements as well as design. The daily usage scenario shows early the challenges that may arise after delivery.
Finally, have the people who will attend the first meeting read the file. If you see that everyone explains different goals, talk about this before the project starts. Agreeing on a common goal reduces re-opening of the same discussion during design. The most important function of the preparation document is to gather the expectations within the business around a shared understanding.
Clearly mark missing information
Not every detail in your project brief needs to be finalized. However, one must distinguish between approved information and decisions just discussed. If the name of a new service is unclear or the scope of a second language is still being discussed, write this clearly. The design team should not proceed by taking these areas for granted.
Identify the person who will make the decision for each uncertainty. This way, when a question arises, it is known who will answer it within the organisation. This simple structure reduces unnecessary meetings and conflicting answers from different people. The quality of preparation is seen not only in the quantity of files but in the traceability of decisions.
Get ready for the first meeting
Collect the information you have prepared in a single folder and clearly mark what is missing. Instead of waiting months to get everything perfect, complete the basics for decision-making. Good preparation is not about hiding uncertainties, but about making them solvable together.
You can review Pixel's web design service and share your needs summary on the contact page. Adding the link to your existing site, if you have one, and the three points you find most difficult will help the conversation start from a concrete place.
Frequently asked questions
Can we start before all the texts are ready?
An initial discussion can take place, but the main service descriptions should be prepared early to bring the design closer to the actual content. If the length and structure of the content change late, the design may also need to change. If text production is within the scope of the project, those responsible and delivery dates should be determined from the beginning.
Is it enough to send competitor websites I like?
Examples are useful, but you need to explain what you like. Mark specific features such as menu structure, readability or project presentation. Copying the entire structure of another business may not suit your customer's questions.
Do I need to choose the technical platform?
No. You can explain the business needs first. Ask what the proposed infrastructure means for content management, maintenance, and development. Expect the choice to be explained by your business needs, not just the technology name.
