Work Domain Analysis¶

Status: emerging
Last updated: 2026-07-08
Sources: Burns Hajdukiewicz 2004 Ecological Interface Design.Pdf
Tags: [work-domain-analysis, abstraction-hierarchy, ecological-interface-design, means-ends, part-whole-hierarchy, cognitive-work-analysis]

Summary¶

Work Domain Analysis (WDA) is the method that supplies the domain content an Ecological Interface Design (EID) display must represent. It models the environment a user controls, rather than the tasks the user performs, by combining two structures: an Abstraction Hierarchy that describes the domain across five ordered levels of abstraction, and a Part-Whole Hierarchy that decomposes the domain into subsystems and components. The five abstraction levels are connected by means-ends (how/why) links, so that each lower level explains how the level above is achieved and each higher level explains why the level below exists. The analysis proceeds from a defined system boundary, is built top-down then bottom-up then through the middle, and is checked for completeness through connection review, language consistency, and validation exercises such as scenario mapping. The value of a completed model is judged by the new variables and relationships it makes available for display design.

Body¶

Context¶

Chapter 2 of Burns & Hajdukiewicz (2004) sets out how to build a work domain model, the domain-content foundation on which the rest of the EID method depends. The chapter works through defining a system of interest, the Abstraction Hierarchy and its five levels, means-ends links, the Part-Whole Hierarchy, the combination of the two into a full work domain model, extensions for social constraints and multiple regions of control, and a step-by-step build procedure with completeness checks. Within this knowledge base the article sits under the Ecological Interface Design hub and connects to Task Analysis, which the chapter treats as a complementary rather than substitute method, and to Representation Design, the downstream stage that consumes the model's variables.

Key Points¶

WDA defines its object of study differently from user-centered methods. Whereas task-based approaches begin with the user, WDA begins with the environment that the user controls, and its first step is to draw a system boundary. Anything the user must control, monitor, or supervise, and anything that interacts with the user's work, is placed inside; the interface, databases, signal-acquisition and input/output devices, and anything being designed or redesigned are placed outside. A boundary drawn too tightly omits relevant constraints, while one drawn too broadly wastes effort, and when the correct scope is uncertain the analyst is advised to err toward breadth (PDF pp. 48-49, orig. pp. 13-14).

The Abstraction Hierarchy is the primary tool of WDA and is adapted from the engineering technique of Functional Decomposition. It is a tree-like structure whose levels are ordered along the dimension of abstraction, meaning how closely an element describes the physical nature of the domain versus its purpose. Purpose and physical form are the two anchors, with intermediate levels between them (PDF pp. 49-51, orig. pp. 14-16). Five levels are used: Functional Purpose (what the domain was designed to do, expressed as at least two generic, potentially conflicting purposes with evaluative criteria), Abstract Function (the causal laws and conservation principles, and the flows of mass, energy, information, money, or force through the system), Generalized Function (the processes that achieve those causal relationships), Physical Function (the components and their capabilities and limitations), and Physical Form (the size, shape, color, location, condition, and material of components) (PDF pp. 51-58, orig. pp. 16-23).

The levels are joined by means-ends links, described as how/why links: reading downward answers how a function is accomplished, and reading upward answers why a function exists. A functional representation of the hierarchy shows these across-level means-ends links, whereas a causal representation preserves the same structure but instead draws the within-level flow links, which are most informative at the Abstract and Generalized Function levels; both representations are usually developed (PDF pp. 62-63, orig. pp. 27-28). A recurring discipline is to keep purposes distinct from tasks and processes distinct from tasks: purposes are constant attributes of a system obtained by questioning or reflection, while tasks are variable actions observed over time, and a work domain model deliberately excludes monitoring, detecting, managing, and reporting actions that the eventual interface will support (PDF pp. 54-57, orig. pp. 19-24).

The second structure is the Part-Whole Hierarchy, which decomposes the domain by aggregation from system to subsystem to component, using "contains" going down and "is part of" going up. Unlike the Abstraction Hierarchy it has no fixed number of levels. A full work domain model places the Abstraction Hierarchy on the vertical axis and the Part-Whole Hierarchy on the horizontal axis, forming a matrix; the two dimensions are not fully orthogonal, since some cells (such as the purpose of a whole system) are more useful than others (such as the purpose of an individual component). The Part-Whole levels also guide display grouping, with system and subsystem levels indicating overview or status displays and the component level indicating detailed control displays (PDF pp. 64-66, orig. pp. 29-31).

