Shape the website menu around concrete user tasks
Map existing pages to what visitors want to do. A worked example makes menu labels, destinations and the subsequent review explicit.
Plan the website menu around what visitors want to accomplish. You need to know which content exists and which question each destination page answers. Your company’s department names are initially just one possible way to organise it.
Connect existing content to a task
The following example is fictional. A software provider’s website has an integration page, a project enquiry form and help for portal software already in use. The identifiers refer to our own example pages, not actual ASES routes.
The table shows part of the navigation. The menu labels are proposals; the destination mapping is an expectation to examine later, not the result of a user study.
Task | Existing content | Proposed menu item | Destination |
|---|---|---|---|
Check whether the provider can transfer customer data between CRM and ERP. | System integration covering data flows, limits and how to enquire. | Connect systems |
|
Describe a planned web application and provide your contact details. | Project enquiry covering the proposed work and contact information. | Enquire about a project |
|
Read how a file export works in the portal software already in use. | Portal help with the relevant instructions. | Portal help |
|
A destination page must fulfil the promise of its menu item. A general services overview is insufficient, for example, if it lacks the integration information being sought. Review the content before merely renaming the link.
Examine menu labels through concrete tasks
GOV.UK recommends concrete, credible test tasks that do not reveal the solution. Give a suitable participant the first task in the table, for example. Do not tell them which menu item to choose. Observe their choice of label, detours and the outcome on the destination page.
Then ask whether the information they found answers the task. A first click alone does not establish this. Record observation and interpretation separately: the wrong destination may result from a label, grouping or missing content. A single attempt does not yield a general success rate.
Preserve orientation on small screens
The WAI menu tutorial describes semantic structure and consistent visible items across screen sizes. A collapsible mobile menu should support the same tasks. Items visible in both views should have the same order, wording and destination; the current page must be recognisable.
Plan explicitly for long translations and multiple navigation levels. Moving an item into a subgroup is a content decision, not simply a matter of space. Check whether the three example tasks remain possible there without an explanation.
Review how the navigation works, too
The WAI-ARIA example distinguishes ordinary website navigation from an application menu with specialised keyboard controls. The menu role is not automatically appropriate for ordinary navigation links. Use understandable links and suitable controls for expanding sections; their state and focus must be clear.
Check keyboard use, magnification and an appropriate screen reader configuration in the implemented version. The example review of three destinations does not replace this technical check. Adopt labels and groups when task understanding, destination content and operation fit together; keep unresolved findings visible.
Sources
Read more
All articles
Design & UX with ASES
User experience, interfaces and brand presence