Information Architecture and Navigation

A candidate who's asked "how would you organize the navigation for this app" and jumps straight to sketching a tab bar has skipped the actual work. The tab bar is a surface — a UI decision about which few labels get permanent screen real estate. The decision that determines whether the product is usable at all happens one layer beneath it: how is the content and functionality structured in the first place, so that any navigation surface built on top of it has a sane set of things to point at? That structure is information architecture (IA), and it's the layer most junior answers skip past on the way to picking icons.

This subject picks up where ux-vs-ui-and-the-design-process left off. If UX is the end-to-end quality of the whole interaction and UI is the surface, IA sits close to the UX end of that spectrum — it's structural, not visual, and you can get it completely right or completely wrong without a single mockup existing yet. Navigation is downstream of IA: it's the mechanism (tabs, menus, breadcrumbs) that exposes a structure to a user, and a good navigation pattern applied to a bad structure just makes the bad structure easier to get lost in faster.

The throughline an interviewer is listening for: can you separate "how is this content organized" from "how is that organization displayed," validate the organization with real users before committing to it, and then pick a navigation pattern for reasons tied to the content's shape rather than convention or taste.