Object-Oriented Experience Design (OOXD)
Users experience things that behave. So we design objects.
Alright. Let’s design an experience design approach that steals shamelessly from object-oriented thinking—not as a metaphor, but as an operating system for design.
I’ll call it Object-Oriented Experience Design (OOXD). Not because acronyms make things true, but because this one earns its keep. I developed this approach to go beyond existing object-oriented user experience approaches that focus on object structure—embedding behaviour, states, and messages—so experiences are not just understandable, but resilient, predictable, and legible under uncertainty. My ultimate goal is achieving an approach that shines where
Requirements change mid-flight.
Data is incomplete or contradictory.
Multiple actors interpret reality differently.
Accountability matters.
Automation must coexist with judgement.
Which is to say: the interesting problems.
Here we go!
Object-Oriented Experience Design (OOXD) is an approach to experience design that treats experiences not as linear journeys or collections of screens, but as systems of meaningful objects with purpose, behaviour, and responsibility. Borrowing directly from object-oriented thinking, OOXD asks designers to define what things are, what they can do, what state they are in, and how they respond—from the user’s point of view. By focusing on objects rather than flows, it produces designs that are more resilient to change, more honest under uncertainty, and more legible to both humans and machines. In short: instead of designing how users move, OOXD designs what users interact with—and lets the experience emerge from how those objects behave.
Object-Oriented Experience Design (OOXD)
Users experience things that behave. So we design objects with responsibilities, states, and relationships. Just like good software.
1. The core unit: the Experience Object
An Experience Object is anything a user can point at—mentally or literally—and say:
“That thing does something for me.”
Examples: an invoice, booking, notification, filter, profile, consent decision, trade, task, civil-service export case.
Each object has a contract.
Experience Object Contract
Every object must define:
Purpose
Why does this object exist from the user’s point of view? The outcome the object helps the user achieve. The single reason the object exists.
Capabilities (interface)
What can the user do with it?
Actions the user can take.
Parameters (inputs): data required per action.
Results (outputs): data returned or state changes.
State
What conditions can it be in?
Primary lifecycle states. Mutually exclusive, e.g., draft → submitted → under review → approved → archived.
Derived flags that modify behaviour but not lifecycle states. Non-exclusive, e.g., locked, has errors, is late.
Outcome states e.g., cancelled, validation failed.
Rules
What behaviour happens when actions are taken?
What’s allowed?
What’s prevented?
What changes automatically?
What must be true before and after and action?
Who can invoke which actions?
Events (feedback)
How does the object speak back?
Visual,
Textual,
Temporal (loading, delay, persistence).
If you can’t answer these cleanly, the design is lying to you.
2. Encapsulation: hide complexity, not truth
OO principle: encapsulation
Design translation: hide implementation, expose intent, limits and consequences.
In OOXD, Encapsulation means that an experience object shields users from system internals—technical processes, organisational boundaries, data plumbing—while remaining truthful about what the object can do, what it cannot do, and why. The user interacts with a clear, finite interface defined by meaningful actions and states, not by how the system happens to be built. Crucially, encapsulation does not mean obscuring uncertainty, constraints, or impact: those are part of the object’s public contract. A well-encapsulated experience feels simple without being simplistic,
Bad design exposes:
System internals,
Organisational silos,
Database structure,
“Because compliance said so”.
OOXD rule: an object may be complex internally, but its interface must feel honest and finite.
Example:
A tax submission object doesn’t show “Form A, Form B, Sub-workflow C”
It shows: Prepare → Review → Submit → Track
Same truth, less screaming.
3. Inheritance: design once, behave consistently
OO principle: inheritance
Design translation: patterns should inherit behaviour, not just styling.
In OOXD, inheritance means that when a new experience object is introduced, it must extend an existing base object and automatically carry forward its states, actions, and behavioural expectations—unless there is a deliberate, explicit reason not to. Visual consistency is a side effect; behavioural consistency is the contract. If an object looks like a case, a task, or a transaction, it must act like one: same lifecycle logic, same affordances, same failure modes, same tone of feedback. Deviations are allowed, but they must be intentional, named, and understandable to the user. This rule prevents “familiar but treacherous” interfaces and ensures that learning transfers across the system, building trust through predictable behaviour rather than repeated instruction.
OOXD rule: experience objects must inherit behaviour, not just appearance.
Create Base Experience Objects e.g.,:
Case
Document
Task
Transaction
Message
Each defines:
Standard states
Expected actions
Feedback patterns
Then extend e.g.,:
Export Case inherits from Case
Merge and Accusation Deal inherits from Transaction
AI Agent inherits from Task (with opinions)
Users feel this immediately:
“Oh. This works like the other ones.”
That feeling is trust, not familiarity.
4. Polymorphism: same action, different meaning
OO principle: polymorphism
Design translation: the same action behaves differently depending on the object.
In OOXD, Polymorphism means that a shared action—such as submit, approve, delete, or run—is implemented across different experience objects, but its outcome is determined by each object’s purpose, rules, and state. The label stays familiar, reducing cognitive load, while the behaviour changes appropriately: submitting a draft validates and locks it, submitting a trade executes risk checks, submitting an AI assessment records confidence and provenance. Users don’t need to relearn verbs; they learn to trust that objects will interpret those verbs correctly. This rule prevents both over-specific actions (“Submit trade for provisional execution v2”) and dangerous ambiguity, ensuring that identical interactions feel predictable in intent but precise in consequence.
For instance, “Submit” doesn’t mean one thing.
Submit a form → validation + lock
Submit a trade → execution + risk checks
Submit feedback → acknowledgement + disappear politely
OOXD rule: The label may be the same. The consequence must match the object’s nature. If users hesitate before clicking, you’ve violated polymorphism.
5. Composition over flows
OO principle: composition over inheritance.
Design translation: Experience should emerge from how well-defined objects interact, rather than forcing users through rigid, pre-authored journeys.
In OOXD, instead of designing a single, fragile flow that assumes perfect order and complete information, designers define small, self-contained experience objects—each with clear responsibilities and states—and allow them to be assembled dynamically based on context. A “journey” becomes the temporary outcome of object collaboration: a case creates a task, a task produces a document, a document triggers a decision. When conditions change, objects can be recomposed without redesigning the whole experience. This makes systems more resilient, more adaptable to real-world behaviour, and far more tolerant of uncertainty, interruption, and human improvisation.
Classic experience design mistake:
Draw a flow
Force users through it
Panic when reality disagrees
OOXD says: experiences are composed of objects collaborating, not users marching.
A “journey” is just:
Object A creates Object B
Object B references Object C
Object C blocks Object D until state changes
Flows emerge. They’re not enforced. This is why good products feel forgiving.
6. State machines are the real wireframes
OO Principle: state and state transitions.
Design translation: Design experience objects around explicit states and valid transitions, not screens or steps.
In OOXD, the real structure of an experience is the state machine of each object: the set of states it can occupy and the rules governing how it moves between them. Screens become temporary projections of state, not the architecture itself. By defining states first—draft, pending review, approved, failed, archived—and explicitly modelling what actions are possible in each, designers make behaviour predictable, errors explainable, and edge cases intentional rather than accidental. This approach replaces brittle page-to-page flows with resilient state-driven experiences, where progress, blockage, and reversal are all legible consequences of an object’s current condition, not surprises introduced by navigation.
Screens are snapshots. Objects have lifetimes. OOXD replaces page-to-page flows with state diagrams per object
Design questions shift from: “What’s the next screen?” to “What state is this object in, and what’s now possible?”
This is where:
Empty states stop being awkward.
Errors stop being surprising.
Edge cases stop being “edge”.
Because they’re just states you bothered to name.
7. Messages, not microcopy
OO Principle: message passing.
Design translation: Treat user feedback as messages emitted by objects, not decorative microcopy attached to screens.
In OOXD, messages, not microcopy means that experience objects actively communicate their state, decisions, and consequences through explicit messages—much like objects in software send and receive messages to coordinate behaviour. Feedback such as confirmations, warnings, delays, or refusals are not ad-hoc bits of copy but the visible output of object methods responding to user actions. Because messages are tied to object behaviour and state, they are timely, contextual, and consistent across the system. This shifts content writing from persuasion or apology toward clarity and predictability: users learn to read the system the way they read a conversation, not a set of instructions taped onto an interface.
Objects don’t just sit there.
They emit messages.
“Saved”
“Waiting on approval”
“Can’t proceed because X”
“This will affect Y”
OOXD rule: Feedback is an object method, not decoration.
Microcopy becomes:
Predictable
Contextual
Boring in the best possible way
Boring is underrated. Boring scales.
8. Object responsibility principle (experience design edition)
OO Principle: single responsibility principle (SRP)
Design translation: An experience object should have one clear purpose and one primary reason to change or confuse the user.
In OOXD, the Object Responsibility Principle means each experience object is accountable for a single, coherent user concern—such as capturing data, making a decision, issuing an assessment, or recording accountability. When an object tries to educate, decide, negotiate, validate, and explain policy all at once, it becomes cognitively overloaded and behaviourally unpredictable. By splitting responsibilities across multiple collaborating objects, complexity is distributed rather than hidden, and users can understand what is happening without having to infer why everything is happening at once. This principle prevents “committee interfaces” and ensures that when something changes—rules, policy, logic—the impact is local, legible, and manageable rather than system-wide chaos.
Borrowed directly from SRP: an experience object should have one reason to confuse the user.
If an object:
Explains policy,
Collects data,
Makes decisions and,
Negotiates exceptions,
…you’ve built a committee, not an interface.
Split the object.
9. Why this works (especially for me)
This approach:
Scales across teams
Aligns design and engineering
Makes AI agents legible (they become objects with intent and constraints)
Reduces patronising experience design by replacing “guidance” with capability
It also gently forces designers to think like architects, and engineers to think like human beings. A rare diplomatic victory.
10. The litmus test
Ask this of any design:
“What object is the user interacting with right now?”
If the answer is:
“This screen”
“This step”
“This flow”
You’re not done.
If the answer is:
“A case”
“A decision”
“A transaction”
“A commitment”
You’re designing reality, not user interface only.
Resources and references used (and implicitly relied on)
The comparison and framing of existing Object-Oriented User Experience (OOUX) in this article is grounded in the established, body of work below and resources they listed.
Experience design: next iteration of UX. https://www.nngroup.com/articles/experience-design/
Canonical origin of OOUX as a UX methodology introduced object discovery, object mapping, and ORCA
https://www.ooux.com
https://www.ooux.com/what-is-ooux
https://www.ooux.com/resources
ORCA Framework (Objects, Relationships, Contexts, Actions). Core teaching structure used in OOUX practice
https://www.ooux.com/orca-framework
LogRocket Blog — Object-Oriented UX
Practical overview aimed at product teams
https://blog.logrocket.com/ux-design/object-oriented-ux-ooux/
UX/Product Design Reference
Process-level explanation of OOUX in modern UX
https://ux.productdesignreference.com/leadership/process/object-oriented-ux
Entropik — Object-Oriented UX Guide
High-level industry summary of OOUX concepts
https://www.entropik.io/blogs/object-oriented-ux-the-ultimate-guide-to-designing-intuitive-user-experiences