Interactions<\/strong> are atomic. A selection, an input, a confirmation. They cannot be meaningfully subdivided from the user’s perspective.<\/li>\n<\/ul>\nShared utility components handle cross-cutting concerns \u2014 locale, theme, validation, alerts \u2014 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.<\/p>\n
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 \u2014 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.<\/p>\n
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.<\/p>\n
\nAbstract<\/h2>\n
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.<\/p>\n
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 \u2014 Experiences, Flows, and Interactions \u2014 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 \u2014 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.<\/p>\n
\n1. Introduction<\/h2>\n
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 \u2014 how to structure the interface layer so that it absorbs change gracefully \u2014 remains largely unsolved in most codebases.<\/p>\n
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.<\/p>\n
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.<\/p>\n
A user opening a developer onboarding tool is not navigating to a screen. They are pursuing a goal \u2014 getting their environment configured correctly \u2014 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.<\/p>\n
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 \u2014 applied here to the surface that users actually touch.<\/p>\n
\n2. Background<\/h2>\n2.1 Screen-Centric Organization and Its Consequences<\/h3>\n
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.<\/p>\n
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 \u2014 what counts as a valid selection, when a step can be skipped \u2014 migrates into presentation components because there is no structural location for it that is clearly correct.<\/p>\n
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.<\/p>\n
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.<\/em><\/p>\nFigure 1a \u2014 Screen-Centric Organization<\/strong><\/p>\n%%{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'}}}%%\n\nflowchart LR\n S1["Screen A"]\n S2["Screen B"]\n S3["Screen C"]\n S1 <-->|"navigation + state"| S2\n S2 <-->|"navigation + state"| S3\n S1 -.->|"validation duplicated"| S3\n\n<\/code><\/pre>\nFigure 1b \u2014 Intent-Centric Organization (EBD)<\/strong><\/p>\n%%{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'}}}%%\n\nflowchart TD\n EX["OnboardingExperience"]\n FL["UserInfoFlow"]\n IN["FormField \/ DropdownSelect"]\n UT["Locale \/ Theme"]\n\n EX -->|"composes, passes state"| FL\n FL -->|"renders"| IN\n IN -.->|"emits event"| FL\n FL -.->|"emits completion"| EX\n FL --> UT\n IN --> UT\n\n<\/code><\/pre>\n2.2 Component-Based Thinking and Its Limits<\/h3>\n
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.<\/p>\n
A component library answers the question: how do we build consistent interface elements?<\/em> It does not answer the question: where does navigation logic live? Who owns multi-step state? What happens when a step should be skipped?<\/em> Those questions require a structural model, not a component model.<\/p>\nBrad Frost’s Atomic Design methodology made an important contribution to this problem by establishing a vocabulary for hierarchical component composition \u2014 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<\/em> 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.<\/p>\n2.3 Goal-Directed Design as a Precursor<\/h3>\n
Alan Cooper’s goal-directed design methodology, articulated in About Face<\/em>, 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 \u2014 that the question is not what the system can do but what the user is trying to accomplish.<\/p>\nEBD 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.<\/p>\n
\n3. The Four Axes of Interface Volatility<\/h2>\n
Before defining the structural model, it is useful to characterize where change actually occurs in interface systems \u2014 the same volatility analysis that underpins Volatility-Based Decomposition at the system level, applied here to the interface layer.<\/p>\n
3.1 Functional Volatility<\/h3>\n
Changes in what the user is asked to do \u2014 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.<\/p>\n
3.2 Non-Functional Volatility<\/h3>\n
Changes in how journeys compose \u2014 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.<\/p>\n
3.3 Cross-Cutting Volatility<\/h3>\n
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.<\/p>\n
3.4 Environmental Volatility<\/h3>\n
Changes to the external systems the interface depends on \u2014 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.<\/p>\n
Figure 2 maps each volatility axis to the structural tier responsible for containing it.<\/em><\/p>\n%%{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'}}}%%\n\ngraph TB\n subgraph axes["Four Axes of Interface Volatility"]\n FV["Functional"]\n NF["Non-Functional"]\n CV["Cross-Cutting"]\n EV["Environmental"]\n end\n\n subgraph tiers["Containing Tier"]\n INT["Interaction"]\n EXP["Experience"]\n UTL["Utility"]\n end\n\n FV -->|isolated by| INT\n NF -->|isolated by| EXP\n CV -->|isolated by| UTL\n EV -->|isolated by| EXP\n\n<\/code><\/pre>\n
\n4. The Structural Model<\/h2>\n
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.<\/p>\n
4.1 Experiences<\/h3>\n
An experience is a complete user journey bounded by a human intent \u2014 the arc from initiation to fulfillment. It is the answer to the question: what did this user come here to accomplish?<\/em><\/p>\nExperiences are the most durable tier. The intent behind a developer onboarding experience \u2014 understand the organization’s configuration requirements, provide personal context, complete the setup \u2014 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.<\/p>\n
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 \u2014 a checkpoint, a completion \u2014 the experience emits that state as a single coherent event. It holds everything. It decides what comes next.<\/p>\n
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.<\/p>\n
An experience MUST NOT<\/strong> implement flow-level progression logic.
\nAn experience MUST NOT<\/strong> render interaction components directly.
\nAn experience MAY<\/strong> compose other experiences as bounded sub-journeys.
\nAn experience MAY<\/strong> receive configuration that determines which flows it contains and in what order.
\nAn experience MAY<\/strong> call the backend API, passing accumulated journey state as a completion event.<\/p>\n4.2 Flows<\/h3>\n
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.<\/p>\n
Flows sit at the most structurally important tier \u2014 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.<\/p>\n
A flow owns its progression through interactions and the state it accumulates across them. It does not communicate with the backend \u2014 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.<\/p>\n
A flow MUST NOT<\/strong> coordinate directly with sibling flows.
\nA flow MUST NOT<\/strong> make direct API calls.
\nA flow MUST NOT<\/strong> render utility components as owned children \u2014 it invokes them.
\nA flow MAY<\/strong> emit a completion event carrying accumulated state upward to the experience.
\nA flow MAY<\/strong> skip itself entirely if its entry conditions are not met, signaling the experience to advance.<\/p>\n4.3 Interactions<\/h3>\n
An interaction is the smallest observable unit of user action \u2014 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.<\/p>\n
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 \u2014 a dropdown becoming a searchable select, a checkbox becoming a toggle \u2014 change with design decisions. Because interactions are the most likely to change, they must be the most isolated.<\/p>\n
An interaction owns its visual presentation, its internal display state (focused, disabled, errored), and the event it emits when the user acts.<\/p>\n
An interaction MUST NOT<\/strong> contain flow progression logic.
\nAn interaction MUST NOT<\/strong> make direct API calls.
\nAn interaction MUST NOT<\/strong> be aware of adjacent interactions.
\nAn interaction MAY<\/strong> use utility components for locale rendering, validation display, and alert presentation.<\/p>\n4.4 Utilities<\/h3>\n
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.<\/p>\n
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.<\/p>\n
A utility MUST NOT<\/strong> contain flow progression logic.
\nA utility MUST NOT<\/strong> hold domain-specific state.
\nA utility MUST NOT<\/strong> coordinate workflows or make decisions on behalf of flows.<\/p>\nFigure 3 shows the complete structural model and the communication rules between roles.<\/em><\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'secondaryColor': '#d1fae5', 'tertiaryColor': '#ede9fe', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n EXP["Experience"]\n FLW["Flow"]\n INT["Interaction"]\n UTL["Utility"]\n CFG["Configuration"]\n\n CFG -->|"defines flow composition"| EXP\n EXP -->|"composes, passes state"| FLW\n EXP -->|"embeds as sub-journey"| EXP\n FLW -->|"composes, passes props"| INT\n INT -.->|"emits event"| FLW\n FLW -.->|"emits completion"| EXP\n INT --> UTL\n FLW --> UTL\n EXP --> UTL\n\n<\/code><\/pre>\n
\n5. Communication Rules<\/h2>\n
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.<\/p>\n
The governing rule is directional: state flows downward; results propagate upward as events.<\/strong> An experience passes configuration and shared state to flows. Flows pass props and callbacks to interactions. Interactions emit events \u2014 they do not call flows. Flows emit completion events \u2014 they do not call experiences. No tier reaches sideways. No tier reaches up.<\/p>\nBackend communication is the exclusive domain of the experience. A flow that discovers it needs to call an API has exceeded its scope \u2014 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.<\/p>\n
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.<\/p>\n
The second governing rule addresses cross-tier calls: nothing calls a utility; everything consumes it.<\/strong> 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")<\/code> and receives a string. The distinction matters because a utility that receives callbacks or coordinates timing has begun behaving like a flow.<\/p>\nFigure 4 shows the lifecycle of a single flow \u2014 how it receives context from the experience, collects state through interactions, and resolves to a completion event.<\/em><\/p>\n%%{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'}}}%%\n\nstateDiagram-v2\n [*] --> Entering : Experience calls enter(sharedState)\n\n Entering --> CheckSkip : Evaluate entry conditions\n CheckSkip --> Skipped : Conditions not met\n CheckSkip --> Active : Conditions met\n\n Skipped --> [*] : Emits skip() to Experience\n\n Active --> CollectingState : Render interactions, wait for events\n\n CollectingState --> CollectingState : Interaction emits event; flow accumulates state\n\n CollectingState --> Validating : User requests advancement\n\n Validating --> CollectingState : Validation errors \u2014 return to interactions\n\n Validating --> Complete : All valid\n\n Complete --> [*] : Emits flowComplete(accumulatedState) to Experience\n<\/code><\/pre>\n
\n6. Configuration-Driven Experience Composition<\/h2>\n
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.<\/strong><\/p>\nThis 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.<\/p>\n
In practice, this requires three things:<\/p>\n
A configuration schema that describes experience composition.<\/strong> 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.<\/p>\nAn event-based communication model between the interface and the backend.<\/strong> When a flow emits a completion event, that event carries the accumulated state from the flow \u2014 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.<\/p>\nBackend architecture capable of absorbing this routing.<\/strong> The techniques for achieving this on the backend \u2014 separating orchestration from execution, isolating integration concerns, routing workflow decisions through configurable managers \u2014 are described fully in Volatility-Based Decomposition in Software Architecture<\/em> (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.<\/p>\nFigure 5 illustrates this end-to-end configuration-driven model.<\/em><\/p>\n%%{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'}}}%%\n\nflowchart TD\n subgraph config["Organizational Configuration"]\n PC["org.config"]\n end\n\n subgraph ux["UX Layer \u2014 EBD"]\n EXP["OnboardingExperience"]\n FLOWS["Config \u00b7 UserInfo \u00b7 Segment \u00b7 Setup"]\n EXP -->|"composes"| FLOWS\n end\n\n subgraph ev["Event Boundary"]\n EV["Completion Event"]\n end\n\n subgraph backend["Backend Layer \u2014 VBD"]\n MGR["OnboardingManager"]\n ENG["PolicyEngine \u00b7 SegmentEngine"]\n ACC["WorkspaceAccessor \u00b7 IdentityAccessor \u00b7 StorageAccessor"]\n MGR -->|"invokes"| ENG\n MGR -->|"invokes"| ACC\n end\n\n PC -->|"drives flow composition"| EXP\n PC -->|"drives routing"| MGR\n FLOWS -.->|"emits on complete"| EV\n EV -->|"received by"| MGR\n\n<\/code><\/pre>\nThe 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.<\/p>\n
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.<\/p>\n
\n7. Core User Journeys as Architectural Validation<\/h2>\n
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.<\/p>\n
Core user journeys are intentionally narrow. Even complex products have a small number of genuinely core journeys \u2014 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.<\/p>\n
An interface architecture is structurally sound if each core user journey can be traced cleanly through the Experience \u2192 Flow \u2192 Interaction hierarchy without bypassing structural rules. Specifically:<\/p>\n
\n- A change within one flow must not require changes in a sibling flow.<\/li>\n
- Adding a new interaction to a flow must not require modifying the experience.<\/li>\n
- Introducing a new locale string must not require modifying any flow or experience.<\/li>\n
- A new organizational configuration variant must produce a different experience composition without code changes.<\/li>\n<\/ul>\n
If any of these conditions fails, the failure points directly to where the architectural boundary has been violated.<\/p>\n
A product serving multiple audience types might define three core user journeys \u2014 initial onboarding, profile configuration, and workspace setup \u2014 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.<\/p>\n
Figure 6 traces a multi-segment onboarding journey through the structural hierarchy.<\/em><\/p>\n%%{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'}}}%%\n\nsequenceDiagram\n actor User\n participant OE as OnboardingExperience\n participant CSF as ConfigSelectionFlow\n participant UIF as UserInfoFlow\n participant OPF as OrgProfileFlow\n participant SF as SetupFlow\n participant Util as Utilities\n\n User->>OE: Opens onboarding\n OE->>Util: t("steps.config_selection") \u00b7 applyTheme()\n OE->>CSF: enter()\n CSF->>User: Renders configuration options\n User->>CSF: Selects configuration profile\n CSF-->>OE: flowComplete({ config })\n\n OE->>UIF: enter(config)\n UIF->>User: Renders fields from org configuration\n User->>UIF: Fills required profile fields\n UIF-->>OE: flowComplete({ userInfo })\n\n Note over OE: GET \/api\/config\/segments\n alt Has optional segments\n OE->>OPF: enter(config, segments)\n OPF->>User: Renders segment selectors\n User->>OPF: Selects organizational segment\n OPF-->>OE: flowComplete({ segment })\n else No optional segments\n OE->>OE: advance \u2014 OrgProfileFlow skipped\n end\n\n OE->>SF: enter({ config, userInfo, segment })\n SF->>User: Renders setup progress UI\n SF-->>OE: flowComplete()\n Note over OE: POST \/api\/onboard { config, userInfo, segment }\n OE->>User: Renders completion and next steps\n<\/code><\/pre>\n
\n8. Architectural Watchpoints<\/h2>\nInteraction Scope Creep<\/h3>\n
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.<\/p>\n
Flow Awareness of Siblings<\/h3>\n
A flow that checks the state of a sibling flow \u2014 even through a shared store \u2014 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.<\/p>\n
Configuration Complexity Threshold<\/h3>\n
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.<\/p>\n
Utility Drift<\/h3>\n
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.<\/p>\n
Experience Depth<\/h3>\n
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.<\/p>\n
\n9. Relationship to Volatility-Based Decomposition<\/h2>\n
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.<\/p>\n
\n\n\n| VBD<\/th>\n | EBD<\/th>\n<\/tr>\n<\/thead>\n |
\n\n| Manager<\/td>\n | Experience<\/td>\n<\/tr>\n |
\n| Engine<\/td>\n | Flow<\/td>\n<\/tr>\n |
\n| Resource Accessor<\/td>\n | Interaction<\/td>\n<\/tr>\n |
\n| Utility<\/td>\n | Utility<\/td>\n<\/tr>\n |
\n| Core Use Case<\/td>\n | Core User Journey<\/td>\n<\/tr>\n |
\n| Communication rules (MUST\/MUST NOT)<\/td>\n | Communication rules (MUST\/MUST NOT)<\/td>\n<\/tr>\n |
\n| Volatility axis<\/td>\n | Interface volatility axis<\/td>\n<\/tr>\n |
\n| Configuration-driven routing<\/td>\n | Configuration-driven experience composition<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 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 \u2014 nothing more.<\/p>\n 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.<\/p>\n
\n10. Practitioner Observations<\/h2>\nThe 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 \u2014 some beneficial, some pathological \u2014 that practitioners encounter as EBD moves from a design-time concept to a living codebase.<\/p>\n 10.1 The Flow Proliferation Pattern<\/h3>\nTeams 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 \u2014 no intermediate save, no resumability, no standalone value \u2014 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\u201350% during their first refactoring pass.<\/p>\n 10.2 The Interaction Purity Challenge<\/h3>\nInteractions are defined as atomic \u2014 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 \u2014 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.<\/p>\n 10.3 The Experience Scope Question<\/h3>\nA 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 \u2014 if suspending it means abandoning the enclosing journey \u2014 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.<\/p>\n 10.4 Bridging the Designer\u2013Developer Vocabulary Gap<\/h3>\nOne of the less anticipated effects of EBD is the change it produces in cross-functional communication. Designers naturally think in journeys \u2014 the complete arc of what a user is trying to accomplish. Developers naturally think in components \u2014 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?”<\/p>\n 10.5 Accessibility as a Structural Consequence<\/h3>\nWhen Interactions are genuinely atomic \u2014 accepting typed input, rendering a bounded display state, emitting a well-defined event \u2014 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.<\/p>\n 10.6 The State Accumulation Pattern<\/h3>\nExperiences that attempt to own the entire user session \u2014 rather than just the journey they represent \u2014 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.<\/p>\n 10.7 Configuration-Driven Composition as a White-Labeling Gateway<\/h3>\nWhen 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 \u2014 different user segments need different journeys \u2014 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.<\/p>\n 10.8 The Refactoring Gradient<\/h3>\nTeams 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 \u2014 one journey at a time, starting with the most volatile \u2014 consistently outperforms the big-bang approach.<\/p>\n
\nThis appendix presents a realistic application of EBD to a developer onboarding platform \u2014 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.<\/p>\n 11.1 System Context<\/h3>\nThe 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.<\/p>\n 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 \u2014 all without hardcoding any organization-specific logic into the interface layer.<\/p>\n 11.2 Experience Decomposition<\/h3>\nThe top-level architectural unit is the SetupExperience<\/strong> \u2014 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.<\/p>\nThe SetupExperience composes four Flows, each owning a discrete goal:<\/p>\n \n\n\n| Flow<\/th>\n | Goal<\/th>\n | Completion Criteria<\/th>\n<\/tr>\n<\/thead>\n | \n\nEnvironmentSelectionFlow<\/strong><\/td>\n| Identify the developer’s target environment and organizational tier<\/td>\n | Environment profile selected and confirmed<\/td>\n<\/tr>\n | \nToolConfigurationFlow<\/strong><\/td>\n| Select and configure the tools to be installed<\/td>\n | Tool manifest finalized and validated<\/td>\n<\/tr>\n | \nCredentialSetupFlow<\/strong><\/td>\n| Provision or collect authentication credentials (SSH keys, tokens, certificates)<\/td>\n | All required credentials present and verified<\/td>\n<\/tr>\n | \nWorkspaceSetupFlow<\/strong><\/td>\n| Clone repositories and establish the directory structure<\/td>\n | All repositories cloned and workspace structure created<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Each Flow is composed of Interactions:<\/p>\n \n\n\n| Flow<\/th>\n | Interactions<\/th>\n<\/tr>\n<\/thead>\n | \n\n| EnvironmentSelectionFlow<\/td>\n | OrgPickerInteraction, TierSelectorInteraction, EnvironmentSummaryInteraction<\/td>\n<\/tr>\n | \n| ToolConfigurationFlow<\/td>\n | ToolToggleInteraction, VersionSelectorInteraction, ConflictWarningInteraction<\/td>\n<\/tr>\n | \n| CredentialSetupFlow<\/td>\n | SSHKeyInputInteraction, TokenEntryInteraction, KeyValidationInteraction<\/td>\n<\/tr>\n | \n| WorkspaceSetupFlow<\/td>\n | RepoListInteraction, DirectoryPreviewInteraction, ProgressIndicatorInteraction<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n11.3 Core Journey<\/h3>\nThe following diagram illustrates the standard onboarding journey. The SetupExperience orchestrates the Flow sequence; each Flow manages its own Interactions internally.<\/p>\n %%{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'}}}%%\ngraph TD\n subgraph SetupExperience["SetupExperience (Journey Lifecycle)"]\n START([Developer Arrives]) --> ENV\n\n subgraph ENV["EnvironmentSelectionFlow"]\n E1[OrgPickerInteraction] --> E2[TierSelectorInteraction]\n E2 --> E3[EnvironmentSummaryInteraction]\n end\n\n ENV -->|environment.selected| TOOLS\n\n subgraph TOOLS["ToolConfigurationFlow"]\n T1[ToolToggleInteraction] --> T2[VersionSelectorInteraction]\n T2 --> T3[ConflictWarningInteraction]\n end\n\n TOOLS -->|tools.configured| CREDS\n\n subgraph CREDS["CredentialSetupFlow"]\n C1[SSHKeyInputInteraction] --> C2[TokenEntryInteraction]\n C2 --> C3[KeyValidationInteraction]\n end\n\n CREDS -->|credentials.verified| WORKSPACE\n\n subgraph WORKSPACE["WorkspaceSetupFlow"]\n W1[RepoListInteraction] --> W2[DirectoryPreviewInteraction]\n W2 --> W3[ProgressIndicatorInteraction]\n end\n\n WORKSPACE -->|workspace.created| DONE([Environment Ready])\n end\n<\/code><\/pre>\n11.4 Configuration-Driven Composition<\/h3>\nThe 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:<\/p>\n onboarding:\n organization: "Acme Engineering"\n flows:\n - id: environment_selection\n required: true\n order: 1\n - id: tool_configuration\n required: true\n order: 2\n - id: credential_setup\n required: true\n order: 3\n - id: workspace_setup\n required: true\n order: 4\n<\/code><\/pre>\nThe 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.<\/p>\n 11.5 Adding a Compliance Flow<\/h3>\nA 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.<\/p>\n In the EBD-structured system, the change is:<\/p>\n \n- Create a new Flow<\/strong>:
ComplianceFlow<\/code>, composed of PolicyAcknowledgmentInteraction<\/code>, IdentityVerificationInteraction<\/code>, and CertificationInteraction<\/code>.<\/li>\n- Update the configuration<\/strong> for regulated-industry organizations:<\/li>\n<\/ol>\n
onboarding:\n organization: "Regulated Corp"\n flows:\n - id: environment_selection\n required: true\n order: 1\n - id: compliance\n required: true\n order: 2\n - id: tool_configuration\n required: true\n order: 3\n - id: credential_setup\n required: true\n order: 4\n - id: workspace_setup\n required: true\n order: 5\n<\/code><\/pre>\nNo 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 \u2014 not because any code was changed.<\/p>\n %%{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'}}}%%\ngraph TD\n subgraph SetupExperience["SetupExperience (Regulated Industry)"]\n START([Developer Arrives]) --> ENV\n\n subgraph ENV["EnvironmentSelectionFlow"]\n E1[OrgPickerInteraction] --> E2[TierSelectorInteraction]\n E2 --> E3[EnvironmentSummaryInteraction]\n end\n\n ENV -->|environment.selected| COMPLY\n\n subgraph COMPLY["ComplianceFlow (NEW)"]\n CP1[PolicyAcknowledgmentInteraction] --> CP2[IdentityVerificationInteraction]\n CP2 --> CP3[CertificationInteraction]\n end\n\n COMPLY -->|compliance.verified| TOOLS\n\n subgraph TOOLS["ToolConfigurationFlow"]\n T1[ToolToggleInteraction] --> T2[VersionSelectorInteraction]\n T2 --> T3[ConflictWarningInteraction]\n end\n\n TOOLS -->|tools.configured| CREDS\n\n subgraph CREDS["CredentialSetupFlow"]\n C1[SSHKeyInputInteraction] --> C2[TokenEntryInteraction]\n C2 --> C3[KeyValidationInteraction]\n end\n\n CREDS -->|credentials.verified| WORKSPACE\n\n subgraph WORKSPACE["WorkspaceSetupFlow"]\n W1[RepoListInteraction] --> W2[DirectoryPreviewInteraction]\n W2 --> W3[ProgressIndicatorInteraction]\n end\n\n WORKSPACE -->|workspace.created| DONE([Environment Ready])\n end\n<\/code><\/pre>\n11.6 Structural Observations<\/h3>\nThis case study illustrates several properties of EBD in practice:<\/p>\n \n- Additive change model<\/strong>: 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.<\/li>\n
- Flow independence<\/strong>: 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.<\/li>\n
- Interaction reuse<\/strong>: The ProgressIndicatorInteraction appears in the WorkspaceSetupFlow but could appear in any Flow that needs to report long-running progress. Its contract \u2014 accept a progress payload, render a visual state, emit a cancellation event if requested \u2014 is independent of the Flow that hosts it.<\/li>\n
- Configuration as product definition<\/strong>: The difference between two organizations’ onboarding experiences is fully expressed in their configuration packages. The codebase is shared infrastructure. The configuration is the product.<\/li>\n
- Compliance as composition<\/strong>: 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 \u2014 only the configuration does.<\/li>\n<\/ul>\n
\n12. Conclusion<\/h2>\nThe structural failures most visible in interface codebases \u2014 navigation logic in leaf components, flow state in global stores, cascading changes from localized decisions \u2014 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n That is the intended destination \u2014 not merely an interface that is easier to change, but one where the relevant changes no longer require code.<\/p>\n
\nAppendix A: Glossary<\/h2>\nEnvironmental Boundary (Experience)<\/strong> \u2014 The Experience tier is the exclusive communicator with the backend API. Environmental volatility \u2014 API contract changes, backend migrations, authentication changes \u2014 is absorbed at this boundary so that Flow and Interaction logic remains unaffected.<\/p>\nCommunication Rules<\/strong> \u2014 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.<\/p>\nConfiguration-Driven Composition<\/strong> \u2014 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.<\/p>\nCore User Journey<\/strong> \u2014 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.<\/p>\nCross-Cutting Volatility<\/strong> \u2014 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.<\/p>\nEnvironmental Volatility<\/strong> \u2014 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.<\/p>\nExperience<\/strong> \u2014 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.<\/p>\nExperience-Based Decomposition<\/strong> \u2014 A volatility-based decomposition approach for user interfaces that organizes code into three structural tiers \u2014 Experience, Flow, and Interaction \u2014 aligned with the axes along which interface change actually occurs. Sibling framework to Volatility-Based Decomposition (VBD).<\/p>\nFlow<\/strong> \u2014 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).<\/p>\nFlow Composition<\/strong> \u2014 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.<\/p>\nFunctional Volatility<\/strong> \u2014 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.<\/p>\nInteraction<\/strong> \u2014 An atomic, observable user act. The most volatile tier. Owns only its display state and the event it emits upward to its parent Flow.<\/p>\nInteraction Event<\/strong> \u2014 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.<\/p>\nInterface Volatility Axis<\/strong> \u2014 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.<\/p>\nJourney State<\/strong> \u2014 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.<\/p>\nPeer Prohibition<\/strong> \u2014 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.<\/p>\nSkip Condition<\/strong> \u2014 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.<\/p>\nNon-Functional Volatility<\/strong> \u2014 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.<\/p>\nTier<\/strong> \u2014 One of the three structural levels in EBD \u2014 Experience, Flow, or Interaction \u2014 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.<\/p>\nUtility<\/strong> \u2014 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.<\/p>\n
\nAppendix B: Applicability Checklist<\/h2>\nExperience-Based Decomposition is well-suited for interfaces that:<\/p>\n
| | | | | | |