On this page
A website project fails for predictable reasons, and almost none of them are about design taste. It fails because nobody wrote down what the site is for, which pages matter, who is going to write the content, or what happens after a visitor submits a form.
You do not need a forty-page brief. You need four decisions made before a designer opens a canvas.
1. Decide the one job the site does
A business site can generate enquiries, sell products, support existing customers or act as a portfolio. It can technically do all four, but the first version should pick one primary job and let the others be secondary. That choice determines the homepage, the navigation and where the strongest calls to action sit.
Write it as a single sentence: “This site exists so that an operations manager who needs an internal tool can judge whether we are credible and start a conversation.” If you cannot finish that sentence, the design will not save you.
2. List the pages, and be ruthless
- Home — the proposition and the proof, in one screen.
- One page per service you genuinely want enquiries for.
- About — who you are and why you are credible.
- Contact — how to reach you, with a form that works.
- Any legal or policy pages your jurisdiction requires.
A common mistake is publishing eight service pages when only three of them describe work you actually want. Thin pages compete with each other, dilute your search visibility and give visitors more places to leave from.
3. Gather the content before the design
Design around real words, not placeholders. Collect the actual service descriptions, the real photographs, the client-facing FAQs and the details of every enquiry you have answered in the last month — those questions are your best source of page copy.
If a section needs content nobody can supply, that is a sign the section should not exist in the first version.
Assign one person to own content, with a deadline before design review. This single decision prevents the most common cause of a website sitting finished-but-unlaunched for two months.
4. Set the technical requirements in writing
Before comparing quotes, write down what the site must technically do: forms that reach a named inbox, analytics you will actually read, a sitemap, unique page metadata, image compression, and a content editing path that does not require a developer for copy changes.
- Where will enquiries be stored, and who reads them?
- Who updates content, and how often?
- Will there be a blog, and who writes it?
- Does anything need to connect — CRM, payments, booking?
- What must happen in the first hour after launch if something breaks?
What to ask a studio before you hire them
Ask to see the code and the content editing screen, not just the finished site. Ask what happens when a form submission fails, and ask who owns the domain and hosting account. A team that answers those three questions clearly is usually the safer bet, regardless of portfolio size.
Finally, agree the scope in writing with a fixed price and a definition of done. A site that is scoped properly is boring to build — and that is exactly what you want.
