Navigation Queries

Half the calls to a telecom's support line open the same way. Somebody wanted to move their service to a new address, spent ten minutes on the site, and gave up.

Help users get where they meant to go: listen on the way to wherever you're going.

Listen to the full Navigation Queries course on DesignPath
Share
Share

The page exists. It sits under Account, then Manage Services, then Address and Location, in a menu built around the seven departments that own the pages. The person looking for it does not know there are seven departments, and has no reason to.

That gap has a name. People arrive with a task in their own words and are handed a structure written in the organization's words. The work of translating between the two is left to them.

A navigation query closes the gap from the other end. It asks what somebody is trying to do and routes them, instead of asking them to find where the answer is filed.

Anatomy of a Query Constructor

The phrase covers four different components, which is why teams talk past each other about it. All four do the same job in a different shape.

Four Shapes of the Same Idea

Four components do the same job in different shapes, and seeing them as one family is what makes them learnable.

An intent dropdown, the I want to control, which asks for a goal and narrows from there. An A-Z index, which lists every task on one page in the words people use. Tap-ahead search, which builds a longer query out of suggestions without anybody retyping. And an evaluation journey, which asks what matters before showing a comparison. Each one takes somebody from a stated intent to a destination without a walk through the hierarchy.

The Parts They Share

Five, and a missing one is usually what makes an implementation feel unfinished.

The entry control, which is the thing on the page that starts it. The intent list, written in the reader's vocabulary. The narrowing step or steps, each one reducing what is left. The destination, which is not always a page. And the way back, so a wrong turn costs one step rather than the whole sequence.

The Destination Is Not Always a Page

The destination is the part most often left blank in a design file.

Some tasks end at a form, some at a booking slot, some at a phone number with opening hours, and some at a document. The City of Düsseldorf's two dropdowns take somebody from an intent and a location straight to appointment booking. Where a task really does end in a call, the honest destination is the number and the hours, rather than a page that then offers the number.

What It Cannot Do

The limit belongs at the front of any proposal for one of these.

A navigation query supplements an information architecture. It routes around a structure that is hard to navigate, and it repairs nothing. Bolted onto a site nobody has organized, it becomes one more layer to get lost in, and it hides the evidence that the structure needs work. Build it beside good structure and good search, as the express lane for people who already know what they want.

Pro tip: Write the five parts down for the constructor you are proposing, in one list. The one you cannot fill in is the design problem, and it is almost always the way back or the destination.

Found this useful? Pass it on.
Share