How to brief a web design agency: what to prepare before you start

Here is how it happens: vague requirements produce assumptions, assumptions produce the wrong thing, changing the wrong thing costs more than building it right the first time would have. Research from the Project Management Institute puts poor requirement gathering as the leading cause of project failure in 37% of cases. The brief is where that failure starts — or where it’s prevented.

This guide is for anyone about to hire a web studio or agency, particularly if it’s your first time or if a previous project didn’t go the way you hoped. It covers what to decide before you make contact, what a good brief actually contains, and how to evaluate what you get back.

Before you contact anyone: decisions to make first

The brief doesn’t start when you open a document. It starts with a set of internal decisions that most clients skip — and then wonder why the proposals they receive don’t quite fit.

What should the website actually achieve? Not “improve our online presence” — that’s not a goal, it’s a direction. A goal is: generate qualified inbound leads for our branding service, reduce the number of discovery calls we need to take by letting clients self-qualify through a configurator, drive direct bookings for photography sessions. The more specific the goal, the more the agency can design toward it.

Who is the site for? Not “everyone.” A site designed for everyone is optimised for no one. Think about who your primary visitor is, what they’re trying to find out, what device they’re probably on, and what would make them take the action you want them to take. If you have two very different audience segments, name both and decide which one the site prioritises.

What’s your budget — honestly? We’ll come back to why hiding this backfires. For now: have a number in mind before you start talking to agencies.

What’s the real timeline? And separately: is there a hard deadline (product launch, event, funding round) or is it just a preference? These are different things and they affect how the agency resources the project.

Who is writing the content? This is the question most clients answer too quickly. “We’ll handle it” means something very specific — someone in your team is going to produce finished, publication-ready copy on a schedule that fits the project. If that’s genuinely true, great. If it’s aspirational, it will delay your project. More on this below.

What are your technical requirements? Existing CRM, booking system, email marketing platform, payment gateways — anything the new site needs to connect to needs to be named upfront, not discovered halfway through development.

What a good brief actually contains

A brief is not a wishlist. A wishlist is “we’d like a blog, a client portal, live chat, multilingual support, and an integrated CRM.” A brief is a document that makes clear what the project is for, what it must do, what it must not do, and what success looks like.

The essential sections:

• Company overview. Two or three paragraphs: what the business does, who it serves, what makes it different. This isn’t marketing copy — it’s context for the agency to make decisions that fit your business, not a generic one.
• Project goals and KPIs. What the site needs to achieve, expressed as measurable outcomes. “Increase contact form submissions by 25% within six months” is a goal. “Get more leads” is not.
• Target audience. Who visits the site, what they need, what would make them act. If you have data — analytics, customer research, even just a clear picture of your typical client — include it.
• Scope of work. The page list. Every page or template you need, with a note on functionality (contact form, configurator, booking calendar, product listings). Crucially: what is out of scope for this phase. This is the single most important thing for preventing scope creep.
• Design direction. Reference sites with notes on what specifically you like about them (not just “this one”). Brand assets you already have. Any hard rules (colours that must appear, things that must not).
• Content plan. Who writes what, by when. Photography: existing, stock, or new shoot?
• Technical requirements. Platform preference, integrations, hosting situation, analytics and tracking setup, GDPR/cookie consent, accessibility requirements.
• Budget range. A range, not a precise number. Enough for the agency to scope appropriately.
• Timeline. Target launch date and any hard external deadlines.
• Decision-making process. Who approves what, and how feedback will be collected and delivered. One point of contact is worth specifying here.

The budget conversation

Clients hide their budget for an understandable reason: they’re worried the agency will charge exactly that amount, regardless of what the project actually requires. This logic backfires in practice.

When an agency doesn’t know your budget, they do one of two things: they scope a project that’s too large and propose something you can’t afford, or they underscope and you end up with change requests that exceed what a transparent budget would have cost. Neither outcome helps you.

Sharing a budget range doesn’t mean the agency charges the maximum. It means they can tell you what’s realistic within that range and propose the right approach — a template-based build if the budget is modest, a custom design if there’s room for it, a phased approach if the goals exceed what the budget can cover at once.

If you genuinely don’t know what things cost, use a configurator to get a ballpark before your first conversation. Our instant quote tool for websites and online stores are built exactly for this — you get a real number based on what you actually need, before committing to anything. We’ve also written a detailed guide to what a website costs in Sweden if you want the full market picture first.

How to communicate what you want visually

“I like Apple’s website” is not a design brief. It’s a starting point for a question: what specifically about Apple’s website do you like? The typography? The white space? The way the product photography is used? The scroll behaviour? The simplicity of the navigation?

That specificity is what the agency needs. Not to copy the reference site — to understand what visual and experiential qualities matter to you.

The most useful thing you can do is compile a small mood board — five to ten references, each with a note on what you’re pointing to. Layout structure, colour approach, typographic tone, photography style, the way calls to action are handled. Figma, Pinterest or even a simple shared folder works fine.

Brand assets to have ready before you start:

• Logo files in vector format (SVG or AI — not a PNG or JPG from your email signature)
• Brand colours as HEX codes, not “the blue from our business card”
• Fonts, ideally with licences that cover web use
• Any existing brand guidelines document

If you don’t have these — if your “brand” is a logo someone made in Canva five years ago — that’s worth knowing before the web project starts. Building a website without a coherent visual identity means the designer has to invent one as they go, which is inefficient and produces a worse result. Brand before website is almost always the right sequence. We’ve written about what brand identity actually is if you’re weighing up whether to address this first.

