Digital products ·
A website structure is a sequence of decisions, not a list of pages
Website structure often begins with a menu. Section labels solve very little until the team knows who has arrived, which question they need to answer and what the next meaningful action should be.
Begin with the visitor's decision
A company may have a long list of services, achievements and documents. A visitor sees a different problem: is this offer relevant, can the provider be trusted, what will the next step require and what happens after an enquiry?
Build the first scheme around those decisions rather than the company's departments. For each visitor type, record the starting situation, question, required evidence and intended action. These four elements turn an abstract site map into a small set of testable journeys.
Inventory the content before naming pages
Collect the available services, products, use cases, objections, projects, documents and contact routes. Mark who owns each item, whether it is current and which decision it supports.
The inventory reveals where there is enough substance for a separate page, where several fragments belong together and where only a label exists. A vacant section does not become useful because it appears in the menu. It may be better to postpone it and strengthen the main journey.
One complete journey matters more than a complete tree
Shape the primary route from entry to action first. A person may recognise their problem, compare approaches, find evidence, understand the working format and begin a conversation. Alternative entry points and return paths can follow.
This order prevents every page from appearing equally important. Pages perform different jobs: some attract, some explain, some reduce risk and some enable action. The hierarchy should make those roles visible.
Give every page a job
Define one principal question and one reading outcome for each page. The home page orients; a service page explains scope and process; a project shows how a decision developed; an article examines one problem; the contact page makes the next step clear.
When two pages answer the same question in the same way, they compete and increase maintenance. When one page tries to sell every service, tell the whole story and carry a reference library, it loses clarity. Separation begins with functions rather than screen count.
Navigation uses the visitor's language
Internal names may be obvious to a team and meaningless to a client. A navigation label should make a clear promise. A new visitor ought to predict what they will find after selecting it.
Primary navigation holds frequent directions, contextual links continue a specific journey and search helps people who already know the term. URLs and breadcrumbs reinforce the hierarchy, but they should not be the only way to understand location.
Test the scheme with real material
Grey placeholder blocks conceal structural problems. Real headings, examples, constraints and actions reveal whether the meaning fits the proposed page and whether the evidence is sufficient.
Even a short journey test is more useful than discussing a tree without content. Give a person a task and observe where they begin, which labels they choose and where they hesitate. Changing the structure now costs less than moving finished design and copy later.
Make the result usable in development
A working structure includes the page map, each page's role, connections, key actions and required content. A complex project may also need content types, URL rules, access states and analytics requirements.
Within the Method, this scheme becomes a shared foundation for copy, design and website development. It lets the first prototype use real journeys, exposes missing material early and supports a realistic project scope without false precision.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.