Breaking Down Object Bases and Tree Systems in OOUX: When and How to Use Them

When I first started learning about tree systems, I confused this concept with the concept of an object base. For me, understanding the differences between these two concepts was key to gaining a deeper understanding of tree systems and their benefits. Let me remind you what an object and an object base are.

In OOUX, ‘objects’ form the backbone of the design. These archetypal real-world entities matter to both users and the business. They represent the things users come to your site for and should have structure, purpose, and individual instances.

“Think of objects as the conceptual cookie cutters and instances — as the cookies. Objects are the blueprint, instances are the actual things of substance that people interact with”. — Sophia Prater, founder and chief evangelist of Object-Oriented UX.

An ‘object base’ has a different function. It is a foundational object in a system that serves as the starting point or ‘blueprint’ for creating more specific objects. In Object-Oriented UX (OOUX) and Object-Oriented Programming (OOP), an object base provides a common structure, including attributes (properties) and behaviors (methods), that can be shared and inherited by more specific objects, often called ‘derived objects.’

This is an advanced article for Object-Oriented UX (OOUX) designers. If you are a beginner or unfamiliar with the Object-Oriented User Experience methodology, I recommend starting with OOUX launch guide, created by Sophia Prater. Sophia is the founder and lead UX designer at Rewired and the chief evangelist of OOUX. Everything I have learned in this field is thanks to her work.

When using two levels of object bases, you create a hierarchy where the first level is more general, and the second level is more specific, but still serves as a base for further specialization.

Two-level object base structure:

• First-level object base: This is the most general object in the hierarchy, containing attributes and behaviors that are broadly applicable to both the second-level object base and all derived objects.
• Second-level object base: This inherits from the first-level object base but introduces more specific attributes and behaviors. It can serve as a base for further derived objects.
• Derived objects: These objects inherit attributes from both object base levels and are the most specific in the hierarchy.

A graphic illustrating how inherited attributes are recorded.

Examples of E-commerce that uses two-level object base structures:

• First-level object base: product.
• Second-level object base: cloth, shoe.
• Derived objects of cloth: shirt, pants, dress.

This is how the object map will look like:

Level 1 — object base

🟦 Product

• 🟥 SKU (unique identifier)
• 🟥 price
• 🟥 brand
• 🟦 reviews(nested object or metadata)
• 🟥 availability
• 🟨 image

Level 2 — object base:

🟦 Clothes (as a more specific object derived from a Product)

• 🟥 size
• 🟥 color
• 🟥 material
• 🟥 gender (metadata for men’s, women’s, unisex)
• 🟦 has 0-many accessories (nested object)

Derived objects from clothes:

1. 🟦 Shirt (derived object from clothes)

• 🟥 sleeve length (short, long, sleeveless)
• 🟥 fit (slim, regular, oversized)
• 🟥 collar type

2. 🟦 Pants (derived object from clothes)

• 🟥 waist size
• 🟥 length
• 🟥 style (e.g., jeans, chinos, dress pants)
• 🟥 pocket style

3. 🟦 Dresses (derived object from clothes)

• 🟥 length (mini, midi, maxi)
• 🟥 occasion type( formal, casual, evening)

Another example I want to give is with a financial platform where Transfer is an object base, and Account transfers, Wire transfers, ACH transfers, and Real-time payments are derived objects.

Identifying opportunities to use an object-based concept in your system:

• Identify two or more objects that share both common and distinct attributes.
• Each of these objects has a clear purpose to exist as a separate entity.
• Derived objects inherit all attributes from the object base.
• Object bases are never instantiated — only derived objects are.

The purpose of using an object base:

• To reduce redundancy in the documentation.
• To consider a UI representation where derived objects share many similarities, but users can still easily differentiate them.
• The developers might also consider using a Base class.

On the other hand, the tree system concept is a hierarchical structure that organizes objects in a sequence from general (root) to specific (fruit), often passing through intermediate (branch) objects. It focuses on the flow of data and the relationships between objects as they become more specific.

Tree system structure:

• Root object: The most general object in the hierarchy, serving as the starting point. It often represents a broad concept.
• Branch objects: Intermediate objects that add layers of specificity. They bridge the gap between the root and the fruit, introducing additional context and attributes.
• Fruit objects: The most specific objects in the tree system represent the final, tangible instance that users interact with.

A graphic depicting the tree system structure, where ‘course’ serves as the root object, ‘module’ is the branch, and ‘lesson’ is the fruit. The illustration also highlights the cardinality relationships between these objects.

