Experience-Based Decomposition (EBD)
Organizing Interface Architecture Around Human Intent: A Framework
Author: William Christopher Anderson Date: April 2026 Version: 1.0
Executive Summary
The most common complaint about user interfaces in long-lived products is not that individual screens are poorly designed. It is that changing anything requires touching everything. A wizard gains a conditional step; navigation logic scattered across twelve components must be updated. A new user segment arrives; flow assumptions baked into leaf components need untangling. A new locale is added; string literals buried in state machines surface one by one.
The structural cause of this is well understood in backend systems — responsibilities distributed across the wrong boundaries — yet the interface layer repeatedly inherits the same problem, dressed differently. Screens are not boundaries. Components are not boundaries. Routes are not boundaries. None of these are units of human purpose, which is the only boundary that remains stable as products evolve.
Experience-Based Decomposition addresses this by establishing human intent as the organizing principle of interface structure. It defines three architectural tiers:
- Experiences represent complete user journeys — composable, stable, and bounded by purpose rather than screen count.
- Flows encapsulate the goal-directed sequences within an experience. They own one goal, one set of accumulated state, and one set of exit conditions.
- Interactions are atomic. A selection, an input, a confirmation. They cannot be meaningfully subdivided from the user's perspective.
Shared utility components handle cross-cutting concerns — locale, theme, validation, alerts — without acquiring knowledge of any particular user purpose. A small set of core user journeys validates that the architecture supports real human intent without boundary leakage.
When this structure is in place and backed by an event-driven communication model, something more powerful becomes possible: experiences can be defined and composed through configuration rather than code. An organizational configuration, a feature flag, an audience-specific ruleset — any of these can alter what an experience contains, in what order flows execute, and how the backend responds to their completion events. The interface becomes programmable at the intent level, not just the component level.
EBD applies most directly to long-lived products, systems serving multiple audience types with distinct mental models, and any product that must remain coherent across years of continuous evolution.
Abstract
Product interfaces operate under continuous revision. Requirements arrive from user research, competitive pressure, regulation, and organizational restructuring, each demanding changes that rarely respect the edges of existing screens or components. Conventional approaches to interface construction organize code around what the system presents rather than what the user intends to accomplish. As the product grows, every meaningful change touches more than it should. The cost of evolution eventually outpaces the value it delivers.
Experience-Based Decomposition is a decomposition framework that treats human intent as the primary structural force in UX design. It introduces a three-tier hierarchy — Experiences, Flows, and Interactions — defines explicit roles, responsibilities, and communication rules for each, and validates structural decisions against a small set of core user journeys. It further describes how an event-driven communication model, when combined with external configuration, enables experiences to be composed and routed dynamically — decoupling UX structure from code in the same way that Volatility-Based Decomposition decouples system behavior from system structure. This paper provides a practitioner-oriented articulation of EBD, covering its structural model, communication discipline, configuration-driven composition, and application across real product contexts.
1. Introduction
Interface design has accumulated considerable practice rigor over the past three decades. Interaction design, information architecture, accessibility standards, and component design systems have each contributed real improvements to how products are conceived, constructed, and maintained. Despite this, the underlying architectural problem — how to structure the interface layer so that it absorbs change gracefully — remains largely unsolved in most codebases.
The most expensive interface changes are not redesigns. They are the routine ones: a new field in a form that ripples through five components, a conditional step that requires refactoring a navigation model, a new organizational unit that invalidates assumptions embedded in a dozen places. These changes are expensive not because they are complex in themselves, but because the structure of the codebase offers no natural home for the logic they require. Each modification finds space where it can, distributing responsibility in ways that make the next modification more expensive.
The root cause is misalignment between what the code is organized around and what the user is organized around. Code is organized around screens. Users are organized around purposes.
A user opening a developer onboarding tool is not navigating to a screen. They are pursuing a goal — getting their environment configured correctly — and that goal may involve seven screens, four API calls, three conditional branches depending on their organization's configuration, and a different set of form fields than their colleague sitting next to them. None of that variation lives in the goal itself. The goal is stable. The implementation of it is what varies.
Experience-Based Decomposition organizes the interface layer around that distinction. Structure follows intent. What varies is isolated from what endures. The principles are the same ones that underpin Volatility-Based Decomposition at the system level — applied here to the surface that users actually touch.
2. Background
2.1 Screen-Centric Organization and Its Consequences
Frontend frameworks present an implicit model: routes map to pages, pages contain components, components contain logic. This model works well enough when an interface is small and stable. It begins to break down when the product matures and the implementation becomes load-bearing in unexpected places.
The specific failure mode is familiar. State that belongs to a multi-step sequence ends up in a parent component managing all steps. Navigation decisions that depend on user context end up duplicated across components that each independently try to determine what the user should see next. Business logic — what counts as a valid selection, when a step can be skipped — migrates into presentation components because there is no structural location for it that is clearly correct.
Once this pattern takes hold, it is self-reinforcing. New code follows existing patterns. The next engineer to add a feature adds it where similar features already live. The structural debt compounds.
Figure 1a shows the screen-centric failure mode: logic accumulates everywhere because screens are not boundaries. Figure 1b shows EBD's intent-centric structure: each tier has one responsibility.
Figure 1a — Screen-Centric Organization
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%
flowchart LR
S1["Screen A"]
S2["Screen B"]
S3["Screen C"]
S1 <-->|"navigation + state"| S2
S2 <-->|"navigation + state"| S3
S1 -.->|"validation duplicated"| S3
Figure 1b — Intent-Centric Organization (EBD)
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%
flowchart TD
EX["OnboardingExperience"]
FL["UserInfoFlow"]
IN["FormField / DropdownSelect"]
UT["Locale / Theme"]
EX -->|"composes, passes state"| FL
FL -->|"renders"| IN
IN -.->|"emits event"| FL
FL -.->|"emits completion"| EX
FL --> UT
IN --> UT
2.2 Component-Based Thinking and Its Limits
The dominant response to screen-level fragility has been the component library: shared, composable UI primitives that enforce visual consistency and reduce repetition. This approach has genuine value. Reusable components reduce duplication. Design systems create coherence. Neither addresses decomposition.
A component library answers the question: how do we build consistent interface elements? It does not answer the question: where does navigation logic live? Who owns multi-step state? What happens when a step should be skipped? Those questions require a structural model, not a component model.
Brad Frost's Atomic Design methodology made an important contribution to this problem by establishing a vocabulary for hierarchical component composition — atoms, molecules, organisms, templates, pages. The hierarchy is real and useful at the component level. What it does not provide is a model for the behavioral hierarchy: the distinction between an atomic interaction (selecting an item), a goal-directed sequence (choosing a configuration profile), and a complete user journey (onboarding a developer). Atoms and molecules are structural units. Interactions, flows, and experiences are intentional units. Both taxonomies are necessary; neither replaces the other.
2.3 Goal-Directed Design as a Precursor
Alan Cooper's goal-directed design methodology, articulated in About Face, established the foundational insight that interfaces should serve user goals rather than reflect system capabilities. Cooper argued that personas and scenarios should drive interaction design decisions — that the question is not what the system can do but what the user is trying to accomplish.
EBD extends this insight structurally. It is not sufficient to design around user goals at the specification level if the implementation is organized around screens. The goal-directed principle must persist into the codebase structure, or it dissipates at the moment implementation begins.
3. The Four Axes of Interface Volatility
Before defining the structural model, it is useful to characterize where change actually occurs in interface systems — the same volatility analysis that underpins Volatility-Based Decomposition at the system level, applied here to the interface layer.
3.1 Functional Volatility
Changes in what the user is asked to do — new fields, new validation rules, new options, added or removed steps. This is the most frequent category of interface change, driven by product decisions, user research findings, regulatory requirements, and organizational configuration differences. When functional volatility is not isolated, a single new field type forces changes across presentation, validation, state management, and API layer simultaneously.
3.2 Non-Functional Volatility
Changes in how journeys compose — a new audience type requiring a different path through the same flows, a new entry point, a conditional sub-journey that applies only to a segment of users. Non-functional volatility at the interface layer is less frequent but carries higher impact, because it affects the composition of the interface rather than any individual component.
3.3 Cross-Cutting Volatility
Changes to concerns that propagate broadly without belonging to any particular flow: locale strings, visual themes, form validation conventions, error presentation formats, accessibility requirements. These change independently of user goals and should be isolated in shared utilities that flows and interactions consume without embedding.
3.4 Environmental Volatility
Changes to the external systems the interface depends on — backend API shapes, authentication mechanisms, configuration schemas. This is the interface's equivalent of the integration volatility that Resource Accessors handle in VBD. It should be contained at a thin boundary layer rather than distributed across flows.
Figure 2 maps each volatility axis to the structural tier responsible for containing it.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%
graph TB
subgraph axes["Four Axes of Interface Volatility"]
FV["Functional"]
NF["Non-Functional"]
CV["Cross-Cutting"]
EV["Environmental"]
end
subgraph tiers["Containing Tier"]
INT["Interaction"]
EXP["Experience"]
UTL["Utility"]
end
FV -->|isolated by| INT
NF -->|isolated by| EXP
CV -->|isolated by| UTL
EV -->|isolated by| EXP
4. The Structural Model
Experience-Based Decomposition organizes the interface into four structural roles. Each has a defined scope, a bounded set of responsibilities, and explicit rules governing communication with the other roles.
4.1 Experiences
An experience is a complete user journey bounded by a human intent — the arc from initiation to fulfillment. It is the answer to the question: what did this user come here to accomplish?
Experiences are the most durable tier. The intent behind a developer onboarding experience — understand the organization's configuration requirements, provide personal context, complete the setup — endures across product iterations, new configuration types, new field types, and new platform targets. An experience should be reconsidered only when the underlying human purpose changes, which is rare.
An experience owns the composition of flows that constitute the journey, the complete state accumulated across all of them, the transitions and terminal conditions, and the top-level progress representation. It is also the only tier that communicates with the backend. When the journey reaches a point where accumulated state should be acted on — a checkpoint, a completion — the experience emits that state as a single coherent event. It holds everything. It decides what comes next.
This gateway role is not incidental. Because the experience has the full picture across all flows, it is the only component that can make a meaningful decision about when and what to send to the backend. A flow knows only its own scope. The experience knows the journey.
An experience MUST NOT implement flow-level progression logic. An experience MUST NOT render interaction components directly. An experience MAY compose other experiences as bounded sub-journeys. An experience MAY receive configuration that determines which flows it contains and in what order. An experience MAY call the backend API, passing accumulated journey state as a completion event.
4.2 Flows
A flow is a goal-directed sequence of interactions that accomplishes one discrete outcome within an experience. It is bounded by its goal. One flow, one purpose. The selection of a configuration profile is a flow. The collection of user information is a flow. The confirmation of an installation is a flow. None of these is a screen, though each may render through one.
Flows sit at the most structurally important tier — the one most commonly absent from interface codebases. Because they have no natural representation in screen-first frameworks, flow logic ends up distributed: navigation conditionals in parent components, validation in leaf components, accumulated state in global stores. When the flow has no home, everything becomes its home.
A flow owns its progression through interactions and the state it accumulates across them. It does not communicate with the backend — that is the experience's concern. When a flow finishes, it emits its accumulated state upward. What happens with that state is not the flow's decision.
A flow MUST NOT coordinate directly with sibling flows. A flow MUST NOT make direct API calls. A flow MUST NOT render utility components as owned children — it invokes them. A flow MAY emit a completion event carrying accumulated state upward to the experience. A flow MAY skip itself entirely if its entry conditions are not met, signaling the experience to advance.
4.3 Interactions
An interaction is the smallest observable unit of user action — atomic and indivisible from the user's perspective. Selecting from a list, entering text, toggling a checkbox, clicking a button, reading a status message. Interactions are the surface. They are what users actually touch.
Interactions are the most volatile tier. The specific fields a given configuration requires changes between organizations. Labels, placeholders, and help text change with locale. Control types — a dropdown becoming a searchable select, a checkbox becoming a toggle — change with design decisions. Because interactions are the most likely to change, they must be the most isolated.
An interaction owns its visual presentation, its internal display state (focused, disabled, errored), and the event it emits when the user acts.
An interaction MUST NOT contain flow progression logic. An interaction MUST NOT make direct API calls. An interaction MUST NOT be aware of adjacent interactions. An interaction MAY use utility components for locale rendering, validation display, and alert presentation.
4.4 Utilities
Utilities encapsulate capabilities that cut across all three tiers without belonging to any of them. They are consumed; they do not consume. They have no knowledge of user journeys, specific goals, or the context in which they are invoked.
Locale rendering, visual theme application, progress indication, field validation, and alert presentation are all utility concerns. A locale renderer that knows it is rendering an onboarding string has violated its boundary. The same utility that renders "Next" in English should render "Suivant" in French without any awareness of which flow requested the translation.
A utility MUST NOT contain flow progression logic. A utility MUST NOT hold domain-specific state. A utility MUST NOT coordinate workflows or make decisions on behalf of flows.
Figure 3 shows the complete structural model and the communication rules between roles.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'edgeLabelBackground': '#ffffff'}}}%%
flowchart TD
EXP["Experience"]
FLW["Flow"]
INT["Interaction"]
UTL["Utility"]
CFG["Configuration"]
CFG -->|"defines flow composition"| EXP
EXP -->|"composes, passes state"| FLW
EXP -->|"embeds as sub-journey"| EXP
FLW -->|"composes, passes props"| INT
INT -.->|"emits event"| FLW
FLW -.->|"emits completion"| EXP
INT --> UTL
FLW --> UTL
EXP --> UTL
5. Communication Rules
The structural boundaries described above are only as strong as the discipline applied to communication between roles. A flow that calls another flow directly has already coupled itself to that flow's internal state model, regardless of how cleanly each is implemented in isolation.
The governing rule is directional: state flows downward; results propagate upward as events. An experience passes configuration and shared state to flows. Flows pass props and callbacks to interactions. Interactions emit events — they do not call flows. Flows emit completion events — they do not call experiences. No tier reaches sideways. No tier reaches up.
Backend communication is the exclusive domain of the experience. A flow that discovers it needs to call an API has exceeded its scope — it has taken on a decision that belongs one tier up. The experience holds the complete state of the journey. It is the only component with enough information to know when that state is ready to be sent somewhere, what form it should take, and what should happen next in response. Flows surface their state upward and wait for the experience to advance them.
This containment prevents the most common failure mode: a flow that accumulates awareness of sibling flows and backend responses, gradually becoming a de facto experience manager while remaining architecturally classified as a flow.
The second governing rule addresses cross-tier calls: nothing calls a utility; everything consumes it. Utilities are invoked inline, not coordinated. A flow does not ask a locale utility to translate a string and then wait for a response. It calls t("buttons.next") and receives a string. The distinction matters because a utility that receives callbacks or coordinates timing has begun behaving like a flow.
Figure 4 shows the lifecycle of a single flow — how it receives context from the experience, collects state through interactions, and resolves to a completion event.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%
stateDiagram-v2
[*] --> Entering : Experience calls enter(sharedState)
Entering --> CheckSkip : Evaluate entry conditions
CheckSkip --> Skipped : Conditions not met
CheckSkip --> Active : Conditions met
Skipped --> [*] : Emits skip() to Experience
Active --> CollectingState : Render interactions, wait for events
CollectingState --> CollectingState : Interaction emits event; flow accumulates state
CollectingState --> Validating : User requests advancement
Validating --> CollectingState : Validation errors — return to interactions
Validating --> Complete : All valid
Complete --> [*] : Emits flowComplete(accumulatedState) to Experience
6. Configuration-Driven Experience Composition
The structural model described in the preceding sections is valuable in its own right. It localizes change, clarifies ownership, and produces codebases where the user's intent is legible in the architecture. When combined with an event-driven communication model and external configuration, it enables something more significant: experience composition as a runtime concern rather than a compile-time one.
This is the natural extension of getting the structure right. If an experience is defined as a composition of flows, and that composition is expressed in data rather than code, then the composition itself becomes configurable. An organizational configuration artifact can specify which flows an experience contains, in what order they execute, and what conditions cause any of them to be skipped. Two users with the same interface binary can experience meaningfully different journeys based solely on configuration.
In practice, this requires three things:
A configuration schema that describes experience composition. A schema might specify required flows, optional flows, their execution order, and skip conditions for each. An organization that requires an additional compliance step presents a flow the standard user never sees. An audience segment with a simplified onboarding path skips flows irrelevant to their context. The same interface binary serves both, driven entirely by configuration.
An event-based communication model between the interface and the backend. When a flow emits a completion event, that event carries the accumulated state from the flow — the selections made, the information provided. A properly structured backend, upon receiving this event, can route the remainder of the transaction differently based on the same configuration that governed the interface. A user who selected the enterprise segment in an OrgProfileFlow may have their provisioning routed through a compliance-validation backend path that the standard user never encounters. The interface does not know about this routing. It emitted an event with a payload. The backend decided what to do.
Backend architecture capable of absorbing this routing. The techniques for achieving this on the backend — separating orchestration from execution, isolating integration concerns, routing workflow decisions through configurable managers — are described fully in Volatility-Based Decomposition in Software Architecture (Anderson, 2026). The interface-side pattern and the backend-side pattern are designed to compose: the same organizational configuration that drives flow selection in the experience layer drives route selection in the manager layer.
Figure 5 illustrates this end-to-end configuration-driven model.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#f8fafc'}}}%%
flowchart TD
subgraph config["Organizational Configuration"]
PC["org.config"]
end
subgraph ux["UX Layer — EBD"]
EXP["OnboardingExperience"]
FLOWS["Config · UserInfo · Segment · Setup"]
EXP -->|"composes"| FLOWS
end
subgraph ev["Event Boundary"]
EV["Completion Event"]
end
subgraph backend["Backend Layer — VBD"]
MGR["OnboardingManager"]
ENG["PolicyEngine · SegmentEngine"]
ACC["WorkspaceAccessor · IdentityAccessor · StorageAccessor"]
MGR -->|"invokes"| ENG
MGR -->|"invokes"| ACC
end
PC -->|"drives flow composition"| EXP
PC -->|"drives routing"| MGR
FLOWS -.->|"emits on complete"| EV
EV -->|"received by"| MGR
The consequence of this architecture is worth stating plainly. Once the interface is composed from configuration rather than code, the surface presented to different user segments, organizational units, or deployment contexts can diverge without any code change. A new organizational division that requires an additional configuration flow is accommodated by updating configuration, not by shipping new interface code. Feature flags that progressively surface new experiences to pilot users become a matter of configuration management rather than a deployment. The interface becomes programmable at the level of human purpose.
This is the intended endpoint of applying volatility-first thinking to the interface layer. The structural model localizes change. Configuration-driven composition removes the need for most change to touch code at all.
7. Core User Journeys as Architectural Validation
The concept of core use cases as architectural validation mechanisms appears in Volatility-Based Decomposition as a check against boundary leakage. The same technique applies here.
Core user journeys are intentionally narrow. Even complex products have a small number of genuinely core journeys — the high-level human purposes that define what the product is for. Most documented use cases and user stories are variations, edge cases, and exception paths around a much smaller set of essential behaviors.
An interface architecture is structurally sound if each core user journey can be traced cleanly through the Experience → Flow → Interaction hierarchy without bypassing structural rules. Specifically:
- A change within one flow must not require changes in a sibling flow.
- Adding a new interaction to a flow must not require modifying the experience.
- Introducing a new locale string must not require modifying any flow or experience.
- A new organizational configuration variant must produce a different experience composition without code changes.
If any of these conditions fails, the failure points directly to where the architectural boundary has been violated.
A product serving multiple audience types might define three core user journeys — initial onboarding, profile configuration, and workspace setup — each exercising the architecture across different volatility profiles. The onboarding journey exposes functional and non-functional volatility, as conditional paths and field sets differ by organizational segment. The configuration journey exercises the Experience's environmental boundary directly, translating accumulated user state into a backend API call. The setup journey validates the configuration-driven model, confirming that what the user sees is derived from recorded configuration rather than hardcoded assumptions about their context.
Figure 6 traces a multi-segment onboarding journey through the structural hierarchy.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'actorBkg': '#e0e7ff', 'actorBorder': '#4338ca', 'activationBkg': '#ede9fe', 'activationBorderColor': '#7c3aed', 'signalColor': '#4338ca', 'signalTextColor': '#1e293b', 'noteBkgColor': '#fef3c7', 'noteBorderColor': '#d97706', 'noteTextColor': '#1e293b'}}}%%
sequenceDiagram
actor User
participant OE as OnboardingExperience
participant CSF as ConfigSelectionFlow
participant UIF as UserInfoFlow
participant OPF as OrgProfileFlow
participant SF as SetupFlow
participant Util as Utilities
User->>OE: Opens onboarding
OE->>Util: t("steps.config_selection") · applyTheme()
OE->>CSF: enter()
CSF->>User: Renders configuration options
User->>CSF: Selects configuration profile
CSF-->>OE: flowComplete({ config })
OE->>UIF: enter(config)
UIF->>User: Renders fields from org configuration
User->>UIF: Fills required profile fields
UIF-->>OE: flowComplete({ userInfo })
Note over OE: GET /api/config/segments
alt Has optional segments
OE->>OPF: enter(config, segments)
OPF->>User: Renders segment selectors
User->>OPF: Selects organizational segment
OPF-->>OE: flowComplete({ segment })
else No optional segments
OE->>OE: advance — OrgProfileFlow skipped
end
OE->>SF: enter({ config, userInfo, segment })
SF->>User: Renders setup progress UI
SF-->>OE: flowComplete()
Note over OE: POST /api/onboard { config, userInfo, segment }
OE->>User: Renders completion and next steps
8. Architectural Watchpoints
Interaction Scope Creep
Interaction components that begin making API calls or managing flow state have absorbed responsibility that belongs one tier up. This pattern typically emerges when a team adds a feature to the most convenient location rather than the correct one. The correction is to extract the logic into the flow and reduce the interaction to its atomic role.
Flow Awareness of Siblings
A flow that checks the state of a sibling flow — even through a shared store — has created a hidden coupling that the structural model was designed to prevent. When a flow needs data produced by another flow, that data should be passed downward from the experience as shared state. If this happens repeatedly, it suggests the experience boundary needs reexamination.
Configuration Complexity Threshold
Configuration-driven composition is powerful, but configuration schemas that grow unconstrained become their own maintenance problem. The same volatility analysis applied to code should be applied to configuration: stable aspects of experience composition belong in code; variable aspects belong in configuration. The boundary between them should be explicit and documented.
Utility Drift
Utilities that accumulate knowledge of specific flows, user types, or domain rules have crossed from utility into engine territory. A validation utility that behaves differently for enterprise users is no longer a utility. The correction is to move the domain-specific logic into the flow and preserve the utility's domain-agnostic contract.
Experience Depth
Experiences may compose other experiences, but nesting beyond two levels increases coordination cost significantly. Deep experience composition is often a signal that the containing experience has grown into a product rather than a journey, and that the product-level structure needs a separate organizational model.
9. Relationship to Volatility-Based Decomposition
EBD and VBD share a single foundational premise: boundaries aligned with change produce systems that remain coherent as they grow. Applied at the system level, this insight produces the Manager-Engine-Accessor-Utility taxonomy. Applied at the UX level, it produces the Experience-Flow-Interaction-Utility taxonomy. The structural parallels are deliberate.
| VBD | EBD |
|---|---|
| Manager | Experience |
| Engine | Flow |
| Resource Accessor | Interaction |
| Utility | Utility |
| Core Use Case | Core User Journey |
| Communication rules (MUST/MUST NOT) | Communication rules (MUST/MUST NOT) |
| Volatility axis | Interface volatility axis |
| Configuration-driven routing | Configuration-driven experience composition |
The frameworks are designed to compose across the system boundary. When a flow emits a completion event, a VBD manager receives it and routes the subsequent work. Both are responding to the same organizational configuration. Neither knows about the other's internal structure. The contract is the event payload and the configuration schema — nothing more.
This alignment is not merely aesthetic. When both frameworks are applied consistently, changes to organizational configuration propagate through the full stack in a coordinated way: the interface renders different flows, the backend executes different paths, and neither layer required code modification. The configuration is the product. The code is infrastructure.
10. Practitioner Observations
The following observations emerge from applying Experience-Based Decomposition across multiple interface systems of varying scale, domain, and maturity. They are not specific to any single product or organization. They describe recurring structural patterns — some beneficial, some pathological — that practitioners encounter as EBD moves from a design-time concept to a living codebase.
10.1 The Flow Proliferation Pattern
Teams new to EBD consistently produce too many Flows in their initial decomposition. The root cause is a confusion between UI screens and behavioral steps. A wizard with five screens does not necessarily contain five Flows. A Flow owns a goal, not a screen. When a user selects a configuration preset and that selection has no independent lifecycle — no intermediate save, no resumability, no standalone value — it is likely an Interaction within a broader Flow, not a Flow in its own right. The correction is to ask: does this step have its own completion criteria and accumulated state? If not, it belongs inside a Flow that does. Teams that internalize this distinction typically reduce their initial Flow count by 30–50% during their first refactoring pass.
10.2 The Interaction Purity Challenge
Interactions are defined as atomic — the smallest unit of user action that cannot be meaningfully subdivided. In practice, Interactions gradually absorb Flow-level responsibilities. A date-picker Interaction begins making API calls to validate availability. A text-input Interaction starts tracking state across multiple steps. A toggle Interaction begins conditionally showing or hiding sibling Interactions based on business rules. The diagnostic is straightforward: if an Interaction imports services, manages state that survives its own unmounting, or references other Interactions by name, it has absorbed Flow logic. The fix is extraction — move the orchestration concern upward into the owning Flow and reduce the Interaction back to its atomic contract: accept props, render display state, emit events.
10.3 The Experience Scope Question
A recurring architectural question is whether a journey is large enough to be its own Experience or whether it should remain a Flow within a larger Experience. The diagnostic criterion is lifecycle independence. If the journey can be entered, suspended, resumed, and completed without reference to any enclosing journey, it has its own lifecycle and warrants Experience status. If it only makes sense as a step within a broader sequence — if suspending it means abandoning the enclosing journey — it is a Flow. A password-reset journey within a login Experience illustrates the boundary: password reset has its own entry point (a link), its own completion criteria (password changed), and can be abandoned without invalidating the login Experience. It is an Experience, not a Flow. A "confirm your selections" step within an onboarding journey has none of these properties. It is a Flow.
10.4 Bridging the Designer–Developer Vocabulary Gap
One of the less anticipated effects of EBD is the change it produces in cross-functional communication. Designers naturally think in journeys — the complete arc of what a user is trying to accomplish. Developers naturally think in components — the discrete units of rendering and behavior. These vocabularies are not wrong, but they are structurally misaligned, and the misalignment produces translation overhead in every handoff. EBD provides a shared structural vocabulary: designers describe Experiences and Flows, developers implement Flows and Interactions, and both groups use the same terms to refer to the same architectural units. Design reviews become architecture reviews. The question shifts from "which screens does this feature touch?" to "which Flows does this change affect, and does the Experience need to know?"
10.5 Accessibility as a Structural Consequence
When Interactions are genuinely atomic — accepting typed input, rendering a bounded display state, emitting a well-defined event — they become naturally amenable to accessibility testing. Each Interaction has a clear input contract (what does the user provide?), a clear output contract (what event does it emit?), and a clear display state (what does the user perceive?). These contracts map directly to the concerns that accessibility standards address: labeling, focus management, keyboard operability, screen-reader announcements. Teams practicing EBD consistently report that accessibility compliance becomes easier not because they try harder, but because the structural unit they are testing is small enough to have an unambiguous accessibility contract. The improvement is architectural, not motivational.
10.6 The State Accumulation Pattern
Experiences that attempt to own the entire user session — rather than just the journey they represent — accumulate state that properly belongs elsewhere. An onboarding Experience begins tracking authentication tokens. A checkout Experience begins caching product catalog data. A settings Experience begins holding application-wide preferences. The result is an Experience that cannot be unmounted without losing unrelated application state, which defeats the composability promise of the tier. The correction is to distinguish journey state (which the Experience legitimately owns) from session state and application state (which belong in infrastructure layers outside the EBD hierarchy). An Experience should be mountable and unmountable without side effects beyond its own journey.
10.7 Configuration-Driven Composition as a White-Labeling Gateway
When Experience composition is driven by configuration rather than code, the distance between "different organizations see different flows" and "different organizations see a differently branded product" shrinks to a configuration delta. The same mechanism that selects which Flows appear in an Experience can select which theme, locale, and branding assets accompany them. Teams that adopt configuration-driven composition for functional reasons — different user segments need different journeys — discover that they have inadvertently built the infrastructure for white-label deployment. The product becomes a composition engine; the configuration becomes the product definition. This is not a design goal of EBD per se, but it is a structural consequence that recurs frequently enough to warrant explicit acknowledgment.
10.8 The Refactoring Gradient
Teams rarely adopt EBD wholesale. More commonly, they begin by identifying one high-volatility journey in an existing codebase and restructuring it into the Experience-Flow-Interaction hierarchy while leaving the rest of the application untouched. This produces a hybrid codebase where some journeys are EBD-structured and others retain their original organization. The observation is that the hybrid state is stable and productive. The EBD-structured journeys become demonstrably easier to modify, and the contrast motivates incremental adoption. Attempting a full-codebase conversion in a single pass, by contrast, produces a long period of structural instability with no intermediate payoff. The refactoring gradient — one journey at a time, starting with the most volatile — consistently outperforms the big-bang approach.
11. Appendix: Case Study — Developer Onboarding Platform
This appendix presents a realistic application of EBD to a developer onboarding platform — a system that configures new developers' environments when they join an organization. The platform installs tools, provisions credentials, clones repositories, and establishes workspace structures. Different organizations require different onboarding sequences, and the platform must accommodate this variation without per-client code changes.
11.1 System Context
The platform serves multiple organizations. Each organization defines its onboarding requirements through a configuration package specifying which tools to install, which credentials to provision, which repositories to clone, and which workspace structures to create. Some organizations require all developers to complete every step; others make certain steps optional. Regulated industries may require additional compliance steps that do not appear in the standard sequence.
The interface must present the correct sequence of steps for each organization, collect the necessary input from the developer, execute the configuration, and report results — all without hardcoding any organization-specific logic into the interface layer.
11.2 Experience Decomposition
The top-level architectural unit is the SetupExperience — the complete onboarding journey from initial landing to a fully configured development environment. This Experience owns the journey lifecycle: it knows when onboarding begins, what the completion criteria are, and what happens when the journey is abandoned or resumed.
The SetupExperience composes four Flows, each owning a discrete goal:
| Flow | Goal | Completion Criteria |
|---|---|---|
| EnvironmentSelectionFlow | Identify the developer's target environment and organizational tier | Environment profile selected and confirmed |
| ToolConfigurationFlow | Select and configure the tools to be installed | Tool manifest finalized and validated |
| CredentialSetupFlow | Provision or collect authentication credentials (SSH keys, tokens, certificates) | All required credentials present and verified |
| WorkspaceSetupFlow | Clone repositories and establish the directory structure | All repositories cloned and workspace structure created |
Each Flow is composed of Interactions:
| Flow | Interactions |
|---|---|
| EnvironmentSelectionFlow | OrgPickerInteraction, TierSelectorInteraction, EnvironmentSummaryInteraction |
| ToolConfigurationFlow | ToolToggleInteraction, VersionSelectorInteraction, ConflictWarningInteraction |
| CredentialSetupFlow | SSHKeyInputInteraction, TokenEntryInteraction, KeyValidationInteraction |
| WorkspaceSetupFlow | RepoListInteraction, DirectoryPreviewInteraction, ProgressIndicatorInteraction |
11.3 Core Journey
The following diagram illustrates the standard onboarding journey. The SetupExperience orchestrates the Flow sequence; each Flow manages its own Interactions internally.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%
graph TD
subgraph SetupExperience["SetupExperience (Journey Lifecycle)"]
START([Developer Arrives]) --> ENV
subgraph ENV["EnvironmentSelectionFlow"]
E1[OrgPickerInteraction] --> E2[TierSelectorInteraction]
E2 --> E3[EnvironmentSummaryInteraction]
end
ENV -->|environment.selected| TOOLS
subgraph TOOLS["ToolConfigurationFlow"]
T1[ToolToggleInteraction] --> T2[VersionSelectorInteraction]
T2 --> T3[ConflictWarningInteraction]
end
TOOLS -->|tools.configured| CREDS
subgraph CREDS["CredentialSetupFlow"]
C1[SSHKeyInputInteraction] --> C2[TokenEntryInteraction]
C2 --> C3[KeyValidationInteraction]
end
CREDS -->|credentials.verified| WORKSPACE
subgraph WORKSPACE["WorkspaceSetupFlow"]
W1[RepoListInteraction] --> W2[DirectoryPreviewInteraction]
W2 --> W3[ProgressIndicatorInteraction]
end
WORKSPACE -->|workspace.created| DONE([Environment Ready])
end
11.4 Configuration-Driven Composition
The SetupExperience does not hardcode the Flow sequence. Instead, it reads the organization's configuration to determine which Flows to include, in what order, and with what parameters. A simplified configuration structure:
onboarding:
organization: "Acme Engineering"
flows:
- id: environment_selection
required: true
order: 1
- id: tool_configuration
required: true
order: 2
- id: credential_setup
required: true
order: 3
- id: workspace_setup
required: true
order: 4
The SetupExperience reads this configuration at mount time, instantiates the corresponding Flows, and orchestrates their sequencing through the standard event-based protocol. It does not know what happens inside any Flow. It only knows that each Flow will eventually emit a completion event or an abandonment event, and it responds accordingly.
11.5 Adding a Compliance Flow
A regulated-industry client requires developers to acknowledge security policies, verify their identity through a corporate identity provider, and complete a data-handling certification before any tools are installed. In a screen-organized codebase, this would require modifying navigation logic, inserting conditional steps into existing wizards, and threading new state through the entire onboarding sequence.
In the EBD-structured system, the change is:
- Create a new Flow:
ComplianceFlow, composed ofPolicyAcknowledgmentInteraction,IdentityVerificationInteraction, andCertificationInteraction. - Update the configuration for regulated-industry organizations:
onboarding:
organization: "Regulated Corp"
flows:
- id: environment_selection
required: true
order: 1
- id: compliance
required: true
order: 2
- id: tool_configuration
required: true
order: 3
- id: credential_setup
required: true
order: 4
- id: workspace_setup
required: true
order: 5
No existing Flow is modified. The EnvironmentSelectionFlow, ToolConfigurationFlow, CredentialSetupFlow, and WorkspaceSetupFlow are identical to their non-regulated counterparts. The SetupExperience renders the ComplianceFlow between environment selection and tool configuration because the configuration says to — not because any code was changed.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%
graph TD
subgraph SetupExperience["SetupExperience (Regulated Industry)"]
START([Developer Arrives]) --> ENV
subgraph ENV["EnvironmentSelectionFlow"]
E1[OrgPickerInteraction] --> E2[TierSelectorInteraction]
E2 --> E3[EnvironmentSummaryInteraction]
end
ENV -->|environment.selected| COMPLY
subgraph COMPLY["ComplianceFlow (NEW)"]
CP1[PolicyAcknowledgmentInteraction] --> CP2[IdentityVerificationInteraction]
CP2 --> CP3[CertificationInteraction]
end
COMPLY -->|compliance.verified| TOOLS
subgraph TOOLS["ToolConfigurationFlow"]
T1[ToolToggleInteraction] --> T2[VersionSelectorInteraction]
T2 --> T3[ConflictWarningInteraction]
end
TOOLS -->|tools.configured| CREDS
subgraph CREDS["CredentialSetupFlow"]
C1[SSHKeyInputInteraction] --> C2[TokenEntryInteraction]
C2 --> C3[KeyValidationInteraction]
end
CREDS -->|credentials.verified| WORKSPACE
subgraph WORKSPACE["WorkspaceSetupFlow"]
W1[RepoListInteraction] --> W2[DirectoryPreviewInteraction]
W2 --> W3[ProgressIndicatorInteraction]
end
WORKSPACE -->|workspace.created| DONE([Environment Ready])
end
11.6 Structural Observations
This case study illustrates several properties of EBD in practice:
- Additive change model: New organizational requirements produce new Flows and configuration entries, not modifications to existing Flows. The blast radius of a new requirement is bounded by design.
- Flow independence: Each Flow is testable in isolation. The ToolConfigurationFlow can be mounted outside the SetupExperience, provided with mock input, and validated against its completion contract without any other Flow present.
- Interaction reuse: The ProgressIndicatorInteraction appears in the WorkspaceSetupFlow but could appear in any Flow that needs to report long-running progress. Its contract — accept a progress payload, render a visual state, emit a cancellation event if requested — is independent of the Flow that hosts it.
- Configuration as product definition: The difference between two organizations' onboarding experiences is fully expressed in their configuration packages. The codebase is shared infrastructure. The configuration is the product.
- Compliance as composition: Regulatory requirements, which in many systems trigger invasive cross-cutting modifications, become compositional in EBD. A compliance step is a Flow. Including it is a configuration decision. Excluding it is a configuration decision. The code does not know whether it is operating in a regulated context or not — only the configuration does.
12. Conclusion
The structural failures most visible in interface codebases — navigation logic in leaf components, flow state in global stores, cascading changes from localized decisions — share a common origin. The codebase is organized around what the system presents rather than what the user intends to accomplish. When the organizing unit and the unit of human purpose are misaligned, every structural decision is made in the wrong frame of reference.
Experience-Based Decomposition closes that gap. By establishing experiences, flows, and interactions as distinct structural roles with clear responsibilities and explicit communication rules, it makes user intent legible in the code itself. The developer reading the codebase can trace a user journey from its initiation to its conclusion without reconstructing it from navigation conditionals distributed across dozens of components.
In practice, interfaces organized this way do not eliminate change. Configurations change. Organizational requirements change. Products evolve. What changes is the experience of making those changes: a new field type affects one interaction component. A new conditional flow affects one experience and the configuration schema. A new audience segment produces a different experience composition without touching existing code.
When the communication model is event-based and the composition model is configuration-driven, something further becomes true: the interface layer itself becomes a deployment artifact, not just a code artifact. Experiences can be composed, ordered, and conditioned through configuration managed outside the release cycle. The distance between an organizational decision and its expression in the user's experience shrinks to the propagation delay of a configuration update.
That is the intended destination — not merely an interface that is easier to change, but one where the relevant changes no longer require code.
Appendix A: Glossary
Environmental Boundary (Experience) — The Experience tier is the exclusive communicator with the backend API. Environmental volatility — API contract changes, backend migrations, authentication changes — is absorbed at this boundary so that Flow and Interaction logic remains unaffected.
Communication Rules — The directional constraints governing how EBD tiers interact: Experiences invoke Flows, Flows invoke Interactions, and no component may call a peer at its own tier. These rules preserve encapsulation and make change impact predictable.
Configuration-Driven Composition — The practice of defining which flows an experience contains, and in what order, through external configuration rather than hardcoded structure. Enables organizational decisions to reshape user journeys without code changes.
Core User Journey — A high-level human purpose defining the primary value of the interface. Used as an architectural validation mechanism to ensure decomposition boundaries align with real user intent.
Cross-Cutting Volatility — Change that affects capabilities spanning all tiers, such as logging, authentication, theming, or analytics. Isolated into Utilities so that a single cross-cutting change does not require modifications across Experiences, Flows, and Interactions.
Environmental Volatility — Change originating outside the interface layer, including API contract revisions, backend migrations, and deployment-target differences. Contained by the Experience tier, which is the exclusive communicator with the backend, so that Flow and Interaction logic remains unaffected.
Experience — A complete, composable user journey bounded by a human intent. The most stable structural tier in EBD. An Experience assembles Flows through configuration and manages journey state across them.
Experience-Based Decomposition — A volatility-based decomposition approach for user interfaces that organizes code into three structural tiers — Experience, Flow, and Interaction — aligned with the axes along which interface change actually occurs. Sibling framework to Volatility-Based Decomposition (VBD).
Flow — A goal-directed sequence of interactions accomplishing one discrete outcome within an experience. The middle tier. Owns accumulated state and skip conditions; does not make API calls (that responsibility belongs to the Experience).
Flow Composition — The mechanism by which an Experience assembles its constituent Flows, typically through external configuration that specifies flow identity, ordering, and skip conditions. Decouples journey structure from release cycles.
Functional Volatility — Change in business logic within Flows, such as new validation rules, altered calculation steps, or revised decision criteria. Contained at the Flow tier so that structural and environmental boundaries remain unaffected.
Interaction — An atomic, observable user act. The most volatile tier. Owns only its display state and the event it emits upward to its parent Flow.
Interaction Event — The atomic event an Interaction emits upward to its parent Flow upon completion of a user act. Interaction Events are the sole communication mechanism from the Interaction tier to the Flow tier, preserving directional control.
Interface Volatility Axis — A dimension along which interface change is expected: functional, non-functional, cross-cutting, or environmental. EBD aligns architectural boundaries with these axes so that a change along one axis does not ripple across others.
Journey State — The accumulated data that an Experience maintains as the user progresses through its Flows. Each Flow contributes to journey state upon completion; no Flow reads or mutates another Flow's internal state directly.
Peer Prohibition — The rule that components at the same structural tier must not invoke or directly communicate with one another. Flows do not call Flows; Interactions do not call Interactions. This constraint ensures that each component can be added, removed, or reordered without side effects on its siblings.
Skip Condition — A configuration-driven rule that determines whether a particular Flow is included or bypassed within an Experience. Skip conditions allow the same Experience definition to produce different journey shapes based on organizational context, locale, or feature flags.
Non-Functional Volatility — Change driven by the reorganization of user journeys, such as reordering steps, adding or removing Flows, or splitting an Experience into variants. Contained at the Experience tier through configuration-driven composition.
Tier — One of the three structural levels in EBD — Experience, Flow, or Interaction — each corresponding to a distinct grain of user intent and a distinct volatility profile. The tier hierarchy defines both the communication direction and the scope of permissible change.
Utility — A cross-cutting interface capability consumed across all tiers without domain-specific knowledge. Utilities encapsulate concerns like theming, logging, and authentication that would otherwise duplicate across the tier hierarchy.
Appendix B: Applicability Checklist
Experience-Based Decomposition is well-suited for interfaces that:
- Serve more than one audience type with distinct mental models or organizational contexts
- Contain multi-step workflows with conditional paths or configurable step presence
- Must support multiple locales, themes, or organizational branding configurations
- Are driven by external configuration that determines which features or flows appear
- Will be maintained across multiple years and multiple product teams
- Depend on backend systems that may route differently based on the same configuration the interface uses
It may be disproportionate for:
- Single-purpose utility screens with no conditional logic
- Short-lived interfaces with a bounded, stable feature set
- Systems where the expected rate of structural change does not justify the decomposition overhead
References and Influences
William Christopher Anderson Anderson, William Christopher. Volatility-Based Decomposition in Software Architecture. February 2026.
Experience-Based Decomposition is a direct sibling framework to VBD. VBD established that architectural boundaries aligned with volatility axes produce systems resilient to change. EBD applies the same organizing principle to the interface layer, extending the Manager-Engine-Accessor-Utility taxonomy into Experience-Flow-Interaction-Utility, and establishing the same communication discipline — directional, role-constrained, event-based — at the UI level. The configuration-driven composition model described in Section 6 is explicitly designed to compose with VBD's manager-level routing: the same organizational configuration that determines which flows appear in the interface determines which backend paths execute in response to those flows completing.
Alan Cooper, Robert Reimann, David Cronin, Christopher Noessel Cooper, Alan et al. About Face: The Essentials of Interaction Design. Fourth Edition. Wiley, 2014.
Cooper's goal-directed design methodology established the foundational claim that interfaces should serve user goals, not reflect system capabilities. His use of personas and scenarios to drive interaction decisions is a direct precursor to the core user journey validation mechanism in EBD. Cooper also articulated the distinction between implementation models (how systems work) and mental models (how users think systems work), which maps directly to the argument in Section 1 that organizing code around screens misaligns it with the user's cognitive frame. EBD can be understood as the architectural expression of Cooper's design-level insight.
Brad Frost Frost, Brad. Atomic Design. Brad Frost, 2016.
Atomic Design established a hierarchical vocabulary for component composition — atoms, molecules, organisms, templates, pages — and demonstrated that interface structure benefits from explicit layering. EBD inherits this hierarchical instinct while operating at a different granularity. Where Atomic Design hierarchizes visual structure, EBD hierarchizes behavioral intent. The two frameworks are complementary: Atomic Design governs the construction of interaction components; EBD governs how those components are assembled into purposive sequences. A ProductCard (interaction, in EBD terms) might itself be composed of atoms and molecules (in Atomic Design terms). Neither taxonomy replaces the other.
Dan Saffer Saffer, Dan. Microinteractions: Designing with Details. O'Reilly Media, 2013.
Saffer's analysis of microinteractions — the small, contained moments that define product character — provides the conceptual foundation for the Interaction tier in EBD. His four-part structure (trigger, rules, feedback, loops and modes) maps closely to EBD's definition of an interaction as an atomic act with its own display state and event output. Saffer's central argument, that interactions deserve dedicated design attention rather than being treated as implementation details, reinforces the structural case for isolating them in their own tier rather than embedding them in flow or experience logic.
Jesse James Garrett Garrett, Jesse James. The Elements of User Experience. Second Edition. New Riders, 2010.
Garrett's five-plane model — strategy, scope, structure, skeleton, surface — introduced the idea that user experience design has distinct layers of abstraction, each with its own concerns and each dependent on decisions made in the layers below. EBD is an architectural expression of the same layering intuition, applied specifically to the structure and skeleton planes. Garrett's framework is primarily a design process model; EBD converts the same insight into an implementation model, giving the structural layer a home in the codebase rather than just in the design process.
Donald A. Norman Norman, Donald A. The Design of Everyday Things. Revised and Expanded Edition. Basic Books, 2013.
Norman's articulation of affordances, feedback, and the gulf of evaluation provided the cognitive psychology grounding for interaction design as a discipline. His concept of the gulf between the system image and the user's mental model is directly relevant to the argument in Section 2 that screen-organized code produces a codebase whose structure is legible to developers but not to the human intent it serves. EBD attempts to close the same gulf at the architectural level — making the code's structure reflect the user's purpose rather than the system's structure.
Kim Goodwin Goodwin, Kim. Designing for the Digital Age: How to Create Human-Centered Products and Services. Wiley, 2009.
Goodwin's comprehensive treatment of goal-directed design in practice — including scenario development, flow mapping, and design framework construction — provides the practitioner vocabulary that EBD formalizes architecturally. Her emphasis on designing for people's goals across time (not just in a single interaction) reinforces the experience tier's role as the durable container of user intent. Her scenario-based validation approach is the design-side analog to EBD's core user journey validation mechanism.
Roy Thomas Fielding Fielding, Roy Thomas. Architectural Styles and the Design of Network-Based Software Architectures. Doctoral dissertation, UC Irvine, 2000.
Fielding's REST architectural style demonstrated that well-defined constraints on communication between components — stateless requests, uniform interface, layered system — produce distributed systems that evolve gracefully. The communication rules in EBD apply the same discipline to the interface layer: constrained, directional, role-specific communication prevents the coupling that undermines architectural integrity. The event-based communication model in Section 6 draws on the same insight — decoupling the interface from the backend through a uniform event interface rather than tight procedural coupling.
Gregor Hohpe and Bobby Woolf Hohpe, Gregor; Woolf, Bobby. Enterprise Integration Patterns. Addison-Wesley, 2003.
Hohpe and Woolf's catalog of messaging patterns provides the foundational vocabulary for the event-based communication model described in Section 6. Their treatment of message channels, event-driven routing, and the decoupling of producers from consumers is directly applicable to the mechanism by which flow completion events propagate to both the experience tier above and the backend manager below. The configuration-driven routing described in that section is an application of their correlation and content-based routing patterns to the interface-backend boundary.
Juval Löwy Löwy, Juval. Righting Software. Addison-Wesley, 2019.
Löwy's IDesign methodology, the source of Volatility-Based Decomposition, provides the structural vocabulary from which EBD draws its parallel taxonomy. The Manager-Engine-Accessor-Utility role taxonomy and the associated communication rules are adapted here into Experience-Flow-Interaction-Utility. Löwy's emphasis on separating orchestration from execution — and his warning that interwoven orchestration and execution logic creates change coupling — translates directly to the EBD rule that experience logic (orchestration) must be structurally separated from flow logic (execution of a specific goal).
Author's Note
Experience-Based Decomposition builds on established practices in interaction design, frontend engineering, and software architecture — in particular Alan Cooper's goal-directed design, Brad Frost's Atomic Design, and the volatility-first thinking that underlies Volatility-Based Decomposition. Whether the specific synthesis presented here is genuinely novel, the author cannot say with certainty. What can be said is that the author has not encountered another framework that approaches interface decomposition this way, nor read work that expresses this structural model — the explicit tier hierarchy, the communication rules, the configuration-driven composition model, and the deliberate isomorphism with the backend component taxonomy. If prior art exists, the author would welcome the reference.
The intent is a reference suitable for design reviews, engineering onboarding, and architectural decision-making in organizations building products intended to serve users well over years rather than quarters.
Distribution Note
This document is provided for informational and educational purposes. It may be shared internally within organizations, used as a reference in product design and engineering discussions, or adapted for non-commercial educational use with appropriate attribution.