Skip to content

Web & Digital Experience

UX and information architecture: organised by the visitor's task

Most sites are organised the way the company is: Residential, Commercial, Service Department. Visitors don't think in departments. They think “my heat is out” or “my tune-up is due”. Information architecture builds the structure from the tasks people arrive with, names it in their words and tests it against those tasks before anything is built.
Discuss your siteSee the five tasks ↓
task · book a furnace tune-upby departmentby taskResidentialCommercialService Department1RepairsMaintenance2Residential plans3Schedule a visit4About UsResources4 stepsNo heat or coolingBook maintenanceReplace a systemCommercial accountsPay an invoiceBook maintenance11 step

Five tasks visitors arrive with

For a home-services site. They come from calls, searches and the questions the office answers every day.
My heat or cooling is outthe top of the homepagea number, today's availability, a way to book
Book a tune-upthe menua time, and what the visit includes
Replace a systemsearch, then service pagesoptions, a written quote, financing
Pay or ask about a billthe footer, or an old emailthe invoice, a way to pay, a person
Commercial servicethe menuan account contact and how work is approved

How the structure is found, not invented

  1. 01

    Listen first

    Calls, searches, the office's questions

    The tasks come from what people actually ask for, not from a workshop about the company.

  2. 02

    Content inventory

    Everything that exists today

    Every page listed, with what it's for and who uses it, so nothing useful is lost.

  3. 03

    Card sort

    How visitors group things

    People sort topics into piles that make sense to them; their piles suggest the menu.

  4. 04

    Tree test

    Can they find it, without the design?

    The structure alone, as a list, tested with real tasks before anything is built.

  5. 05

    Labels in their words

    “Book maintenance”, not “Service Department”

    Every menu label is a word visitors use, checked against search terms and calls.

One task, tested twice

“Where would you book a furnace tune-up?” One participant, the old structure and the new.

Old structure · book a furnace tune-up

  1. Opened Residential

    a wrong turn: no tune-ups here

    failed

  2. Back, opened Service Department

    done

  3. Opened Maintenance

    done

  4. Opened Residential plans

    done

  5. Found Schedule a visit

    after 5 choices

    done

Found, but only after a wrong turn and five choices.

What information architecture hands off

In

Tasks
and the words visitors use
Content
everything that exists
Services
what the business does
Information architecture
organise by task, then test

Out

Navigation
and its labels
Relationships
which page links where
Test results
to check against

Worth doing when visitors get lost or call to ask

Good fit

  • The menu mirrors your departments.
  • The office answers “where do I find…” calls.
  • A redesign or a new app is about to be built.

Not the right fit

  • A one-page site, or a handful of pages.
  • The structure was tested recently and works.

Where this capability is used

Next to information architecture

Questions about UX and information architecture

Isn't this just choosing menu items?

The menu is what shows. Underneath are the page relationships, the labels and the paths to each task, and they're tested before anything is built.

Do we need to recruit research participants?

A handful is enough for card sorts and tree tests, and existing customers usually say yes. The office's call log does a lot of the work.

Will changing the structure hurt our search rankings?

Moved pages keep their addresses or redirect to the new ones, and their content is kept. Nobody can promise rankings, but a move done carefully shouldn't throw them away.

Does this apply to apps as well as websites?

Yes. In an app, the tasks are the day's work: find a job, assign it, close it out.