To understand the meaning of this complex system, we will have to discuss parent-child relationships. In object-oriented development, several types of relationships define how objects interact or depend on one another, each with unique implications for structure, behavior, and reusability.

1. Association

• Definition: Association is a connection between two independent objects where they interact in some way but don’t have ownership over each other.
• Example: A teacher and a student are linked in an association since the teacher teaches the student, but each object (teacher, student) exists independently.
• Types: Association can be one-to-one, one-to-many, many-to-one, or many-to-many.

2. Aggregation

• Definition: Aggregation is a type of association where one object contains other objects, forming a “whole-part” relationship. Here, the “whole” and “parts” have a looser connection; the “parts” can exist independently of the “whole.”
• Example: A library contains books. If the library is demolished, the books still exist independently.

3. Composition

• Definition: Composition is a stronger, more dependent form of aggregation. In composition, if the “whole” is destroyed, the “parts” cease to exist because they rely on the “whole” for their existence.
• Example: A house and its rooms. If the house is destroyed, the rooms no longer exist. Here, rooms are an intrinsic part of the house.

4. Inheritance

• Definition: Inheritance is a relationship where one class (called the subclass or child) derives attributes and behaviors from another class (called the superclass or parent), thus establishing a hierarchy. The subclass gains access to the methods and properties of the superclass and can also introduce its own.
• Example: A car is a type of vehicle that inherits characteristics like movement and speed control. It can also add its own features, like a trunk.

5. Dependency

• Definition: Dependency exists when one object requires another to function. This is typically a “uses-a” relationship, where one object relies on the other temporarily to complete a specific task.
• Example: A printer depends on a document to print. Without the document, the printer has nothing to print.

Tree system objects have parent-child relationships, but not all objects with parent-child relationships are considered to be part of a Tree system. The Tree System is used to model complex, hierarchical relationships where objects become progressively more specific as you move down the hierarchy. It’s particularly useful for managing and displaying data that flows from general to specific, especially when the relationships between objects are essential for understanding the system.

Identifying a Tree System Concept in Your System:

1. All parts of the tree system must be objects with distinct instances.
2. The root (parent) object can have 0-many branches (children), and each branch (parent) can have 0-many fruits (children). However, each fruit (child) must have exactly 1 branch (parent), and each branch (child) must have exactly 1 root (parent).
3. Inheritance of attributes: child objects inherit attributes from their parent objects, while also having their own unique attributes.
4. Child objects cannot exist without their parent (composition relationships).
5. The structure should move from general to specific, as the user “consumes” the fruit.

Example with an event management system:

1. 🟦 Root object: Event

• 🟨 Title: Tech Innovators Conference 2024
• 🟨 Description: A multi-day conference featuring discussions on the latest technology and innovation.
• 🟥 Location: New York Convention Center
• 🟥 Dates: June 1–3, 2024

2. 🟦 Branch object: Session

• 🟦 Has 1 parent object: Event
• 🟨 Title: AI in Healthcare
• 🟥 Speaker: Dr. Sarah Lee
• 🟥 Duration: 1 hour
• 🟥 Date: June 1, 2024
• 🟥 Time: 10:00 AM — 11:00 AM
• 🟥 Room: Room 101, East Wing
• 🟥 Topic: How artificial intelligence is transforming healthcare.

3. 🟦 Fruit Object: Session review (audience's version)

• 🟦 Has 1 parent object: Session
• 🟥 Date: June 1, 2024
• 🟥 Time: 10:00 AM — 11:00 AM
• 🟨 Audience’s review description.
• 🟨 Audience’s attached images

For now, I’ve identified two main reasons why it’s important to recognize tree systems within your platform:

1. Presenting the correct attributes to the correct object. For example, an audience’s review description should not be attached to the Session object or to the Event as a whole. This review is not about the entire event — it’s specific to a particular Session.
2. Providing context for the parent object when viewing a child object. Since the review is tied to a specific Session, it’s important to always show the parent object when you’re on the child. In this case, when the audience leaves a review for a Session, they should see (perhaps via a mini card) which Event that Session belongs to.

Each concept serves a different purpose in modeling systems and organizing objects, helping designers clarify how objects relate to one another in a digital environment. By identifying the correct type of parent-child relationship, OOUX ensures a clearer, more intuitive design that reflects real-world relationships between objects.

By using OOUX, designers aim to align the digital user interface more closely with the user’s real-world understanding and expectations, making the experience more intuitive and effective. This methodology is beneficial when designing complex systems with many interrelated parts and can help simplify the user’s interaction with the system by reducing cognitive load.