What I ask before I start any web project
Every web project starts the same way for me: with questions. Not "what colours do you like" or "have you seen any sites you want yours to look like" – those come later, and honestly they matter less than people think. The questions I care about are the ones that establish what the website actually needs to do, and for whom. Get those wrong and no amount of good design rescues it.
I've been doing this long enough to know that most project problems trace back to the brief. Not the budget, not the timeline, not the technology – the brief. Either it didn't exist, or it was vague, or everyone assumed they understood it and nobody checked. A website built without a real brief is just a designer's best guess dressed up in your colours.
So here's what I actually ask.
What does the website need to do?
Not what should it look like, or what pages should it have – what does it need to accomplish? This sounds obvious, but it rarely gets answered clearly. "I want a professional online presence" is not an answer. Neither is "I want people to find us."
The answer I'm looking for is specific: generate enquiries from architecture practices in the UK, sell prints directly to collectors without going through galleries, convince local businesses to book an initial consultation. That specificity changes everything – the structure of the site, the hierarchy of information, where the calls to action go, what the homepage prioritises.
If a client can't answer this question, we're not ready to start.
Who is it for?
Most websites try to speak to too many people at once and end up connecting with none of them. I want to understand exactly who the primary audience is – not a vague demographic, but something closer to a real description of the person who should be landing on this site and what they're looking for when they do.
This matters because different audiences need different things. A B2B audience doing due diligence before a significant purchase needs depth, credibility signals and clear information. Someone browsing for a gift needs immediacy and confidence. A client hiring a creative professional wants to see the work and get a sense of who they'd be working with. The same business information, structured differently, will work for one of these and fail for the others.
What do you want visitors to do?
Related to the first question but distinct from it. The goal of the website might be to generate leads, but the specific action you want visitors to take might be to fill in a brief form, book a call, or simply email you. These are different things, and designing for one means de-prioritising the others.
I also ask whether there's a secondary action – something you'd accept if the primary one doesn't happen. A visitor who isn't ready to enquire today might be willing to sign up for a newsletter, follow on Instagram, or save a page. Knowing what you'd settle for helps design a site that doesn't lose people entirely when they're not quite ready.
What do you have, and what do you need?
Content is where web projects go wrong more often than any technical decision. I ask this early because the answer changes the scope of the project significantly. A client with strong photography, finished copy and a clear sense of what goes where is a very different project from a client who needs help with all of it. Neither is a problem – I offer copywriting services alongside the design work – but it has to be factored in from the start, not discovered halfway through.
The related question is whether there's an existing site, and what's worth keeping. Sometimes the answer is nothing, but often there's content, SEO history, or domain authority that's worth preserving and building on rather than wiping and starting over.
Who are your competitors, and what do you actually think of their sites?
I look at competitors anyway, but I want to know what the client thinks too – because what they say reveals how they see themselves in the market. Someone who looks at a competitor's site and says "ours needs to be completely different" is telling me something about positioning. Someone who says "I want something like theirs but better" is telling me something else.
The more useful version of this question is: what do you think your site should communicate that theirs doesn't? That gap is usually where the interesting design problem lives.
What's the budget, really?
I ask this directly, and I understand why people are reluctant to answer. There's a persistent fear that naming a budget means the designer will just spend all of it. What actually happens is the opposite: knowing the budget lets me tell you honestly what's achievable within it, and suggest where to start if the full vision costs more than you have right now.
A vague answer here produces a vague quote, and a vague quote produces a difficult project. If the budget is £3000, I can design a focused site that does one or two things well. If it's £8000, the scope expands. If there's a mismatch between the budget and the brief, I'd rather talk about that at the start than after I've spent a whole day on a proposal.
It also helps me point you towards the right starting point. A small business that needs something clean and functional to start generating enquiries is a different conversation from an established company that wants a comprehensive site with e-commerce and a content strategy behind it. Both are things I do – you can see the range on the website design page – but they're priced and scoped differently, and budget is the quickest way to work out which conversation we're having.
What happens after launch?
Who will be updating the site? How often does the content change? Is there likely to be a need for new features or additional pages down the line? These questions inform technical decisions – what CMS makes sense, how the templates should be structured, how much flexibility to build in.
They also open a conversation about ongoing support. Some clients are confident managing their own site; others want someone on hand for updates and maintenance. Either way, it's better to design for the reality than to assume.
What I've found is that clients who've thought about this beforehand tend to get more out of the handover. If you know you'll be adding case studies every month, we can make sure that's straightforward. If you know you'll never touch it, we can discuss whether a management plan makes more sense than training you on something you won't use. The post-launch relationship is part of the project, not an afterthought.
None of this is complicated, but it requires the client to think carefully about their business before thinking about their website – and that's the point. The sites that work are almost always the ones where that thinking happened before any design did.
If you're ready to start that conversation, the best first step is to fill in the website design brief. It covers most of the above, and it gives me enough to come back with something useful rather than a generic quote.