How do I brief a website designer?

You want a better website, so you start collecting screenshots of sites you like. The folder grows. It still doesn't tell the designer what your business needs the new website to do.

A useful brief connects the business, the buyer and the work to be delivered. You don't have to write a technical specification or decide the layout before speaking to someone.

What does a designer need to understand first?

Begin with the job the website has to perform.

A website brief should explain the offer, the intended buyers, the action you want them to take and the problems the current site creates. Content, constraints and references then help turn that purpose into a realistic scope.

Write the main situation in plain language. "People ask whether we serve commercial premises, but the homepage mostly shows houses" is more useful than "we need a premium digital presence".

Separate the problem from a preferred solution. You might think you need a video hero, but the underlying need could be to show the scale of your work. Let the designer evaluate how best to communicate it.

If the offer itself is hard to describe, use the homepage clarity questions as preparation. The designer should not have to infer the service from a competitor's website.

Which information belongs in the first brief?

Include what changes the decisions and the quote.

Start with a short working document, then fill gaps together.

Area	What to provide
Business and offer	What you sell, to whom and where
Website purpose	The main action and the problem you want solved
Content	Available copy, work examples, images and missing material
Functions	Forms, booking, editable sections and necessary connections
Constraints	Budget context, a genuine deadline and existing systems
Decisions	Who gives feedback and approves the work

You don't need a perfect answer in every row. Mark uncertainty honestly rather than inventing details to make the brief look finished.

For a hypothetical training company, "courses launch in March and we need course details editable by staff" establishes a real constraint. "Make it like this award-winning site" doesn't explain how enrolment or content will work.

How should you use design references?

Explain the quality you want to borrow, not just the URL.

Pick a few references and annotate them. You might like the readable service explanation on one, the quiet typography on another and the way a third shows project images.

Say what doesn't fit too. A dramatic animation may look interesting while distracting from a practical booking task. A luxury visual style may misrepresent a service built around affordability and speed.

Use this format:

I like the large work images because they let me inspect the detail. I don't want the long animated introduction. Our visitors need to find the service and contact details quickly.

The reference becomes evidence of a preference rather than an instruction to copy another business's identity or layout.

What real content should you collect?

Give the design something representative to work with.

Gather the longest plausible service name, a typical description, a genuine work example and the kinds of photographs you can supply. Identify any text that needs to be written or rewritten.

For images, record what each one needs to explain and which assets already exist. The website image guide gives you a brief for subjects, crops and placement before the designer builds a layout around missing material.

Placeholder content hides problems. A neat one-line heading doesn't tell you whether a real service name fits on a phone. A perfect sample image doesn't establish how your actual photos will crop.

List what you'll change after launch and how often. The need to update prices, team members or articles affects the editor; our guide to safe website editing explains what to agree.

Don't send account passwords in the brief. Note which systems exist, then agree an appropriate way to provide access when the project needs it.

If you know the website needs to change but don't yet have a formal brief, that's enough to start a conversation with Aruno. We can help agree the website's purpose, page scope and content responsibilities before designing and building it. Book a free intro call, or send your rough notes to hi@aruno.studio, WhatsApp or Telegram @mihaipostelnicu.

What should be settled before the design starts?

Turn the rough brief into an agreed set of deliverables.

Confirm the pages and page types, who supplies the words and images, what the forms do and which sections are editable. Identify any material the project is waiting for.

Agree how feedback is gathered. One person can collect comments from the team and resolve conflicting requests before the next review. That helps the designer respond to decisions rather than contradictory opinions.

Explain what the deadline means. An event date, a campaign launch and an internal preference have different consequences if content arrives late.

Ask the quote to reflect those decisions. Our website cost guide explains why scope matters more than a bare page count. Also agree the handover before work begins, rather than discovering missing accounts after launch.

Can you write the brief in one page?

A short brief works when it makes the important decisions visible.

Use these prompts as a starting document:

1. We sell this service to these people.
2. The website should help them take this next step.
3. The current problem is this, with these examples.
4. We need these pages, functions and editable sections, subject to scoping.
5. We already have this content and need help with the rest.
6. These references show the qualities we like and why.
7. These are our constraints, approver and genuine deadline.

Finish by asking the designer to explain the proposed scope back to you. Any important difference in understanding should be settled before the visual direction is approved.

Frequently asked questions

Do I need wireframes before hiring a designer? No. Describe the business problem and required content first. Wireframes can be part of the design work rather than something you must prepare alone.

Should I include my budget? Give useful context if you have it. It helps the provider recommend a realistic scope. A budget doesn't replace a written explanation of what the quote includes.

Can the brief change? Yes, but distinguish new information from additional work. Agree how a material scope change affects the price or timeline before it is built.

What if I only know that I dislike the current site? Collect specific examples of what feels wrong and what visitors struggle to do. The first conversation can help turn those observations into a clearer problem.

Does a clearer brief reduce the website cost? It can reduce uncertainty about the work, but it doesn't guarantee a lower quote. Use it to compare the same pages, content responsibilities and functionality across proposals.

How long should I spend preparing the brief? Start with the information you already know and mark the gaps. Send that first version before spending days polishing it; your designer can help decide which unanswered questions affect the scope.

Keep the screenshots, but write the business problem above them. That gives the designer something useful to solve.