interface-architecturelisted

# Interface Architecture ## Mission Design the structure that makes an interface understandable before visual polish hardens it. ## Task hierarchy Identify primary, supporting, rare, destructive, setup, and recovery tasks. Architecture follows user work, not internal data models. ## Surface selection Choose among inline, popover, menu, sheet, dialog, page, or workspace according to context required, task duration, information volume, frequency, reversibility, and interruption cost. Do not use a dialog for work that needs surrounding context. Do not create a full page for a tiny contextual decision without reason. ## Navigation Navigation should answer: - where am I? - what else exists? - what is related? - how do I return? - what happens to current state? Prefer specific labels and predictable hierarchy. ## Grouping Proximity implies relationship. Group controls that affect the same object or task. Separate controls when grouping would imply a false relationship. ## Component responsibility For each component define what it knows, controls, exposes, and owns. Avoid both giant components and meaningless fragmentation. ## Information hierarchy Establish primary information, secondary information, supporting metadata, actions, advanced controls, and system feedback. Hierarchy must survive narrow widths, long content, localization, zoom, loading, and errors. ## Progressive disclosure Hide complexity only when the common user does not need it and advanced users