How English Works | The Menu

A menu looks like a list.

That is why we underestimate it.

At a restaurant, the menu tells you what can be ordered.

On a website, it tells you what can be visited.

Inside a software application, it may tell you what can be done.

On a television, phone, camera, ticket machine or game console, it may be the main surface through which the human discovers what the machine is capable of.

So the menu is not merely a list of words.

A menu is English arranged into possible futures.

Choose Settings, and one world opens.

Choose Account, and another opens.

Choose Delete, and the language may lead to an irreversible action.

Choose Help, and the system may route you towards explanation.

A surprisingly large part of modern life therefore depends on whether a few nouns and verbs are arranged well enough for a person to find the right path.

Quick Read

One-sentence answer: a menu works when English names the available choices clearly enough, groups them logically enough and reveals their hierarchy and current state well enough for a reader to predict where each choice will lead.

A good menu has several language jobs:

scope: what set of choices this menu contains;
labels: what each option means;
grouping: which choices belong together;
hierarchy: which choices contain subchoices;
order: what appears first and what appears later;
state: which item is current, selected, disabled or unavailable;
prediction: whether the reader can reasonably anticipate what happens after choosing;
access: whether the menu can be operated by different readers and input methods.

W3C’s Web Accessibility Initiative treats menus as critical structures because navigation menus reflect the structure of websites and application menus provide access to core functionality. Its guidance emphasises meaningful labels, clear structure, identifiable current states, predictable ordering and keyboard-operable interaction. That is a technical standard, but underneath it is a simple English principle: if the words do not expose the structure, the reader has to guess the structure.

The Menu Is a Map Made of Labels

Imagine a website with these menu items:

Home
Things
Stuff
Other
More

Nothing is grammatically wrong.

Almost nothing is navigationally useful.

The reader does not know whether Things contains products, lessons, photographs, policies or documents.

The labels fail because they do not carry enough information scent.

Information scent is a useful way to think about menu English. A label should smell enough like its destination that the user can make a reasonable prediction before clicking.

Good menu label → plausible destination model.

Compare:

Things
Secondary English

Or:

More
Fees & Class Schedules

The more descriptive label reduces the reader’s search space before the click.

That is English doing navigation.

A Menu Can Contain Nouns or Verbs

Website navigation often uses nouns:

Courses
Research
Admissions
Contact

Application menus often use verbs:

Save
Print
Export
Delete

The difference matters.

A noun often names a destination or information domain.

A verb often names an action.

If a website mixes them carelessly, the user may not know whether an item opens a page or performs an operation immediately.

Consider:

Account

versus:

Delete account

The first sounds like a place.

The second sounds like an action with consequence.

Strong interface English respects that distinction.

Grouping Teaches the Reader the System

Suppose a camera menu contains twenty options in one flat list:

Image size
Bluetooth
Autofocus
Language
White balance
Date
Battery
Wi-Fi
Exposure
Copyright

The options may all be correctly named.

The user still has to scan the whole set.

Now group them:

Image: image size, white balance, exposure, autofocus
Connection: Wi-Fi, Bluetooth
System: language, date, battery
Metadata: copyright

The menu has become a small ontology.

It teaches the reader how the system’s capabilities are organised.

This is why W3C recommends menu structure that reflects the underlying structure and uses lists and labels to make the hierarchy understandable to assistive technologies as well as visual readers.

Grouping is not only visual tidiness.

Grouping is a claim about which things belong together.

Hierarchy Is Meaning

A submenu says:

This choice lives inside that larger choice.

For example:

English
- Primary English
- Secondary English
- IGCSE English

The hierarchy communicates category membership.

But hierarchy can become too deep.

Imagine:

Services → Education → Tuition → English → Secondary → Lower Secondary → Secondary 2 → Grammar → Tenses

Every step may be logically defensible.

The reader is walking through a tunnel.

Deep hierarchy imposes memory cost because the user must remember where they are and how they got there.

W3C’s cognitive-accessibility guidance warns that users can become confused when site and menu hierarchy are difficult to understand, and recommends logical, cohesive sections with submenus whose relationship to their parent is clear.

