Before the pixels: planning a business website that works
Define the audience, page structure, content responsibilities and launch essentials before choosing the design or platform.
Before designing a new website, decide what it needs to achieve. A focused brief defines the audience, the information they need and the actions the site should support. It also helps separate launch essentials from ideas that can wait.
Visual references can help explain your preferences, but they do not define the problem. Begin with the business and the people the website needs to serve, then use that context to evaluate design and technology choices.
Give the website a job
“We need a modern website” describes a preference, not a purpose. Try a more specific statement: help a prospective customer understand our services and decide whether to request a conversation.
A retail site may need to help people compare products and complete a purchase. A specialist supplier may need to qualify enquiries. An internal portal may need to make a repeated task easier. These are different jobs, and they deserve different decisions.
Choose one primary action for each important page. Supporting actions can exist, but the visitor should not have to work out what you consider the next step.
Start with visitor questions
Your internal departments rarely match the way a new visitor thinks. A useful structure comes from the questions someone needs answered:
- Is this relevant to my situation?
- What exactly do you provide?
- How does the process work?
- What information do you need from me?
- What can I reasonably expect next?
Use those questions to organise the homepage and service pages. Make the answers specific. A visitor should be able to tell what a service includes, whether it fits their situation and what happens after they contact you.
Decide what you can substantiate
An attractive layout cannot turn an unsupported claim into evidence. Gather the facts you can publish: approved project examples, accurate service details, genuine customer feedback and current contact information.
If a case study cannot be shared, leave it out or describe a general method without implying that it is a real client result. Publish only the information you can support. A page can explain the service and its process without implying client results that have not been documented.
Map the pages before choosing the platform
Write a short purpose for each proposed page. If two pages have the same purpose, consider whether they should be combined. If a page has no useful purpose, it probably does not belong in the first release.
A manageable business site might begin with a homepage, services overview, focused service pages, an about page and a contact page. A blog only belongs in the plan if someone can maintain it with worthwhile material.
Then discuss the editing workflow. Who will change prices, add a service or publish an article? Structured content files may be enough for a small site maintained with a development partner. A team making regular independent edits may benefit from a content management system.
Treat mobile as a real journey
Mobile design is more than shrinking the desktop version. A visitor may be using one hand, reading between meetings or returning to the site from a message.
Keep the offer understandable near the top. Make navigation, links and forms comfortable to use. Avoid interactions that depend on hovering. Check long headings, embedded media and validation messages on narrow screens, rather than only checking the homepage screenshot.
Define a useful first release
Separate essential functionality from future possibilities. A clear, complete service site can launch before a complex portal, a large resource library or a custom dashboard exists.
The first release still needs to be complete for its job. That means accurate content, working links, clear forms, responsive layouts and a tested handover. “First version” should describe a deliberate scope, not unfinished basics.
Plan what happens after launch
Agree who owns the domain, hosting, content and maintenance. Document how changes are made and how important actions will be measured. Set a review point to inspect actual visitor behaviour and decide which improvement is worth doing next.
The brief should give the delivery team a shared basis for decisions: what belongs in the release, what needs approval and how the result will be checked. Keep it detailed enough to guide the work and simple enough to use.
A practical brief you can start today
You can begin with a short working document. It does not need to be polished, but it should make the first discussion more concrete:
- Describe the business and the audience in a few plain sentences.
- Explain the main job of the website and the action you want it to support.
- List the questions a prospective customer needs answered before taking that action.
- Identify the existing content, brand assets and approved examples you can provide.
- Name the person who will approve the direction and the person who will maintain the content.
- Record any important dates, budget boundaries and systems the website needs to connect with.
Where an answer is missing, write the question instead of guessing. That helps discovery focus on the decisions that still need work.
For example, a consultancy may receive enquiries for work it does not offer. Its brief could prioritise service pages that explain project boundaries, a clearer description of the process and a form that asks about the business problem. The review would consider enquiry relevance as well as submission volume, rather than assuming a new visual design will resolve the mismatch.
Want to turn an idea into a workable brief? Explore our consulting and strategy service or start a conversation.