Content: the part that delays almost every project

Content is the single most common cause of web project delays — by a significant margin. Not technical problems, not agency capacity, not revisions. Content.

The reason is structural. Design is built around content. If the copy isn’t written, the designer uses placeholder text, builds layouts around it, and then the real copy arrives and it’s twice as long, half as long, or structured completely differently. Everything needs adjusting. Development gets pushed. The launch date moves.

The brief needs to answer three things about content:

Who writes the copy? If it’s you or your team, be honest with yourself about whether that will actually happen on schedule. If it’s the agency, it needs to be in the scope and the budget. If it’s a freelance copywriter, they need to be briefed in parallel, not after design starts.

Where do the images come from? Stock photography is quick and inexpensive but generic, and generic imagery undermines good design faster than almost anything else. Custom photography takes planning and budget but produces something that actually looks like your business. The brief should specify which path you’re taking. (We’ve written about why professional photography pays for itself — the short version is that it makes everything else perform better.)

Who handles SEO? Keyword research, content structure, meta tags, URL architecture — these need to be planned before design starts, not added as a last step before launch. Decide in the brief who owns this, because if it’s assumed it will sort itself out, it won’t.

Technical requirements: what to flag upfront

The brief should name every system the website needs to connect to. Surprises here are expensive — an integration that wasn’t mentioned until development week three means scope change, cost change, timeline change.

For businesses in Sweden, flag these specifically:

• Swish — if you’re selling to Swedish consumers, Swish Handel is expected. Requires a direct bank agreement, not just a plugin.
• Klarna — standard for e-commerce checkout in Sweden; plan for it from the start.
• BankID — if you need secure login or digital signing, this has specific technical requirements.
• GDPR and cookie consent — non-essential cookies (including Meta Pixel and Google Analytics) must be blocked by default until the user explicitly accepts. This needs to be built in, not retrofitted. IMY has issued fines of 37 million SEK for non-compliant pixel setups.
• Accessibility (EAA/WCAG 2.2 AA) — legally enforceable since June 2025 for most commercial websites in the EU. Keyboard navigation, sufficient colour contrast, screen reader compatibility. Not an overlay widget — built into the theme. Micro-enterprises (under 10 staff and under €2M turnover) are exempt from the service layer, but worth knowing either way.

Also state: who owns the domain, who manages hosting, what analytics are already in place, and whether migration from an existing site is part of the project.

Vague vs clear: examples

How to evaluate proposals you receive

A good proposal is specific. It names the pages, the features, the timeline with milestones, the tech stack, the team who will actually do the work, and what happens after launch. It addresses the goals you stated in your brief, not a generic version of a website project.

Red flags to watch for:

• No mention of staging environment (updates tested live = avoidable crashes)
• Vague post-launch support (“we’ll be available if you need us” is not an SLA)
• No clarity on who owns the files, source code, and accounts at the end
• Work described as done by the agency that’s actually subcontracted without disclosure
• No timeline broken into milestones — just a single delivery date

And the one that looks like a green flag but often isn’t: the cheapest proposal. A low price means something was left out of scope, the work will be rushed, or the quality ceiling is lower than you need. We’ve written about why cheap websites cost more in the long run — the same logic applies to proposals.

Ask before you sign: does IP transfer to us on final payment? What’s the warranty period for post-launch bugs? How are client-caused delays (late content) handled contractually?

Giving feedback that actually moves the project forward

Once the project is running, the brief becomes the reference point for every decision. Design feedback should be anchored to it.

“I don’t like this” is not useful feedback. “This layout puts the contact form below the fold, which conflicts with our goal of increasing form submissions” is useful feedback — it’s specific, it’s tied to a goal, and it gives the designer clear direction.

Consolidate feedback internally before sending it. Multiple stakeholders sending contradictory comments at different times is one of the most efficient ways to slow a project and frustrate a creative team. One round of consolidated, prioritised feedback is worth ten rounds of ad-hoc reactions.

Changes that are outside the original scope — a new page, a feature that wasn’t in the brief, a significant shift in direction — are change requests. They affect the timeline and budget. A good agency will flag this clearly and propose how to handle it; a good client won’t be surprised when they do.

The brief checklist

Before you contact an agency, you should be able to answer all of these:

Goals and audience:

• What should the site achieve, in measurable terms?
• Who is it for, specifically?
• What’s the single most important action a visitor should take?

Scope:

• What pages and features are in scope for this phase?
• What is explicitly out of scope?

Brand and design:

• Do you have vector logo files, hex colour codes, and licensed fonts?
• Do you have 3–5 reference sites with notes on what specifically you like?
• Is your visual identity ready, or does branding need to happen first?

Content:

• Who writes the copy, and when?
• Where do images come from — stock, existing, or new shoot?
• Who handles SEO — agency, client, or third party?

Technical:

• Platform preference?
• What systems does the site need to connect to?
• Who owns the domain and hosting?
• What analytics and tracking is in place?
• GDPR consent and accessibility requirements?

Project governance:

• Who is the single point of contact on your side?
• Who has final approval?
• What’s the target launch date and are there hard external deadlines?
• What’s your honest budget range?

If you’re putting together a brief and want to know what your project would cost before you approach anyone, our configurator gives you a real number in a few minutes: website quote or online store quote. And if you’d like to talk through the brief itself before committing to anything, we’re easy to reach.