Introduction to Object-Oriented UX
#52: How Object-Oriented UX can help you design complex systems
Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community.
Object-Oriented UX
UX designers work on a wide range of products, from websites and simple mobile apps to advanced and complex systems. It’s often with these systems that the biggest challenges appear: making sure the product is as simple and intuitive as possible for users, and that its content is well thought out and meets their needs.
To support us in tackling these challenges, we can introduce a method into our design process that simplifies complex system design by enabling a more structured and thoughtful approach. That method is Object-Oriented UX.
What is Object oriented UX (OOUX)
Object-Oriented UX is a way of thinking about design, introduced and popularized by Sophia Prater. It assumes that instead of starting with specific screens or user flows, we begin by identifying the objects that should exist in the system, their attributes, the relationships between them, and the actions users can take on those objects. Only after this stage do we move on to designing user flows and wireframes.
Objects, Attributes, Relations and Actions
Earlier, I mentioned objects, attributes, relationships, and actions. These are the four key elements of the OOUX methodology. Let’s take a closer look at each of them.
Objects
Objects are the core building blocks of a system. They serve as the foundation for its structure and interactions.
In an e-commerce site, for example, typical objects might include a product, a cart, and an order.
Attributes
Attributes are the properties that describe objects. They help users identify and distinguish between different objects.
For instance, attributes of a product might include its name, price, and availability. A cart could have attributes like total value or number of items, while an order might include an order number, status, and payment method.
Relationships
Relationships define the connections and dependencies between objects in the system. They show how objects are linked and how they influence each other.
For example, a product belongs to a category, a cart contains products and is associated with a user, and an order is tied to a specific cart, user, and set of products.
Actions
Actions are the things a user can do with or to an object — as well as the things objects can do on their own.
For example, actions for a product might include “add to cart,” “save for later,” or “compare.” For a cart, actions could be “clear cart” or “proceed to checkout,” and for an order: “track shipment,” “cancel,” or “reorder.”
Assumptions and value of OOUX
Designers often jump into creating user flows (or even final mockups) before they fully understand what they are designing and who they are designing for. If you don’t know the objects that make up the system, you simply can’t design it well. Object-Oriented UX (OOUX) allows us to define the structure of the system early on: what objects exist within it, what attributes describe them, how they relate to each other, and what actions users can take on them. OOUX is not meant to replace any part of the design process. Instead, it adds an important step that forces a deep understanding of what the system is made of, which objects are essential, and how they are connected. It also helps surface knowledge gaps early, so they can be filled before it’s too late.
OOUX is based on the idea that we focus on objects. This aligns with how people think in everyday life. We are surrounded by objects that have attributes and relationships. Reflecting this in our designs makes it easier to match users’ mental models, resulting in better usability and clearer system comprehension.
OOUX is also highly effective in mobile-first design. By prioritizing objects and their attributes using the ORCA method (which will be explained in more detail later in this article), we can easily take a sorted list of elements and translate it into a mobile layout. This ensures the interface presents information in the right order, matching real user needs by showing the most important objects and attributes first.
Mapping and prioritizing objects also keeps us closely focused on user needs. Every object and attribute must be well thought out, and we should only include those that genuinely address those needs.
OOUX helps the team think about information architecture and data modeling before diving into interaction and visual design. This often leads to more stable and sensible solutions. Well-defined objects, attributes, and relationships also make it easier to scale the system by introducing new objects over time.
OOUX ensures consistency throughout the system. Since everything is built on a set of pre-defined objects, we can guarantee that the same objects behave consistently in different parts of the system. This leads to higher usability and reduces cognitive load, because users don’t need to relearn how the system works or get familiar with similar objects multiple times.
Since OOUX is inspired by object-oriented programming and how developers think, it also improves communication by allowing designers to speak a language that feels more natural to developers.
To sum up, here are the key benefits of Object-Oriented UX:
Better understanding of the system before designing
Defining the system’s structure early in the process
Reflecting users’ mental models
Support for a mobile-first approach
Focus on user needs
Guidance for information architecture design
Easier system scalability
Consistency across the entire system
Smoother communication with developers
ORCA Method
The main method used within the context of OOUX is ORCA, which was also created by Sophia Prater. The name ORCA comes from four key pillars: Objects, Relationships, Calls-to-Action, and Attributes, which I mentioned earlier.
In the context of OOUX, the concept of mapping objects along with their relationships and attributes often comes up. This can give the impression that the process is simply about sticking some Post-its on a board. However, ORCA is much more than that. Its real value lies in the fact that it is not designed to work in isolation from user insights and real data. As mentioned earlier, OOUX is not meant to replace any part of the UX process but to enhance it. This is clearly illustrated in the diagram below, which places ORCA between the Research and Design phases of the double diamond model. From this, it’s easy to see that in order to go through the ORCA process effectively, we need to complete our research first and have a solid understanding of our users, their needs, their problems, and their mental models.
The ORCA process consists of four main stages: Discovery, Requirements, Prioritization, and Representation. In each stage, we work through the core pillars of OOUX. As Sophia Prater herself says, you don’t always need to follow all 15 steps of the process. ORCA is a flexible framework that you can adapt to your current needs and context.
1. Discovery
In the first stage, we focus on high-level exploration of all four OOUX pillars. We use the data we've already gathered and ask questions that help us identify key objects, their relationships, what users want to do with them, and what attributes they should contain. At this point, we may also discover gaps in our knowledge that require us to revisit the research phase and gather additional data.
During this stage, in addition to identifying objects in the form of nouns, we also prepare a nested object matrix and a CTA matrix. The stage concludes with object mapping, where we visualize objects, their relationships, available actions, and attributes. This is a critical part of the entire process and a cornerstone of the OOUX approach. Below, you can see an example of object mapping.
2. Requirements
The second stage is about taking a closer look at what we developed during the discovery phase and refining each element of ORCA. We dive deep into all four pillars and make sure we have everything we need for the upcoming design phase. At this point, we can explore questions such as what makes an object unique, which attributes are required, who can edit the object, and how it changes over time.
3. Prioritization
The third stage focuses on prioritization. Here we can define priorities for the identified areas, the order in which we’ll work on them and implement them, as well as the hierarchy of objects and their content from the user’s perspective. This step is especially helpful in a mobile-first approach, as mentioned earlier. Prioritization allows us to easily transfer the established hierarchy from object mapping into the mobile design and reflect the intended order of content. Prioritization is done by setting the appropriate order of elements on the object map.
4. Representation
The final stage is about representing what we’ve developed so far. Only at this point do we start designing screens using our defined objects. We then build a prototype, validate it, and iterate based on feedback.
When not to use OOUX
Just like any other method we use in our work, Object-Oriented UX is not the perfect fit for every situation. In the case of simple projects like company websites, portfolios, blogs, or landing pages that serve mainly an informational purpose and don’t involve many objects or relationships for users to interact with, OOUX will likely not bring much additional value. Instead, it may require a significant amount of time and effort. The same applies to products with a simple, linear flow that often follow a predefined user path.
Similarly, if you are in a very early stage of discovery, you should not focus on identifying objects yet, as you probably do not have enough data to do it properly. At that stage, your attention should be on user needs, goals, and problems. For OOUX to be effective, it has to be grounded in data. If we lack insights into the business domain, processes, or user needs, it will be difficult to model the right objects and relationships.
It is also important to consider how familiar your team is with the method. In my opinion, it is not worth implementing it right away if the team is not yet able to fully take advantage of what it offers. Of course, learning by doing is a great approach, but if there is not enough time for team training or exploring the method while working on active projects, OOUX might end up being misunderstood, used incorrectly, or even rejected altogether.
This also applies to limited resources and deadlines. OOUX is a time-consuming method, especially in the early stages, so if we do not have time or resources, then even despite having complex projects, the decision to use OOUX may be unfavorable from a business point of view, even if in the long run it guarantees a better solution that is much further in time.
Want to find out more?
I hope Object-Oriented UX has sparked your interest and, more importantly, that you see the same value in it as I do. If that's the case and you'd like to dive deeper, I highly recommend visiting https://www.ooux.com, a website created by the author of the OOUX methodology herself. It's an excellent source of materials, podcasts, case studies, and training that will support you in exploring OOUX and applying it to your work.