Interface structure should match task structure, not organizational or technical implementation structure

What it is

Structure matching means grouping, ordering, and entry points follow the user’s mental steps through a task: preparation, review, publication, and exception handling should be continuously reachable; backend service names, database tables, departments, or reporting lines should not become a navigation layer users must understand.

Why it happens

Users arrive with goals and predict the next step as “what does this task still need,” not “which team or module owns it internally.” When structure matches, paths, fields, states, and permissions appear in task order, and working memory tracks only the current goal. When it does not, users translate organizational or technical vocabulary, gather one task’s material across pages, and remember that separate steps belong to one intent. As tasks grow complex, translation cost and omissions increase.

Studying it

Start with task analysis: triggers, required information, role handoffs, decisions, exceptions, and completion evidence. Compare that model layer by layer with the information architecture. Use task-based card sorting, path observation, and logs to test whether users can reach an entry from the goal, where they return, which steps they skip, and where they reenter data. Compare task-based and organization- or technology-based versions, measuring completion, path length, interruptions, and support requests.

Where it stops holding

Task structure is not the only legitimate structure. Administrators may work by permission governance, auditors by process stage, and operations staff by customer segment; a system serving several primary tasks must rank and layer them. Technical structure sometimes affects performance and reliability and cannot be wished away, but it can be placed where users do not have to make decisions. Compressing every role into one path can slow experts.

Applying it

• Write a goal-step-state diagram for each core user, then check whether every step’s entry, data, and feedback are continuous.
• Rename departments, services, tables, and modules with task-object names; put technical detail in diagnostics or help.
• Give high-frequency tasks an end-to-end path that preserves context, drafts, and selected conditions across pages.
• Track one real task from trigger to completion and count cross-module jumps, repeated input, and interruption points.

Related

• Same group: B2.25.2 Conceptual integrity means covering all functionality with as few consistent concepts as possible · B2.25.3 Adding a new concept costs more learning than adding a function under an existing concept · B2.25.4 Independent design by multiple people without a shared concept model necessarily creates conceptual redundancy and near-equivalent controls
• Nearby: G1 Navigation and Information Architecture · H1 Interaction Patterns and Flows
• Search terms: task analysis · information architecture · conceptual structure