Design work

Interaction architecture organizes the work users came to do.

The architecture of an interface should follow the role and task model: what objects matter, which tasks are primary, which actions belong together, and where feedback must appear.

Definition

Interaction architecture is the structural design of the user interface. It covers workspaces, navigation, major objects, commands, status, feedback, and the relationships among them. It is still more abstract than final visual design.

The goal is to make the system's organization match the user's task organization closely enough that use feels direct and learnable.

Inputs From Earlier Models

Input model	What it contributes	Architectural decision it informs
Role model	Who needs which capabilities and how often.	Role-specific entry points, permissions, dashboards, and guidance.
Essential use cases	User intentions and system responsibilities.	Commands, forms, feedback points, and completion states.
Task model	Sequence, frequency, variants, and handoffs.	Navigation, workflow continuity, cross-role state, and notifications.

Workspace Design

A workspace is a coherent place to perform a family of tasks around shared objects and context. In operational software, workspaces often matter more than page count because users need to maintain orientation while acting.

Group tasks that share the same domain object and role context.
Expose the current object, status, constraints, and available actions together.
Keep high-frequency actions near the working context.
Separate setup, exception handling, and administration when they have different risks.
Preserve state when users move between related tasks.

Navigation And Access

Navigation should reflect how work is found, resumed, delegated, and completed. A navigation tree based only on database entities can make sense to developers and still fail the role model.

Role-based access

Primary roles should have direct access to their main work. Secondary or administrative roles can use narrower entry points.

Task-based grouping

If users think in cases, orders, claims, studies, or incidents, navigation should respect those work containers.

Recovery paths

Support returning to interrupted work, resolving failed submissions, and finding items awaiting action.

Status visibility

Users need to know what has happened, what is pending, and which role owns the next step.

Interface Objects

Interface objects are the things users act on directly: a customer account, a claim, a reservation, a route, a message, or a schedule. Good architecture chooses interface objects that make sense in the work domain rather than exposing raw database structure.

Database-centered

Separate menus for Customer Table, Address Table, Contract Table, and Billing Table.

Use-centered

A customer workspace that gathers identity, service, contract, billing, and tasks relevant to the current role.

Architecture Checklist

Can each primary workspace be traced to roles and task clusters?
Are high-frequency tasks reachable without navigation clutter?
Are exception and recovery paths represented, not merely error messages?
Can the user see enough context to decide safely?
Does the structure leave room for visual design without depending on it?