The chapter extends the basic model to domains whose constraints are not only physical. In domains such as the military, social rules, values, and rules of engagement act as legitimate constraints and can be modeled in the same style, with a purpose, principles, processes, and physical instantiations, though the standard level labels fit these constraints only loosely (PDF pp. 66-67, orig. pp. 31-32). For large models the authors recommend two management techniques: systematic decomposition, in which the Part-Whole Hierarchy is built first and each decomposition placed on a separate page to keep multiple analysts consistent, and link tables, which record the rationale for each between-level link so it is not forgotten later (PDF pp. 67-69, orig. pp. 32-34). Where a domain contains distinct regions of control that the user does not fully command, such as ambulance dispatching or aircraft navigation, a separate model is built for each region while crossovers between them are tracked, since those interactions are often the richest source of domain information (PDF pp. 69-71, orig. pp. 34-36).

Formal testing of a work domain model is difficult because a model is a representation whose form and detail can legitimately vary, so usefulness is treated as the ultimate test. Validation should confirm that the modeled relationships exist and that no information is missing within scope, and should avoid arguments over representation, over scope, or over prioritizing elements by frequency, because a rarely used constraint can be decisive in an accident. Two recommended validation techniques are scenario mapping, in which domain experts walk through operational scenarios in their own language while the analyst checks and translates coverage onto the model, and questionnaires translated from model elements, worded operationally and probing connections up and down the levels (PDF pp. 71-76, orig. pp. 36-41).

The chapter closes with a build procedure and nine hints. The recommended order is: define the system of interest (erring on breadth); build the Abstraction Hierarchy from the top by determining at least two purposes with performance criteria; then work from the bottom by listing components and their form, excluding the interface and, usually, controllers; then complete the two middle levels; then verify that every box has a connection up and down, resolving any unconnected box as a sign of something missing, extra, or misplaced; check that each level uses its own distinct language; and develop detail only as time allows, favoring breadth over depth. The final two steps are to translate the hierarchy into variables, constraints, and relationships (the subject of Chapter 4) and to show the value of the analysis by comparing its variables and relationships against those on the current display, since new variables or relationships signal readiness to begin designing an EID (PDF pp. 76-81, orig. pp. 41-46).

Conclusion¶

Work Domain Analysis produces a model of the constraints and functions of the environment a user controls, organized so that means-ends links tie purpose to physical form across five levels of abstraction and Part-Whole decomposition supplies the levels of detail. Built systematically from a defined boundary and checked for completeness rather than validated formally, its worth is measured by the variables and relationships it surfaces for display design, which is the point at which EID work can begin.

Related¶

• Ecological Interface Design
• Task Analysis
• Representation Design
• Interface Design Language
• Wda In Design

References¶

Burns, C.M. & Hajdukiewicz, J.R. (2004) Ecological Interface Design. Boca Raton, FL: CRC Press. burns2004ecological

Bisantz, A.M., Roth, E., Brickman, B., Gosbee, L.L., Hettinger, L. & McKinney, J. (2002) 'Integrating cognitive analyses in a large-scale system design process', International Journal of Human-Computer Studies (cited by Burns & Hajdukiewicz for two contrasting work domain models). To be validated (PDF p. 71, orig. p. 36).

Burns, C.M., Bryant, D. & Chalmers, B. (2001) Scenario mapping with work domain analysis (cited as the origin of the scenario mapping technique; full reference to be confirmed). To be validated (PDF p. 73, orig. p. 38).

Jamieson, G.A. (2003a) Petrochemical work supporting ecological interface design (cited example of combining task analysis with EID). To be validated (PDF p. 57, orig. p. 24).

Rasmussen, J. (1985) 'The role of hierarchical knowledge representation in decisionmaking and system management', IEEE Transactions on Systems, Man, and Cybernetics, SMC-15(2), pp. 234-243. Proposed the Abstraction Hierarchy framework. To be validated (PDF p. 48, orig. p. 13).

Ulrich, K.T. & Eppinger, S.D. (2000) Product Design and Development. New York: McGraw-Hill. Source of the Functional Decomposition technique. To be validated (PDF p. 50, orig. p. 16).

Open Questions¶

• How does the translation of a work domain model into variables, constraints, and trade-off relationships (Chapter 4) map onto the visual forms used in EID displays?
• What criteria distinguish a domain that warrants separate models for different regions of control from one that can be captured in a single Part-Whole decomposition?
• How are the loosely fitting level labels for social constraints reconciled with the physical-constraint labels when a domain, such as the Halifax Class frigate, mixes both?