Tomasz Opalski — UX Senior Expert w ING at Independent
ResOps w służbie badaniom - czym jest, jak z nim pracować i co on nam daje
September 20, 2024
14:40
Research Ops
🇵🇱 Polish
Research Ops
OOUX & ORCA Explained: Research, Organize, and Commit to Success
About
Navigating the complexities of product development can be daunting, especially when teams lack a complete picture. This session explores the ORCA method, an object-oriented approach that bridges the gaps left between research and design by traditional frameworks. Attendees will dive into real product scenarios, discovering how OOUX and ORCA can be applied from different angles. By understanding system pieces and relationships, teams can improve planning, enhance data strategies, and be confident with designs that align with user thinking. Attendees will learn the principles of Object-Oriented UX (OOUX) and how ORCA fosters a shared understanding, leading to intuitive solutions and efficient development processes. This approach ensures seamless collaboration among product managers, designers, data analysts, researchers, content designers, and engineers, resulting in intuitive solutions and efficient development processes.
Watch the full talk
Watch this WaysConf session, then continue with related talks or explore the current programme.
From the recording
Talk in brief
Gabriela Ospina presents Object-Oriented UX (OOUX) and the ORCA process as a way to understand a complex product before drawing screens. The approach starts with the nouns in a domain—the people, places, and things users recognize—rather than beginning with task flows. Teams then map relationships between those objects, identify the actions each object offers to different user roles, and define the content and metadata that make each object meaningful. The result is an object map: a shared model that can expose unanswered business rules, guide navigation, inform data structures, and show what a page must contain. Ospina’s argument is not that ORCA replaces research or an existing product process. It supplies structured questions between research and interface design, allowing product, design, engineering, content, and data partners to resolve uncertainty together and reduce costly rework later.
Key takeaways
- 01
Complex does not have to mean complicated
A domain may contain many connected parts while the product remains understandable. The design task is to model those parts clearly instead of transferring complexity to users.
Watch from 1:18 - 02
Define the system before composing screens
Starting with interfaces forces teams to decide content, architecture, and business rules simultaneously. ORCA separates those questions and makes them collaborative.
Watch from 2:46 - 03
Start with objects in the user’s mental model
People enter products for recognizable people, places, and things—not for interface components. Naming those objects creates a stable vocabulary for the team.
Watch from 7:49 - 04
Relationships reveal navigation and data rules
Mapping how objects connect and their cardinality helps teams find natural navigation, missing states, and backend implications before implementation.
Watch from 12:22 - 05
Attach actions and attributes to their objects
Role-specific calls to action and prioritized content make available behavior easier to find and clarify what each screen needs to communicate.
Watch from 16:51
Read edited transcript highlights
These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.
The gap between research and screens
Ospina describes design as the management of complexity. Research may reveal a problem, but teams still face structural questions before a solution is ready for interface design. Under pressure to show progress, designers often begin drawing screens while simultaneously deciding content, navigation, and business rules. That creates hidden multitasking. The alternative proposed here is to make the system explicit first and invite the product-creation team to answer the difficult questions together.
Watch from 1:18Objects before tasks
Object-Oriented UX begins with the nouns in the user’s mental model. A social product contains people, posts, messages, comments, jobs, or recommendations; a delivery product contains consumers, couriers, venues, menus, items, and orders. These objects are not UI components. They are the things users and the business care about. Identifying and defining them exposes ambiguity early—for example, whether two similar nouns are truly the same object or follow different rules.
Watch from 6:22Mapping relationships and cardinality
The second ORCA question asks how the objects connect. A nested object matrix records whether one object must, may, or may not have another. That model can reveal natural nested navigation, empty states that are or are not possible, and data relationships engineers will eventually need. The value is not the diagram itself; it is the conversation it makes possible before the team invests in finished designs or discovers contradictions during development.
Watch from 12:22Actions belong to objects and roles
The call-to-action matrix lists what different user roles may do with each object. A consumer, merchant, and support employee may have different actions on the same venue, menu item, or order. The team then asks why the action exists, when it should be available, and what prerequisite or context applies. Tying actions to objects helps users find available behavior and prevents important interactions from being scattered across unrelated parts of the interface.
Watch from 16:51Content and metadata form the object map
Attributes describe what makes an object recognizable. ORCA separates core content—such as a unique name, image, or description—from metadata that may support sorting, filtering, or grouping. Adding attributes and actions to the relationship model produces an object map, a high-level view of the system. Teams can prioritize what appears in a compact card and what remains one click away, then create wireframes with confidence about what each screen represents.
Watch from 20:16A tool inside the existing process
ORCA is presented as a tool, not a replacement for research or delivery practice. Teams can begin with the question they currently cannot answer, reverse-engineer existing screens to recover their objects, or document a complex domain for future contributors. The model helps product disciplines share language and gives newcomers a durable explanation of the system. Its intended outcome is less guesswork, earlier collaboration, and interfaces that reflect the way users understand the domain.
Watch from 24:07
Explore WaysConf 2026