The English lesson is simple:

A category tree should reduce complexity, not merely hide it behind more clicks.

Ordering Changes What Gets Seen

Menus are not neutral lists because position influences attention.

What appears first feels primary.

What appears last may be overlooked.

What is buried under More may receive less traffic.

What sits beside a familiar item may inherit some of its attention.

There are several legitimate ordering systems:

alphabetical;
chronological;
frequency of use;
task sequence;
importance;
conceptual hierarchy.

The correct order depends on the job.

A construction manual may need ordered steps because sequence matters. W3C’s menu-structure guidance explicitly distinguishes unordered navigation lists from ordered lists where sequence is meaningful.

A restaurant menu might organise by course.

A settings menu might organise by function.

A frequently used command might deserve priority even if alphabetically it belongs near the bottom.

Ordering is therefore an editorial decision about the likely path through choices.

The Current Item Is a Sentence About Where You Are

Menus do not only tell us where we can go.

They can tell us where we are.

A current-state marker—perhaps a highlight, underline or explicit accessible label—communicates:

You are here.

W3C recommends indicating the current menu item, including through mechanisms such as aria-current="page".

That small state signal matters because without it the reader may know the available destinations but not their present location.

This is exactly the same orientation problem we see in long documents, maps and workflows.

English is frequently asked to do two jobs at once:

show possible routes;
show present position.

Hidden Menus Create Hidden Capability

A system may contain an excellent function that nobody finds.

From the user’s perspective, a function that cannot be discovered may as well not exist.

This is a profound design problem.

Suppose a student portal lets users download feedback, but the command sits under:

More → Tools → Documents → Output → Export

The capability exists technically.

It is poorly represented linguistically.

This teaches a larger rule:

Availability is not the same as findability.

English is part of the findability layer.

“More” Is Often a Confession

Many interfaces use:

More

It is short.

It is flexible.

It is also semantically weak.

More what?

More settings?

More information?

More actions?

More products?

Sometimes a compact overflow menu genuinely needs a generic label.

But repeated dependence on More can signal that the information architecture has not found useful category language.

The menu is saying:

We had more things than places to put them.

That may be acceptable.

It should be recognised as a trade-off.

Menu Labels Should Be Parallel

Compare:

Courses
Apply
Student Life
How to Contact Us
Research

The meanings may be clear, but the grammatical forms jump around.

Noun.

Verb.

Noun phrase.

Question-like phrase.

Noun.

Parallel labels reduce processing friction because the reader can compare like with like.

For example:

Courses
Admissions
Student Life
Contact
Research

Or an action menu:

Open
Rename
Duplicate
Export
Delete

Parallel grammar creates a cleaner decision field.

A Menu Can Mislead Without Lying

Suppose a subscription service has:

Upgrade plan
Payment details
Account preferences

Where is cancellation?

Perhaps it exists three layers down under:

Account preferences → Membership → Manage status → End membership

The words may all be technically accurate.

The architecture can still steer behaviour by making one action easy to find and another difficult.

This is why menu analysis can become ethical analysis.

What choices are prominent?

What choices are buried?

Which verbs are direct?

Which are euphemistic?

Does the reader have equal linguistic access to entering and leaving a commitment?

A menu is a choice architecture, and language participates in that architecture.

Restaurant Menus Show the Same Mechanics

Digital menus are not unique.

A restaurant menu also names, groups and frames choices.

Consider:

Fish with rice

versus:

Chargrilled sea bass with jasmine rice and citrus herb dressing

The second description does more than identify ingredients.

It creates expectation.

Words such as chargrilled, jasmine and citrus herb add sensory and status information.

The same object can be linguistically framed as plain, premium, traditional, healthy, indulgent or adventurous.

So even the restaurant menu reveals the general principle:

Choice is shaped by how options are named.

Accessibility Reveals What Visual Readers Take for Granted

A sighted mouse user may recognise a navigation bar because it appears across the top of a page.

A screen reader needs semantic structure and labels.

