A museum ticketing kiosk's menu has grown to forty options and visitors miss features it already has; how would you diagnose and restructure its information architecture?
answer
- evidence before a new menu
- inventory, logs, desk questions
- top tasks at the top level
- broad and shallow, within limits
- baseline tree test, then compare
basics
~20 sMeasure first: inventory the options, use kiosk logs and desk questions to find top tasks and failures, then rebuild the structure around those tasks in visitors' words, and tree-test the new hierarchy against the old before shipping.
solid answer
~50 sI would start with evidence rather than a new menu. An **inventory** of all forty options with their usage and abandonment from the kiosk's logs, plus what visitors ask staff at the desk, shows which features are missed and which are rarely needed. I would check the current **organization scheme** — accreted menus usually mix audience, topic and task in one list — and the **labels**, which often reflect departments. Then an open card sort with visitors to learn their groupings, a draft structure whose top level is the few **top tasks** (buy, collect a booking, member entry), and a **tree test** against a baseline of the current tree. For a kiosk I would favour a fairly **broad, shallow** hierarchy within screen limits, add **wayfinding** — a clear title on every screen and an always-available way to start over — and after launch track completion and desk escalations for the tasks that were failing.
go deeper
Recall that missed features usually mean a structure or labelling problem, and that evidence comes before redesigning the menu.
Explain the breadth-versus-depth trade-off, why the seven-plus-or-minus-two finding does not cap menus, and what wayfinding cues a kiosk needs.
Demonstrate the full sequence: inventory and logs, diagnosis, card sort, task-based top level, baseline and comparative tree tests, post-launch measures.
Set a policy for how new options earn a top-level slot, so the structure does not re-accrete once the restructure ships.
## Why accreted structures fail Kiosk menus rarely start at forty options. They grow one request at a time: a donation prompt, a new exhibition, a school-group flow, a gift-aid option. Each addition lands wherever its owner could get a slot. The result usually has three defects at once: **mixed organization schemes** in one list, **internal labels** that reflect departments, and **no hierarchy of importance**, so the tasks most visitors came for sit among options few people need. Features then exist but are not found — the classic findability failure. ## Step 1: gather evidence - **Content inventory**: every option, where it sits, who owns it, what it leads to. - **Usage and abandonment**: from kiosk logs, how often each option is chosen, and where sessions are abandoned or restarted. - **Desk escalations**: what visitors ask staff that the kiosk could have done — the strongest evidence of missed features. - **Existing complaints and help requests**, in visitors' own words. - **A baseline tree test** of the current structure with the key tasks, so the redesign has something to beat. ## Step 2: diagnose | Symptom | Likely IA cause | |---|---| | Visitors with online bookings queue at the desk | “Collect tickets” is buried or labelled in internal terms | | Many restarts from the same screen | Two sibling labels compete, or the scheme changes mid-list | | Members buy full-price tickets | Member entry sits under a department name visitors do not recognise | | Rare options are chosen by mistake | Top level is crowded with low-value items that look like main tasks | | Long hesitation on the first screen | Too many unranked options with no clear grouping | ## Step 3: restructure 1. **Identify the top tasks** — the few goals that cover most sessions — from usage and desk evidence. 2. **Run an open card sort** with visitors on the remaining content to learn their groupings and words. 3. **Choose one scheme per level**: a task scheme at the top, then time or audience where it fits. 4. **Label in visitors' words** and check siblings for overlap. 5. **Cross-list** items that genuinely belong in two places, sparingly. 6. **Retire or demote** options that serve almost nobody, with their owners' agreement. ## Breadth, depth and the kiosk Every hierarchy trades **breadth** (options per screen) against **depth** (levels to reach an item). Studies of menu structures have generally found that moderately broad, shallow hierarchies outperform deep ones, provided each screen stays scannable and its options are clearly grouped; every extra level is another chance to guess wrong. A walk-up touchscreen limits how many large targets fit on a screen, so the practical answer is a **short top level of top tasks**, each opening a well-grouped second level, with little beyond that. The “seven plus or minus two” finding is often cited as a menu limit. It concerns how many items people can hold in short-term memory; choosing from a visible menu is **recognition**, not recall, so it does not set a cap. The real limits are screen space, scannability and grouping. ## Wayfinding on a walk-up device Findability is getting to the right place; **wayfinding** is knowing where you are and how to get elsewhere. On a kiosk there is no familiar system back button or address bar to fall back on, so the structure must supply: - a clear **title** on every screen that matches the label the visitor chose; - a visible sense of **position** in a multi-level flow; - an always-available way to **go back** one level and to **start over**; - the **same location** for these controls on every screen. ## Step 4: validate and measure Tree-test the proposed structure with the same tasks as the baseline and compare task by task, looking for tasks that got worse as well as the average gain. After launch, track completion for the previously failing tasks, restarts, and desk escalations for things the kiosk now handles. The same process applies to a website or a native mobile app that has grown by accretion; the kiosk simply makes the cost of a bad structure visible as a queue.
- Should a kiosk rely on search to fix findability?Rarely as the main fix. Typing on a walk-up touchscreen is slow, and people often do not know the right term. Search helps known-item lookups, and its queries are useful evidence of people's vocabulary, but the structure and labels still have to work for browsing.
- Does the seven-plus-or-minus-two finding limit how many options a menu screen can hold?No. That finding concerns how many items people hold in short-term memory; choosing from a visible menu is recognition, not recall. Limits come from screen space, scannability and clear grouping, and broader, well-grouped menus often beat deeper ones.
- How do you handle an option that belongs under two top-level tasks?Cross-list it: place the same destination under both parents where people look, labelled consistently. Overused, cross-listing blurs categories and inflates menus, so reserve it for items that card sorts or tree tests show people genuinely split on.
saying these in an interview costs you the question
- Menus must hold at most seven items because of short-term memory limits.
- Adding search makes the underlying structure irrelevant.
- Promoting every missed feature to the home screen fixes findability.
- A deeper hierarchy is always easier because each screen has fewer choices.
- A restructure can ship on stakeholder agreement without testing the new tree.