Website Information Architecture: Navigation in Your Customer’s Language

A visitor looking for a new website encounters three menu choices: “Experience”, “Transformation” and “Growth”. Which one contains the service they need? An attractive interface can still require customers to decode the company’s vocabulary. Information architecture addresses that uncertainty by defining content names, groups and relationships. Navigation is its visible expression, supported by destinations that fulfil the promise of each link. The work begins with how people describe their needs, then connects that language to the actual services available.

Good navigation therefore involves more than reducing the number of links or designing an attractive dropdown. Labels need to establish expectations, destinations need to fulfil them and people need understandable ways to recover from an unsuitable choice. This guide offers a practical approach for corporate and service websites. The examples are hypothetical and should not be mistaken for findings from customer research.

Make the existing content structure visible

Begin with an inventory of real addresses and their contents. Record the title, purpose, visitor question, current status and responsible owner. Flag pages that describe the same service under different names, content that cannot be reached through normal navigation and sections that remain unfinished. A visually simple header can conceal substantial duplication. Changing labels alone will not resolve that underlying problem.

An inventory also helps a new website. Sales presentations, proposals and service documents can provide useful material, but not every internal section needs to become a web page. Separate information that supports a customer decision from details intended for internal use. The exercise should conclude with decisions about what to retain, combine and rewrite. Navigation then has a defined content structure to represent rather than becoming a container for every new request.

Find customer language in actual questions

Sales conversations, incoming enquiries and internal search terms can reveal how people describe their needs. Which words do they use for a service? Does one term mean different things to different audiences? Work from actual evidence where available. If the team has not conducted research, label its assumptions as hypotheses rather than presenting them as established customer behaviour.

For example, an internal category called “digital solutions” might suggest websites, advertising or bespoke software to different people. An appealing umbrella term may still fail to guide a decision. A clearer label or another level of grouping may be needed. Removing all technical language is not automatically correct either, particularly when specialist customers actively use it. Consider the audience’s knowledge and the real scope of the destination page together.

Separate the organisation from the visitor’s task

A company may have design, development and operations departments without customers evaluating services in those terms. Someone might instead arrive with a need to launch an online store or digitise an existing workflow. The architecture should offer understandable routes into those needs while allowing delivery responsibilities to be explained where they matter.

Multiple perspectives do not all have to appear in one overloaded menu. Main navigation can identify core services, a service directory can explain needs and contextual links can lead to specific deliverables. However, different labels pointing to the same place can become confusing if the relationship is unclear. The objective is to make relevant information discoverable, not to display every internal distinction the business uses when assigning work.

Group content by meaningful similarities and differences

Do not classify services solely because their names sound alike. Consider who uses them, what problems they address and how a customer evaluates them. Items within a group should have a recognisable relationship, while groups should be distinguishable. If almost every service appears equally suitable for every category, the categories may be too vague to perform useful navigation work.

Use card sorting as evidence, not an automatic answer

A card-sorting exercise can ask participants to arrange content labels into groups. It may reveal unexpected relationships or terms that people do not understand. Keep a record of who participated, which labels were shown and which uncertainties remain. A small exploratory exercise does not establish the behaviour of an entire market. Its findings inform a decision alongside other evidence; they do not generate a universally correct menu by themselves.

Keep labels concise without removing meaning

A short label is helpful only when it still establishes an expectation. “Solutions” may be compact, but a visitor who cannot predict its contents must experiment. Conversely, a full service description can be difficult to scan in a mobile menu. The task is to communicate the destination within a reasonable length rather than to achieve the smallest possible word count.

Read the proposed link labels apart from their surrounding design. Do they still communicate useful destinations? Are any easy to confuse? Google’s link guidance recommends relevant, descriptive anchor text. The same editorial discipline helps ordinary navigation. Explain the actual subject of the destination instead of repeating a search phrase mechanically or relying on surrounding visual decoration to supply all the meaning.

Align the menu promise with the destination

Someone selecting “Bespoke software projects” should not need to interpret a generic agency introduction to work out whether they reached the correct page. The destination heading and opening explanation should support the expectation created by the link. Exact wording need not always match, but the relationship between the choice and the resulting content must be clear.

The same principle applies to visitors entering through an article or advertisement. Not everyone begins at the homepage. A service detail page should explain its position and offer relevant neighbouring routes. Web design and development planning can consider these entry points together. When contextual links explain relationships, pages become parts of an understandable information system rather than isolated promotional documents.

Give each navigation layer a defined role

