Skip to main content

Information architecture and journeys

Information architecture organises what a person must find, understand and connect. Ask: “When I know my intent, can I predict where to start, what I will see and how to return?”

Clear architecture comes before style. A brightly colored menu with ambiguous names is still ambiguous.

Start with intent​

Write tasks in the person’s words:

I am starting → understand where to begin
I need a reminder → find one precise concept
I want to practise → follow a mission and produce evidence
I am resuming → return to my last state without starting over

An intent is not a technical category. “React”, “API” and “CSS” may be useful library domains, while a beginner’s first entry point may be “understand”, “build” or “fix”.

Taxonomy and labels​

A category is useful when people expect its contents to belong together. Test with: What would you expect here? Where would you put this? What other name fits better? If two categories receive the same answers, the issue is structure, not menu color.

A label is short, stable and concrete. Avoid internal names, overlapping synonyms and titles that promise more than the content delivers.

Journeys and states​

For each step, note the person’s goal, information to recognise, possible action, expected result, alternatives (empty, error, loading, denied, abandoned) and return path.

Home
  → choose “I am starting”
  → see foundation and duration
  → open first room
  → produce an answer
  → receive a check
  → resume or open the next room

Keep the main path obvious, but also provide a contents link, breadcrumb when depth requires it and a search that preserves context. Make the active location visible beyond color alone.

Search and filters​

A search is a dialogue: a person enters a term, the system responds and the person adjusts. Design a label, useful example, loading state, named results, empty state with nearby doors, network error that keeps input and removable filters.

“No results” should explain what was searched and offer a next action. Tolerance can help; it should not replace understandable labels.

Recovery states​

SituationExpected response
Missing pageExplain, keep navigation, offer search and home.
Access deniedSay what is missing and preserve what can be preserved.
Empty resultConfirm the query and offer a next action.
Interrupted sessionShow last state and a resume action.
Server errorKeep input, explain and allow retry.

An exitless state is a dead end. An exit must not silently delete the person’s work.

Test architecture before polish​

Use card sorting to study groups, tree testing to study destinations, first-click testing to study the first choice, wireframes to study order and interruption tests to study resumption. Form tasks by outcome: “find the rule for making a form accessible”, not “click the UI/UX menu”.

Workshop: repair a menu​

The menu contains “Resources”, “Methods”, “Content”, “Advanced” and “Misc”. A person wants to resume a mission. Define three intent-based entries, predictable labels, the resume path, the missing-mission state and a participant task to test the proposal.

One possible answer

Use “Start”, “Find a concept” and “Practise”. The resume path becomes “My path” or “Resume room 4 — Check states”, preserving progress and offering the contents page. If the mission disappeared, explain the migration and offer an equivalent room without deleting the trace. Test: “You return after a week; resume where you stopped and explain how you know it is the right place.”

Checklist​

  • Entries begin with understandable intent.
  • Categories do not overlap unnecessarily.
  • Each step shows location and next action.
  • Search has success, empty, loading and error states.
  • Missing and denied pages have useful exits.
  • Resume preserves context and progress.
  • The main journey was tested with natural-language tasks.
  • Breadcrumb, active menu and return work with keyboard.

Reliable sources​

Continue with evaluation and practise in the interactive UI/UX path.