Web Design Brief Checklist: What to Ask the Client For
A web design brief checklist covering everything a typical website project needs from the client, grouped by category, with a short reason for each item and whether it can wait until after kickoff.
How to use this checklist
This is a reference list, not a script — cut anything your project does not need and add anything specific to it. Every item below carries two things: a one-line reason it matters, and a rough call on timing, because not everything belongs in the same request.
Before kickoff means the project cannot really start without it, or starting without it means redoing work later. Can come later means you can begin with a placeholder or a sensible default and swap in the real thing once it arrives, without losing time. Getting this split right is most of what makes an intake request feel reasonable instead of overwhelming — a list of twelve things due tomorrow reads very differently from four things due tomorrow and eight that can follow over the next two weeks.
If you want the process this checklist plugs into — how to phrase the request, how to follow up, how to handle the items that never come back — see how to collect documents and files from clients.
Identity and brand
| Item | Why you need it | Timing |
|---|---|---|
| Logo file (SVG or high-res PNG) | A screenshot or a resized JPEG will not scale cleanly to a favicon, a retina header, or print. Ask for the source file, not an export someone made for a slide deck. | Before kickoff |
| Brand colors (hex codes if they have them) | Guessing colors from a screenshot introduces drift the client will notice even if they cannot articulate why. If they do not have hex codes, a phone photo of something branded (a sign, a business card) is enough to sample from. | Before kickoff |
| Typography preference, if any | Most small clients do not have a defined typeface and are fine with your recommendation — but ask, rather than assume, if they already use a specific font on printed material. | Can come later |
| Existing style guide or brand book | Rare below a certain company size, but when it exists it settles a dozen small decisions (logo clear space, color usage, tone) that would otherwise be a back-and-forth. | Can come later |
Content
| Item | Why you need it | Timing |
|---|---|---|
| Homepage headline and intro copy | The single piece of text most likely to hold up a launch if it is missing, because it is also the hardest for a client to write — ask for it first and expect it to need a revision round. | Before kickoff |
| Secondary page copy (about, services, etc.) | Structure and layout can proceed with placeholder text, but final copy changes line counts and section heights, so build it in once it exists rather than treating it as a drop-in swap at the end. | Can come later |
| Photos (with a minimum count and resolution stated up front) | A phone photo at full resolution is almost always fine; a photo already resized for a Facebook post usually is not. State the minimum width in the request instead of finding out after upload. | Before kickoff for hero/key photos, later for the rest |
| Team bios and headshots | Needed for an about or team page, rarely for the homepage — usually safe to leave for a later round. | Can come later |
| Testimonials or reviews | Real client language outperforms placeholder copy by enough that it is worth a specific ask ("can you paste your three best Google reviews") rather than a generic "any testimonials?" | Can come later |
| Video or other media assets | Often the last thing ready and the most negotiable — confirm whether the project actually needs it before treating it as a blocker. | Can come later |
Copy deserves its own request rather than a single row on this table — it splits into page copy, SEO title/description, microcopy, and legal text, each with a different writer and a different deadline. See website copy from clients for how to ask for each piece.
Technical access and integrations
| Item | Why you need it | Timing |
|---|---|---|
| Current website admin login, if one exists | Needed to migrate content, redirect old URLs, or simply see what is there before replacing it. Ask for this as a credential, not a document — see the note on handling logins below. | Before kickoff |
| Domain registrar access or DNS delegation | Launch day depends on this. Finding out the client does not have their own registrar login (an old developer registered it for them) two days before launch is a common and avoidable delay. | Before kickoff |
| Hosting account access, if the project keeps existing hosting | Same reasoning as the registrar: confirm access exists before you need it, not when you need it. | Before kickoff |
| Analytics tracking ID (e.g. Google Analytics) | Nice to wire in from day one, but a site can launch and collect a data gap of a few days without lasting damage — not worth delaying launch over. | Can come later |
| Email marketing or CRM integration details | Usually a later-stage connection (newsletter signup, form routing) rather than a structural requirement of the site itself. | Can come later |
| Third-party booking, payment, or scheduling accounts | If the site's core function depends on one of these (a restaurant's reservation system, a shop's payment processor), treat it as a launch blocker, not an integration to add later. | Before kickoff if launch-critical |
Credentials deserve a different handling path than everything else on this list. A password sitting in an email thread is a standing liability, not a filed document — it stays readable in every backup of that inbox indefinitely. Collect logins somewhere built for a one-time handoff rather than in the body of a message; BriefGate's secrets vault encrypts a submitted credential and releases it once, to the person who asked, which is closer to how a password should travel than an email ever is.
Legal and business
| Item | Why you need it | Timing |
|---|---|---|
| Business name, address, and contact details exactly as they should appear | Small inconsistencies (a slightly different phone number in the footer versus Google listings) hurt local search and look sloppy. Get the exact, current version rather than assuming last year's version is still right. | Before kickoff |
| Opening hours, service area, or other operational facts | These are facts about the business, not design decisions, and only the client can supply them correctly. | Before kickoff |
| Pricing or service packages, if shown on the site | Ask whether this is meant to be public before designing a page around it — some businesses deliberately keep pricing off the website. | Before kickoff if the site will show it |
| Privacy policy and terms of service | These carry legal weight and should come from the client or their lawyer, not be invented on their behalf, especially for a site that collects any personal data. | Can come later, but before launch |
| Industry-specific disclosures (health, finance, legal, alcohol) | Requirements vary by sector and jurisdiction; flag early that this is the client's responsibility to confirm, not a default template will not cover it. | Before kickoff for regulated industries |
| Sign-off on who has authority to approve the final site | On any project with more than one stakeholder, confirm this once at the start rather than discovering a second decision-maker after launch. | Before kickoff |
Questions to ask before design starts
The checklist above lists what to collect. Before any of it gets collected, a short set of judgment calls needs answering — not deliverables, but decisions that shape what the deliverables above should even look like. Skipping these is how a project discovers its real target audience, or its actual budget, in week five, after work has already gone in the wrong direction.
Business and goals
- What should this site accomplish in the first six months? Turns "make it look professional" into a measurable target — more bookings, fewer support calls, a credible presence for a funding pitch.
- What's the single action you want a visitor to take? A phone call, a purchase, a booking, or a newsletter signup each changes how every page gets designed.
- Who are your two or three biggest competitors, and what do you like or dislike about their sites? Gives real reference points instead of abstract style words, and often reveals a feature the client assumes is standard.
- What's driving this project now — a rebrand, a broken old site, a new business, something else? The reason shapes what "done" looks like more than any brief does.
- What would make this project a failure, even if the site looks great? Surfaces the one hidden requirement — a specific integration, a legal disclosure, a stakeholder's opinion — before it becomes a week-five surprise.
Audience
- Who is your ideal customer? The basis for every other content and design decision — a site for retirees and a site for university students shouldn't share a template.
- What device do most of your visitors use — mostly phone, or mostly desktop? Tells you where to spend the mobile-testing time, rather than treating both equally by default.
- What questions do people ask before they buy or book with you? This is the FAQ page and half the homepage copy, already written by the client without realizing it.
- What makes someone hesitate to choose you over a competitor? The honest answer is worth more than any tagline — it tells you what the copy needs to overcome.
Brand and style
- Name three websites you like the look of, and say why. Concrete references settle arguments about taste far faster than adjectives do.
- Pick three words for how you want the brand to feel. "Playful," "clinical," and "luxury" each rule out entire design directions before anything's been drawn.
- Any colors, fonts, or styles you specifically want to avoid? Often more useful than what they want — a client with a strong opinion about a previous designer's choices will tell you.
Timeline and expectations
- What's the budget range for this project? Uncomfortable to ask, essential to know before scoping something the client can't afford — offer three tiers rather than asking for a number cold.
- How available will you be for feedback and approvals during the project? A client who disappears for two weeks mid-project needs a different schedule than one who replies within the hour.
- Do you want ongoing maintenance and support after launch, or a one-time build? Changes what "finished" means, and whether the relationship continues after the invoice is paid.
How to ask these
The deliverables in the checklist above work fine as an asynchronous form, because the client can look things up — their current hosting login, an old invoice with pricing. The questions in this section work better live: a written answer to "what feel do you want" tends to arrive short and vague ("modern, but not too corporate"), and only becomes useful once you can ask a follow-up ("modern like what, specifically?"). A practical split that works for most small web projects: send the checklist above as a form before kickoff, and save this section for a short call once the form is back.
Frequently asked questions
What should you ask a client before starting a website project?
The short version: brand assets (logo, colors), core content (a homepage headline and key copy), technical access (the current site's login, domain registrar, hosting), and business facts (hours, address, pricing). The categories above break each one down further, with a note on what blocks the start versus what can wait.
How many items should a client intake checklist have?
Enough to be specific, not exhaustive — a typical small business site needs eight to fifteen distinct items once photos, copy sections, and technical access are counted separately instead of bundled under a vague heading like "assets." A shorter list of concrete asks gets answered faster than a longer list of vague ones.
What if the client doesn't have brand guidelines or hex color codes?
Most small clients don't. Ask for what they actually have: the logo file, and a phone photo of anything branded — a sign, packaging, a business card — that you can sample a color from. Waiting for guidelines that were never written just stalls the project.
How do you collect login credentials from a client without emailing passwords?
Never in the body of an email or chat message — it stays readable in every backup of that inbox indefinitely. A password manager's one-time-share link is a reasonable baseline for occasional use; across many client projects, a vault that encrypts the credential on the server and reveals it once, to the person who asked — BriefGate's secrets vault works this way — removes the risk of anyone forgetting to delete the email afterward.
What if the client never sends the logo or key photos?
Set a real deadline and say what happens if it's missed — most stalls resolve once there's an actual consequence attached. If it still doesn't arrive, fall back to what's available: a phone photo of a sign or business card is enough to sample brand colors, and a text-only wordmark can launch in place of a logo file without forcing a rebuild later.
What's the difference between this checklist and an onboarding questionnaire?
There isn't a separate page for one — the judgment-based questions that shape a project (goals, audience, brand feel, budget) are folded into Questions to ask before design starts above, so this one page covers both the concrete deliverables to collect and the decisions that shape them, instead of splitting them across two documents.
Where BriefGate fits
Turning this checklist into an actual request is the part most tooling skips: someone still has to send it, track what came back, chase what did not, and keep the credentials rows separate from everything else. BriefGate exists for that step. An AI coding agent — or you, from the dashboard — declares this list as typed items with the constraints above baked in (minimum image width, required versus optional, a schema for structured facts like opening hours), and BriefGate generates one branded client portal, sends the reminders on a schedule you choose, and hands back validated data instead of a folder of mismatched files and a stalled email thread. The restaurant, advisor, and club website templates cover a version of this exact checklist pre-built for those three project types, so a recurring project type does not mean rebuilding the list from scratch each time.
Send this checklist to your client with BriefGate — start free, no card required, and turn the table above into a branded portal with reminders instead of a one-off email.