Main navigation shows the principal routes. Section navigation narrows choices within a particular area. A contents list inside a long article moves between sections of the same page. If these controls look and read identically without context, people may not know whether they are opening a new document or moving within the current one.

The footer can hold supporting links, but placing an important service only at the bottom of every page creates a different discovery problem. Decide placement according to the purpose and importance of the route. Repeating every destination everywhere is not a dependable solution. Duplication should support an identifiable need rather than merely add visual density. Writing down each layer’s role makes it easier to assess whether later additions fit the intended structure.

Simplify mobile presentation without changing the concepts

A spacious desktop service panel can become an exhausting wall of content on a phone. Consider leaving descriptions on the destination pages while showing clear headings and necessary subgroups in navigation. Do not randomly rename or reorder equivalent choices between screens. People benefit from recognising the same concept even when its visual presentation changes.

Menu implementation should express the relationships between options and preserve recognisable labels and destinations across screen sizes. Implementation should communicate the relationships to assistive technologies as well as visually. Opening the menu, expanding a category and following a page link are different actions. A label that unexpectedly performs two of them can be difficult to use. Define and test the behaviour instead of leaving it implicit in the visual mockup.

Treat search and recommendations as additional routes

Internal search can help a substantial content library, but it does not independently repair poor categorisation. People need an appropriate term before they can search successfully. Clear navigation remains useful for visitors who know the problem but not the service name. Plan empty results, alternative wording and relevant category suggestions as part of the search experience.

Related-content links should answer a likely next question. Rather than adding the same arbitrary list to every page, consider the actual relationship. A service page can lead to a preparation guide, and the guide can explain when that service becomes relevant. Link wording should describe what readers will find. The goal is a coherent route through useful information, not additional clicks produced by deliberately ambiguous headings.

Test the labels with neutral tasks

Imagine a hypothetical company grouping services as “Growth”, “Transformation” and “Experience”. Ask a participant where they would look when planning a new corporate website. Observe the initial choice and any uncertainty. Do not attribute every unexpected answer to the participant’s lack of expertise; examine whether the labels communicate enough. Another label set can then be tested using an equivalent task.

Define success before observing the exercise. Finding the intended page matters, but so do recovery from a wrong turn and understanding the destination. Avoid teaching the route while claiming to test its discoverability. Findings from a small sample should remain clearly bounded. Do not invent precise success rates without suitable data. The value of the exercise lies in exposing uncertainties and improving the basis for a decision.

Connect architecture changes with content maintenance

Adding a service can affect more than one menu entry. Related pages, anchor text, category explanations and translations may also need attention. If an address changes, old links and technical redirection require separate planning. Keep a dated version of the approved structure so that future team members can understand the reasons behind its organisation.

Assign content ownership and a review responsibility for each group. Otherwise, the same concept may gradually acquire different names across the site. A shared terminology list and page register within a corporate website development process make such drift visible. Information architecture is not a one-time diagram; it is a maintained agreement about how the business explains its offer to people who do not share its internal vocabulary.

Frequently asked questions

Is it wrong to use department names in navigation?

Not always. They may work when the audience recognises them and can connect them to its needs. The mistake is assuming that an internal structure automatically matches customer thinking. Test whether the labels help people complete realistic tasks before adopting them as the primary organisation.

What if a service belongs to two categories?

Examine the category boundaries and likely entry routes first. One principal service page can receive contextual links from another relevant section. Duplicating the entire explanation at a second address is not compulsory. Ownership and future consistency also matter when choosing how to support multiple routes.

Can mobile navigation show headings only?

Yes, if the headings describe the choices clearly. Detailed explanations can remain on service pages. Vague labels become more problematic when their supporting text disappears, so review naming at the same time. Simpler presentation and conceptual clarity need to work together.

How many menu options should a website have?

There is no universal number for every site. Similarity between options, hierarchy and visitor tasks all influence usability. Reducing the count by hiding unrelated services under an unclear umbrella label may make the experience worse. Evaluate the actual decisions rather than treating a particular count as a rule.

Can site search replace a good menu?

It is generally a complementary route. Someone who does not know the relevant term may still need categories or navigation guidance. Search results, synonyms and empty states also require design. The two approaches can support different ways of finding information without one compensating for every weakness in the other.

Must URL addresses change when menu labels change?

No. A clearer label can often point to the existing address. If an address change is genuinely needed, review incoming links and redirection separately. Naming a navigation item and migrating its destination are different decisions, with different maintenance and technical consequences.