From brief to browser: how we build a website.

A website project gets busy long before anyone agrees what it is for. There are references to collect, layouts to discuss and features to price. We find it helps to ask a smaller question first: what should a visitor be able to do once this website works?

At 3tf, our process connects research, design, development and marketing. This is how we turn that into a website brief, and which decisions we try to settle before the build picks up speed.

Start with the job, then write the brief

“We need a new website” is a starting point. It does not tell a designer whether the problem is an unclear offer, poor enquiries, hard-to-find information or a brand that has outgrown its presentation.

We start by connecting the audience to a specific action. For a service business, that might be booking a consultation and telling us enough for the first call to go somewhere. For a property business, it might be comparing suitable developments before arranging a viewing. Those journeys need different information.

A good brief names the audience, the main action, the evidence you have and the constraints. It should also identify who approves the work and who supplies the content. A beautiful layout cannot settle a disagreement about what the business actually offers.

Map the decisions a visitor needs to make

Before deciding how many pages to build, list the questions a customer needs answered. What is the service? Who is it for? What does it include? Why should someone trust it? What happens next?

Our SolTech project shows content shaping the structure. The website explains three commercial models for rooftop solar. Putting those options side by side helps visitors work out which conversation to have. The page structure follows a real decision in the business.

For your own brief, try writing a sentence for each proposed page: “After reading this, the visitor can…” If two pages complete that sentence in exactly the same way, check whether both are necessary.

Design with real content

A layout filled with placeholder text hides the hard parts. Real service names are longer. Real photography has awkward crops. A comparison that looks simple in a sketch may need more explanation once the terms are written down.

We prefer to bring the message, evidence and main action into the design early. Feedback gets more specific, because people can check whether a visitor could compare the options, read the proof and find the next step. Missing photos and copy also show up while there is still time to make them.

Review the phone layout alongside the desktop version. A long heading or a dense comparison needs a considered mobile treatment; shrinking everything is rarely enough.

Build the whole journey

The website includes the moments after a button is pressed. A form needs plain labels, error messages that say what went wrong and a confirmation that the enquiry was received. The team receiving that enquiry needs enough context to respond.

The W3C forms tutorial explains why labels, instructions and feedback matter for accessible forms. We treat those details as part of the experience, alongside visual design.

Our pre-launch review follows a visitor through the site: navigation, service information, enquiry, confirmation and the receiving workflow. We also check keyboard use, narrow screens, links and loading behaviour. A working page is a stronger review artifact than a screenshot alone.

Launch with a plan for what comes next

Before launch, decide what evidence will tell you the website is doing its job. Counting submitted forms is a start. Whether each enquiry fits the business is a separate question, and someone has to record the answer.

Agree who owns updates, how issues get reported and when the first review happens. Then use what visitors and the sales team actually do to choose the next improvement.

That gives us something concrete to build around. You can see our process or start a project brief with the same questions in mind.