A keyboard user needs a workable focus order.

A person with limited short-term memory benefits when the menu clearly indicates the current page and behaves consistently.

W3C emphasises these points because good navigation cannot depend solely on visual familiarity.

This exposes a hidden truth:

Many interfaces are understandable only because users have silently learned the designer’s conventions.

Accessibility forces the designer to make more of that structure explicit.

Primary School: Learn to Sort Choices

Young learners can practise menu thinking without computers.

Give them ten words:

lion
rose
tiger
orchid
whale
daisy
shark
sunflower
eagle
lily

Ask them to build a two-level menu.

Perhaps:

Animals
- Mammals
- Birds
- Fish
Plants
- Flowers

Then ask:

Why does this item belong here?
Could another grouping work?
Which label is too broad?
Which label is too narrow?

This is classification, vocabulary and information architecture at once.

Lower Secondary: Audit Findability

By Secondary 1 and Secondary 2, students can study a real website or application.

Give them a target:

Find the refund policy.

Do not let them use site search initially.

Ask them to navigate from the menu and record each prediction:

Which label looked promising?
Why?
Where did the path fail?
Which label would have made the route clearer?

Now menu design becomes a reading-comprehension problem.

Upper Secondary: Analyse Choice Architecture

Older students can go beyond findability.

Ask:

Which choices are foregrounded?
Which are hidden?
Which labels use direct language?
Which use euphemism?
Is the menu arranged around the institution’s internal departments or the user’s needs?
Does hierarchy match the way a newcomer would classify the task?
Does the current-state marker help orientation?
Could the ordering influence behaviour?

This is language analysis with direct relevance to digital life.

Ten Failure Modes of Menu English

Vague label. The destination cannot be predicted.
Internal jargon. The organisation names categories using terms outsiders do not know.
Mixed grammatical forms. Destinations and actions become harder to compare.
Deep hierarchy. The user forgets where they are before reaching the target.
Hidden submenu. The reader does not know more choices exist.
Weak grouping. Related items are scattered across different sections.
No current-state marker. The user knows where they can go but not where they are.
Generic overflow. Important capabilities disappear under “More.”
Choice asymmetry. Desirable actions are easy to find while inconvenient ones are buried.
Visual-only meaning. Structure or state cannot be perceived through other interaction modes.

Every item can be spelled correctly.

The menu can still fail.

Because the test is not whether the words are individually good.

The test is whether the arrangement helps the receiver choose.

How to Build a Better Menu

Start with user tasks rather than internal organisation.

What are people actually trying to find or do?

Group those tasks into a small number of coherent categories.

Name the categories using words the intended reader already uses.

Then test each label:

What would I expect behind this word?
Would a newcomer predict the same thing?
Does the label describe a destination or an action?
Are sibling labels grammatically parallel?
Is the hierarchy obvious?
Can the user tell which page or state is current?
Can keyboard and assistive-technology users operate the same structure?

Finally, run a simple test.

Give someone a task without telling them the route.

Find the cancellation policy.

Watch the words they choose.

Watch where they hesitate.

Hesitation is data.

It tells you where your category language and their mental model diverge.

The Deeper Idea: A Menu Makes a System Legible

A complex system may contain hundreds of functions.

The user does not want to memorise them all.

The menu is one way the system compresses its capability into a readable surface.

That means the menu performs representation.

It says:

These are the things you can do here, and this is how they relate.

If the representation is good, the system feels intuitive.

If the representation is poor, the same system feels confusing.

The difference may be only six words across the top of a page.

That is how much work small English can do.

Reader Checklist

What does each label make me expect?
Are these destinations, actions or a confusing mixture?
Which choices belong together?
How deep is the hierarchy?
Can I tell when a submenu exists?
Can I tell which item is current?
What is hidden under “More”?
Are important but inconvenient actions harder to find?
Would a newcomer use the same category words?
Can the menu be understood and operated without relying only on visual position?

Research and Further Reading

Final idea: a menu is successful when the reader does not need to know the system before the system can show them where to go.