What OOUX is and why it matters
Object-Oriented UX (OOUX) is a design methodology that starts with the objects users care about — not the tasks they perform. Instead of beginning with "what can the user do?" (task-oriented design), OOUX begins with "what things does the user interact with?" In a project management tool, the objects are Projects, Tasks, People, and Comments. In a recipe app, they're Recipes, Ingredients, Collections, and Cooks. The actions (create, edit, share, delete) emerge naturally once the objects are clear.
Why does this matter? Most complex applications fail not because individual screens are poorly designed, but because the underlying object model is confused. When the same concept is called "Workspace" on one screen and "Project" on another, when a "Team" sometimes means a group of people and sometimes means a subscription plan, when users can't predict where to find something because the app is organized by tasks instead of things — that's an object model problem. OOUX prevents these structural issues by making the object model the foundation of the design, not an afterthought.
Objects vs. actions
Traditional task-oriented design organizes interfaces around verbs: "Create a report," "Invite a user," "Schedule a meeting." OOUX organizes around nouns: Reports, Users, Meetings. The difference seems subtle but has profound implications. Task-oriented design scatters related information across multiple screens organized by workflow. Object-oriented design gathers all information about a thing — its properties, its relationships, and its available actions — into one coherent place. Users think in terms of things, not functions. They look for "my project," not "the project creation workflow."
Objects, actions, and mental models
Users build mental models of software by identifying the "things" they can manipulate. When a user says "I need to check my orders," they're thinking about an object (Order) with properties (status, items, delivery date) and relationships (connected to a Customer, containing Products). They're not thinking about the "Order Status Inquiry Function." OOUX aligns the interface structure with this natural mental model.
An object in OOUX has four components:
- Content — what information does this object contain? (A Task has a title, description, due date, assignee, status.).
- Metadata — what system properties describe it? (Created date, last modified, creator.).
- Nested objects — what other objects live inside it? (A Task contains Comments, Attachments, Subtasks.).
- CTAs (Calls to Action) — what can you do to it? (Edit, assign, complete, delete, move.) The CTAs come last, after the object is fully understood.
The "what before how" principle
OOUX insists on defining what users interact with before designing how they interact with it. This feels backward if you're used to starting with user flows or wireframes. But defining objects first prevents the common trap of designing task flows that feel logical to the designer but don't match how users think about their domain. Map the nouns before you draw the screens.
Noun foraging: finding your objects
Noun Foraging Core Method
Use when: starting a new product design or restructuring an existing one.
Noun foraging is the process of identifying the core objects in your system. Gather all available inputs — user research transcripts, stakeholder interviews, competitor analysis, existing product screens, domain documentation — and highlight every noun. Not just any noun: focus on the nouns users care about and interact with. In an e-commerce context, you'd find: Product, Category, Cart, Order, Review, Customer, Wishlist, Seller. Filter ruthlessly: "Homepage" isn't an object (it's a container). "Search results" isn't an object (it's a list of objects). "Settings" isn't an object (it's a grab-bag of properties). You want the real-world things that users think about.
Step 1: Gather raw material
Collect user research transcripts, business requirements, domain documentation, competitor screenshots, and any existing product inventory. The richer the input, the more complete your object map.
Step 2: Highlight nouns
Go through every document and highlight every noun that represents a thing users create, view, manipulate, or care about. Cast a wide net — you'll filter later.
Step 3: Cluster and deduplicate
Group similar nouns (Order/Purchase/Transaction might be the same object). Identify synonyms the business uses inconsistently. Choose one canonical name for each object.
Step 4: Rank by importance
Which objects are central to the user's mental model? A project management tool's core objects are Projects and Tasks. People, Comments, and Files are important but secondary. Labels and Filters are supporting objects. This ranking determines your information architecture.
Object mapping
Object Map Core Method
Use when: defining the structure of each object and how objects relate to each other.
For each object identified in noun foraging, create an object map that documents:
- Core content — the essential properties users need to see (a Product's name, price, description, images).
- Metadata — system-generated properties (creation date, last modified, creator, status).
- Nested objects — other objects contained within (a Product contains Reviews, a Project contains Tasks).
- Relationships — connections to other objects at the same level (a Task is assigned to a Person, a Product belongs to a Category).
- CTAs — actions the user can take (buy, save, share, edit, delete). Use sticky notes, a spreadsheet, or a dedicated OOUX canvas. The map should be readable by the whole team — designers, developers, and product managers.
The ORCA process
ORCA: Objects, Relationships, CTAs, Attributes Framework
Use when: you want a structured, step-by-step approach to OOUX.
Sophia Prater's ORCA process formalizes OOUX into four sequential steps. O — Objects: Identify and prioritize the system's core objects through noun foraging. R — Relationships: Map how objects connect — one-to-many (a User has many Orders), many-to-many (a Student enrolls in many Courses; a Course has many Students), containment (a Folder contains Files). C — CTAs: Define what users can do with each object. CTAs are always verbs attached to specific objects: "Create Task," "Assign Task," "Complete Task." A — Attributes: Finally, define the properties of each object — what data does each object hold? ORCA forces you to delay thinking about attributes (and screens) until the object model is solid.
CTAs before attributes — why the order matters
Most teams jump to defining fields and properties first (what data does a User profile contain?). ORCA deliberately puts CTAs before Attributes because actions reveal which attributes matter. If users can't "filter Tasks by priority," then the Priority attribute is less important than you thought. If "Compare Products" is a key CTA, then the attributes shown in comparison (price, specs, ratings) are driven by the action, not by a database schema.
Container-first layout design
Container-First Design Technique
Use when: translating your object map into screen layouts.
Once your objects are defined, screens emerge naturally. Each core object gets a "detail view" — a screen dedicated to displaying that object's content, nested objects, and CTAs. Lists of objects get "collection views." The layout question becomes: how do you display this object? A Product detail page is a container for the Product object — its images, description, price, reviews (nested objects), and available actions (add to cart, save, share). The layout structure mirrors the object structure. This is container-first design: instead of placing elements on a page based on visual aesthetics, you place containers for objects based on the object model.
Object Instance vs. Collection View Technique
Use when: deciding how to present objects at different levels of detail.
Every object appears in at least two forms: as a collection item (showing summary properties in a list, grid, or table) and as a detail instance (showing full content on its own page or panel). The collection view helps users find and compare objects — it shows just enough to differentiate (a Task's title, status, and assignee in a list). The detail view helps users work with a specific object — it shows everything (the Task's full description, comments, attachments, history). Many objects also need a compact reference — an even smaller representation used when the object appears inside another object (a user avatar with name inside a comment).
OOUX for complex and enterprise applications
Object Hierarchy Design Technique
Use when: your application has deeply nested or interconnected objects.
Enterprise applications often have complex object hierarchies: an Organization contains Teams, Teams contain Members, Members have Roles, Roles have Permissions. The navigation architecture should reflect this hierarchy — users should be able to drill down through levels and always understand their current position. Use breadcrumbs to show the path (Organization > Team > Member), and allow navigation sideways (from one Team to another) without forcing users back to the top. The most common OOUX mistake in enterprise apps is making the hierarchy too deep — if users regularly need to click through 4+ levels to reach an object, the hierarchy needs flattening.
The god object trap
Avoid creating objects that try to be everything. A "Contact" that represents customers, vendors, partners, employees, and leads is a god object — it has too many properties, too many CTAs, and too many edge cases. Better to split into distinct objects with shared base properties. If your object map has an object with 30+ attributes, it's probably multiple objects wearing a trench coat.
Templates and checklists
[Canonical name — singular, e.g., "Task" not "Tasks"]
[Essential properties users care about: title, description, status, etc.]
[Objects contained within: Comments, Attachments, Subtasks, etc.]
[Connections to other objects: "assigned to Person," "belongs to Project"]
[Available actions: Create, Edit, Assign, Complete, Delete, Archive]
[Collection: list/grid/table. Detail: full page/panel. Compact: inline reference]
- Every core object has a canonical name used consistently across the product
- Object names match user language, not internal/engineering terminology
- No object has more than 20 attributes (split if so)
- Relationships between objects are explicit and documented
- Every object has a clear detail view and collection view
- CTAs are scoped to specific objects (not floating global actions)
- The object hierarchy is no deeper than 3 levels before it needs flattening
- Users can find any object within 3 navigational steps
Real-world examples
Case study
Notion: objects as the entire product model
Notion's product is built entirely around objects. Everything is a "Block" — pages, databases, text, images, embeds. Blocks contain other blocks (a Page contains Text blocks, Database blocks, etc.). Databases contain Pages with custom properties. This object model gives users extraordinary flexibility: the same system handles wikis, project boards, notes, and CRM — because they're all just objects with different properties. The navigation reflects the object hierarchy: workspaces contain pages, pages contain blocks, databases contain entries.
Why it works: The object model is simple enough to understand (everything is a block) but flexible enough to model almost any domain. Users think in terms of their objects (projects, notes, tasks), not Notion's features.
Case study
Salesforce: when object models get too complex
Salesforce demonstrates both the power and the risk of object-oriented design. The core objects are clear: Leads, Contacts, Accounts, Opportunities, Cases. Each has a detail view, collection views, and rich relationships. But decades of feature additions have created object sprawl — Campaigns, Activities, Events, Tasks, Notes, Attachments, Content, Files, Custom Objects — with overlapping concepts and inconsistent naming. "Activities" contains both Tasks and Events but is distinct from the "Tasks" object in other contexts. The lesson: OOUX requires ongoing governance. Object models that aren't maintained accumulate confusion.
Why it matters: Strong object thinking at the foundation kept Salesforce navigable despite massive complexity. But the lack of object governance over time created the usability debt the platform is now working to address.
Case study
GitHub: clear object model, clear navigation
GitHub's interface maps directly to its object model: Repositories contain Code, Issues, Pull Requests, Actions, Projects, and Wiki pages. Each object type has a consistent detail view and collection view. Issues have titles, descriptions, labels, assignees, milestones, and comments (nested objects). The tab navigation on a repository page corresponds exactly to the object types it contains. Users always know what they're looking at and where to find things because the UI structure mirrors the object structure.
Why it works: The one-to-one mapping between objects and navigation makes the interface predictable. Users build accurate mental models quickly because the interface structure matches the domain structure.
Common pitfalls
Starting with screens instead of objects
Jumping to wireframes before defining your objects leads to screens organized by task flow rather than user mental model. The "Create Project" screen might duplicate fields that belong on the "Project" detail view. Start with objects, then let the screens emerge from the object structure.
Using engineering terms as object names
"Entities," "Resources," "Instances," and "Records" are database terms, not user terms. If your users call it a "Recipe," don't call it a "Content Item." Object names should match the language users use when they talk about their work, not the language your backend uses to store data.
Confusing objects with containers
"Dashboard," "Settings," and "Home" aren't objects — they're containers that hold or display objects. A Dashboard displays Metrics, Reports, and Charts (those are the objects). Settings configure properties of other objects (User, Account, Workspace). Don't let containers masquerade as objects in your model.