Insights
OOUX designs a product around its objects; its current method is ORCA. A SaaS product needs it when its core records mean different things in different places. Object-oriented UX (OOUX) designs a product around the things its users think about, such as a candidate, a job or a deal, before designing screens and actions.
Object-oriented UX (OOUX) designs a product around the things its users think about, such as a candidate, a job or a deal, before designing screens and actions. Its originator's current method is ORCA: define the Objects, their Relationships, the Calls to action each role can take on them, and each object's Attributes. A SaaS product needs it when its core records mean different things in different places. For a linear tool that does one job from start to finish, it is overhead.
What OOUX is, and how ORCA works
Sophia V. Prater named and set out the method in A List Apart in 2015: pull the recurring nouns out of the project's goals, define what each object contains, nest objects inside one another to show how they relate, and rank each object's content, all before sketching screens. She presented it as an ingredient to add to an existing design process, not a replacement for one. Her 2016 follow-up added the actions: an inventory of the calls to action on each object, recording why each exists and who can trigger it.
Her current version is ORCA, which she walked through in a 2024 InfoQ podcast:
| Letter | The question | What the team produces |
|---|---|---|
| Objects | Which things do users think about and act on? | A list of the objects, drawn from research and the project's goals |
| Relationships | How does each object connect to every other? | A nested object matrix: the same objects on both axes, each cell a relationship |
| Calls to action | What can each role do to each object? | A call-to-action matrix of objects against roles |
| Attributes | What content and metadata describe each object? | The object map: each object with its attributes and the objects nested in it |
The work runs in rounds: discovery first, then requirements, where every object, relationship, action and attribute is examined in detail, then prioritisation, and only in the last round sketches of screens. Prater counts 15 steps across the rounds, and expects the team to iterate through them.
Does your product need it? The test
ORCA costs workshop time and asks people to argue about definitions. It earns that cost only when there is a model to get wrong. These are the signs that the model under a SaaS product has drifted:
| Sign | What it looks like | The question modelling answers |
|---|---|---|
| The product's nouns are confused | Users cannot say what a "talent pool" or a "workspace" is for; two screens use different names for one thing | What is this object, what does it contain and what is it for? |
| One record means different things to different roles | Sales sees an opportunity, operations sees a commitment, support sees an exception | Is this one object seen by several roles, or two objects sharing a name? |
| A feature keeps needing exceptions | Each release adds another special case to the same flow | Which relationship or state is missing from the model? |
| Information has no home | The team agrees a fact matters but cannot say which record holds it, so people type it again at each step | Which object owns this attribute, and what should it carry into the next workflow? |
| Navigation follows features, not things | Users hunt for one record across several modules | Where does each object live, and how do you reach its related objects from it? |
| Work leaves the product | Timesheets, shift records or decisions are kept on paper or in spreadsheets | What does the off-product record hold that the product's objects do not? |
The rule: one sign on its own may be a naming or layout problem. Two or more around the same records mean the model underneath is unclear, and redesigning screens at that point moves the confusion rather than removing it.
At Tcules, we found several of these signs at once when we mapped the objects of Scissors, temporary staffing software (Scissors case study). Research found users confused about what talent pools were for, and the pools underused. The shortlisting process was rigid. Recruiters kept timesheets and other records on paper, and candidates' shifts were recorded on paper first at the job location. Mapping the objects and the relationships between them, with the research marked on the diagram, led to four decisions: shortlisting rules that let recruiters put forward candidates with unconventional qualifications, talent pools redefined around filtering and categorisation, a reworked job-creation flow, and automated onboarding steps. The case page reports those decisions, not outcome metrics.
When it is overhead
Skip the workshops when:
- The tool is linear and single-task. One person, one job, start to finish: a calculator, a sign-up, a one-off submission.
- There are few objects and nobody disagrees about them. If the product has two or three nouns and every role uses them the same way, a sitemap and a flow are enough.
- The problem is a label, not a definition. If the object is right and only its name is wrong, rename it.
- The structure is settled and the open work is visual or interaction detail. Modelling will not tell you how a date picker should behave.
Occasional users are a special case, not an exception. Microsoft's 2001 inductive user interface guidelines argued for screens that each focus on one task, named in the user's words, rather than screens whose purpose users must deduce from a conceptual model; its own test with 88 novice users found no measurable difference either way. That is an argument about the surface, not against a model underneath. Scissors had both: users not very familiar with technology, and an object model under screens designed to make core functions easier to operate and understand.
The idea is older than the name. Object-first interfaces go back to the Xerox Star of 1981, where users selected an object and then a command, and modelling the business domain before the code is the core of Eric Evans' Domain-Driven Design (2003). What OOUX added is a sticky-note method that designers and their teams can run themselves.
Weigh the evidence for what it is. We found no controlled study of what object modelling does for a SaaS product. The nearest, a 1995 experiment with 64 people new to computers, tested object-first against command-first interaction and rejected the general object-first hypothesis (Kunkel, Bannert and Fach). The case for OOUX rests on design reasoning and practitioners' records, ours included.
The map is also a research instrument
The object map is easy to treat as a design artefact. In both our cases it also showed where the team's knowledge had gaps.
On Doodle, enterprise meeting scheduling, we treated scheduling as an information architecture problem and modelled what we found into an object diagram while research was still running. That revealed information we had been missing and pointed us to where to look. In an interview with someone who schedules meetings across teams, we came across one of the most important parameters in deciding whether a person is available. It went into the diagram, and we recalibrated our Schedule Confidence calculator. The harder work followed: an information architecture in which users enter tentative weekly schedules and organisations assign priorities to the meeting types they use, with results shown as "bookability" scores (Doodle case study). On Scissors, where the ideal users could not be recruited for research, the object diagram was where business, competitor and user evidence met.
What follows for a product team:
- Start the map while research is still running, not after it.
- Treat an empty attribute, or a relationship nobody can describe, as a research question. It tells you whom to ask and what to ask them.
- Expect the map to change when users talk. A model no interview has changed has not yet been tested against the work.
One model, several views
Modelling does not have to force one definition on everyone. Domain-Driven Design's bounded context is an explicit boundary within which a particular model, and so the meaning of its terms, applies, while other parts of a system work with other models. In a product that becomes a choice made on purpose: a candidate in a shortlist is the same person as the candidate in a talent pool, and a shortlist links a job to people without changing who they are elsewhere.
Object-first products make these choices visible. HubSpot describes its CRM as objects, records, properties and associations that work in both directions (HubSpot knowledge base). Salesforce separates a lookup relationship, where related objects can stand alone, from a master-detail relationship, where deleting the master record deletes its details (Salesforce Trailhead). "If this is deleted, what goes with it?" is a product decision, not only a database one.
Before redesigning screens, settle for each object:
- which object is the source of truth;
- which role may create, change or remove it, and in which states;
- which rules move it from one state to the next;
- which exceptions matter, and how a person recovers from them;
- what history must stay visible, and to whom.
That is the modelling our Information Architecture and Workflow Design work does before navigation hardens, and we test the proposed model against domain rules and implementation constraints before treating it as final. For the workflow side, see our article on enterprise UX design principles for complex workflow software.