Object-Oriented UX. Structured before the first wireframe.
OOUX and the ORCA methodology aren't frameworks I learned in a course. They're the structural discipline I apply to every engagement — because every complex product failure I've seen traces back to a missing or wrong object model.
Why most products fail before design begins.
A screen is not the atomic unit of a product. An object is. When a team designs screen-first, they build a product shaped by screens — which is the wrong shape. Screens are views into objects. If the objects are wrong, every screen built on top of them will be wrong too.
Object-Oriented UX (OOUX), developed by Sophia Prater, is a methodology for designing products from their data model outward. It aligns how designers, engineers, and product managers think about the system — replacing misalignment that produces handoff failures.
The ORCA methodology (Objects, Relationships, Calls to Action, Attributes) is the practical mapping tool. A completed ORCA map is the most valuable design artefact a product team can produce — more valuable than a wireframe, because it precedes one.
ORCA in practice — CrossBorda example.
This is an excerpt from the actual ORCA map used in the CrossBorda engagement. Objects, Relationships, CTAs, and Attributes defined before a single wireframe was drawn.
| O /Objects | R /Relationships | C /Calls to Action | A /Attributes |
|---|---|---|---|
| Beneficiary | Belongs to a User · Referenced by Transaction | Add Beneficiary · Edit · Archive | Name, Bank, Account No., Verified Status, Country |
| Transaction | References Beneficiary · References Corridor | Initiate · Cancel · Retry · Download Receipt | Amount, Currency, Status, Reference ID, Timestamp |
| KYC Document | Belongs to a User · Required by Compliance Rule | Upload · Replace · View Status | Type, Status (Pending/Verified/Rejected), Expiry, Country |
| Payout Corridor | Has many Transactions · Governed by Compliance Rules | Select · Configure | Origin Country, Destination Country, Supported Methods, Active Status |
← Replace with real artifact
[Full ORCA map exported from Figma or Miro — wide format (16:6 aspect). Objects as nodes connected by relationship lines. Attributes listed beneath each node. CTAs shown as directional arrows. JetBrains Mono font. Dark background, gold accent for object names. Caption: "ORCA map — CrossBorda payment system, 2024."]
Five phases. Every engagement.
What are the real objects in this system?
Before wireframes, before user stories, before design — I map the domain. Every product has a set of core entities that the entire experience is built around. In a payment system, those entities include Beneficiary, Transaction, Corridor, and KYC Document. In an LMS, they're Student, Exam, Attempt, Question, and Score. Identifying these objects precisely — and naming them consistently — is the first act of product design. It's also the most important.
Image Placeholder
[Image: Whiteboard or Figma canvas with raw object brainstorming — a list of candidate system entities for CrossBorda or Zuniq. Some crossed out, some circled, some connected by arrows. Shows the messiness of real object discovery before it becomes clean architecture.]
Build the ORCA map. Define structure before screens.
ORCA stands for Objects, Relationships, Calls to Action, and Attributes. It's the structural backbone of every product I design. Each Object gets its Relationships mapped (what other objects does it connect to?), its CTAs defined (what actions can be performed on it?), and its Attributes listed (what data does it carry?). The result is a single map that tells you, before any screen is designed, exactly what the system contains. Engineering teams use it as a model. Design uses it as a constraint. Product uses it as a shared language.
Image Placeholder
[Image: A clean, exported ORCA map — 4-column table format: Objects | Relationships | Calls to Action | Attributes. Using CrossBorda data (Beneficiary, Transaction, KYC Document, Payout Corridor). JetBrains Mono font, dark background, gold accent column headers. Caption: 'ORCA map — CrossBorda payment system, 2024.']
Map every state for every object.
An object isn't a static thing. A Transaction has states: Initiated, Pending, Processing, Completed, Failed, Cancelled. Each state has different available CTAs, different visible attributes, and different rules for who can act on it. A Transaction in a 'Failed' state can be Retried. A Transaction in a 'Completed' state cannot. Designing without state maps means discovering edge cases in development — when they're expensive. Designing with state maps means finding them in Figma — when they're just a conversation.
Image Placeholder
[Image: State machine diagram for the Exam object in VigiLearn — Draft → Published → Active → In Progress → Submitted → Graded → Archived. Each state shown as a node, transitions as labelled arrows, available CTAs listed under each state. Shows the complexity that ORCA captures before UI design begins.]
Now we draw screens. Structure first, surface second.
Only after the object model is solid do I move to wireframes. At this point, the screens aren't invented — they're derived. The objects tell me what pages exist. The attributes tell me what information appears on each page. The CTAs tell me what actions each page needs to support. The states tell me how many design variants each view requires. This is why OOUX produces designs with fewer surprises in engineering: the engineer is already familiar with the model. The designer has already thought through every state.
Image Placeholder
[Image: Side-by-side comparison — left: the ORCA map for CrossBorda; right: the resulting UI screens. Objects on the left become pages on the right. Attributes on the left become data fields on the right. CTAs on the left become buttons and actions on the right. The map preceded the screens.]
Then I implement it.
Most designers stop at the handoff. I don't. I build in React, Next.js, WordPress, and custom CMS implementations — taking systems from ORCA map to production. This closes the handoff gap not by communicating better, but by eliminating it. Implementation reveals constraints that design misses. Knowing both sides means I catch them early.
Image Placeholder
[Image: Screenshot of actual code — a React component implementing one of the system objects (e.g., a BeneficiaryCard component or TransactionStatus component). Shows that the designer wrote this, not just specified it. 10–20 lines of clean TypeScript/React.]
Not every product needs OOUX. These do.
Fintech & Payment Systems
Cross-border payments, KYC flows, multi-currency wallets. Complex object relationships and state machines where structural errors have financial consequences.
Enterprise LMS & EdTech
Learning management systems with multi-role access (Student, Instructor, Admin), complex state machines (Exam lifecycle), and institutional compliance requirements.
Regulated Industries
Healthcare, legal, compliance-heavy SaaS. Products where every object state has a regulatory consequence and edge cases are non-negotiable.
Multi-Platform Products
Products that need to express a single object model across web, mobile, and TV — where consistency of structure prevents drift across platforms.
See OOUX in production
The CrossBorda and VigiLearn case studies show the full ORCA methodology applied to live, shipped products.
CrossBorda Case StudyHear it at your event
“Object-First: Why Your UX Breaks Before You Draw a Single Screen” is available as a keynote or workshop.
View Speaker KitBring it to your product
If your product is in fintech, EdTech, or a regulated industry and structural problems are slowing you down — get in touch.
Discuss a Project