Wrangling UX Complexity with Tree Systems 🌲

Learn to recognize and leverage this ubiquitous hierarchy pattern that you’ve probably never heard of

What’s the difference between the movie The Little Mermaid and The Little Mermaid at Mountain Cinemas? And The Little Mermaid at Mountain Cinemas at 7:30 pm on June 1st, 2023?

Are these different things… or the same thing? Is The Little Mermaid at Mountain Cinemas just an instance of The Little Mermaid?

Nope. Let’s take a look at these very different objects on Fandango.

On inspection, we can see that They have different structures (different attributes!) and even different calls-to-action. I can favorite ❤️ The Little Mermaid, but not the other objects. And the only one of these things that I can buy tickets to is The Little Mermaid at Mountain Cinemas at 7:30 pm on June 1st.

These three objects are different yet very closely related. Recognizing them as different entities is critical to conceptual/content/data modeling, not to mention all the work we do in the Object-Oriented UX world. Identifying hierarchy patterns like this one is critical for three main reasons.

Why should I care?

First, improved user experience. Users need to know what they are looking at. If we don’t get clear on these things, we will never communicate them to our users.

Second, improved content authoring, smart content propagation, and data integrity.

Third, improved analytics and high-level insights of roll-up data (for admin dashboards and the like).

I’ll get into each of these, don’t worry. But I wanted to give you some additional motivation to suffer through this article. You’ll need it, because, yes, you will suffer. Tackling all of the above with your ability to recognize Tree Systems is a power skill of the advanced UXer. It’s gonna make you look and feel like a badass. No pain, no gain! 💪

It took me years to recognize this pattern — I’d muddle through confusion as I conflated these separate objects into one, not recognizing them for what they are: a specific and ubiquitous pattern of data flow. It would create all kinds of problems in the UX design — so I wrote this article to hopefully save you some of this frustration and get you on the fast track to the badassery that will come from the new ability to grapple with this pattern.

Before going much further, if it’s not yet obvious, this article is not for beginners! If you are new to OOUX, I recommend bookmarking this bad boy and working your way through our OOUX Launch Guide first.

Or, dive in to see the kind of 4D chess that OOUX can help you play.

Regardless, have patience with this one. Give yourself time to read some bits twice. 🤓

I promise it will be worth it!

Instances versus Objects

In OOUX, we define an object as the structural entity that churns out 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.

Instances of the BOOK object include Ready Player One by Earnest Cline, Project Hail Mary by Andy Weir, and We are Legion by Dennis E Taylor. (All great books for the sci-fi nerds out there).

By the way, for OOUX-style clarity, I’ll put objects in ALL CAPS, italicize instances, and bold attributes.

Let’s get back to The Little Mermaid. Ariel is waiting. She wants to be part of this OOUX world.

Like I mentioned above, OOUX newbies might mistake The Little Mermaid at Mountain Cinema at 7:30 pm on June 1st as an instance of The Little Mermaid. But nooo nooo.

First, The Little Mermaid is not an object. It’s not a cookie cutter! It’s a cookie! It’s an instance of the MOVIE object.

Think about it. We wouldn’t create a new cookie cutter for every movie under the sun! Instead, we’ll play it smart and create a MOVIE cookie cutter (template) and stamp out all the cookies (“pages”, if you must).

Instances of MOVIES include The Little Mermaid (2023) as well as The Little Mermaid (1989) and Splash (1984). All great movies about mermaids. All instances of the MOVIE object. None are objects themselves.

Ok, so what is the “7:30pm showtime of The Little Mermaid at Mountain Cinema an instance of then?

It’s an instance of the SHOWTIME object.

To reiterate, The Little Mermaid at Mountain Cinemas at 7:30pm can’t be an instance of The Little Mermaid, because The Little Mermaid is already an instance of a MOVIE. And we don’t have instances of instances. Thank God.

But there’s another good reason. The MOVIE object and the SHOWTIME object have fundamentally different structures.

Let’s illustrate this with some Object Mapping. (Check out this quick tutorial on Object Mapping if you have no idea how to read the diagram below.)

MOVIES don’t have an attribute for date and time! The Little Mermaid is not at 7:30pm. Because across town it’s also playing at 5:30pm. And 9:25pm. And 11:15pm. The value for date and time depends on what THEATER…and what SHOWTIME at that THEATER.

A SHOWTIME for a MOVIE is at 7:30pm on June 1st. Not a MOVIE.

Conversely, we don’t want to put run time or release year on the SHOWTIME object. We want that information to reference the MOVIE object, an object likely managed by someone at Fandango HQ, not your local theater.

So, are you convinced that MOVIES and SHOWTIMES are different? And that The Little Mermaid at Mountain Cinemas at 7:30 pm is not a MOVIE instance?

Great. Let’s move on.

Introducing Tree Systems

Naming things is hard, but so important.

“Tree System” is a term born of the OOUX-community hivemind (special thanks to Caroline Sober-James). After picking the brains of many developers, we couldn’t find an existing term for this important pattern, so…we made one up. Tree Systems have nothing to do with tree-testing, tree-menus, or treemaps — except for the fact that they help describe hierarchy.

A Tree System is a hierarchy pattern that includes two or more objects: a root object, a fruit object, and often one (or many) branch objects in between. As the set of objects move from root to fruit, the concepts that these objects represent move from general to specific.

Roots? Fruits? “General to specific?” Yes, a Tree System is more of a philosophical design pattern than a technical pattern.

The Tree System starts with a root object, a thing that is general and conceptual. It’s usually not something you can actually touch. In this case, the root is the MOVIE. Branches are objects that get more specific (MOVIE@THEATER), getting us closer to the fruit. Finally we have the fruit object, the thing that is most specific and is usually the juicy thing users actually consume. 🍎

Let’s bring back those real instances, with thanks to Fandango.

The MOVIE root object is generic, agnostic of date and time and recliner seating availability.

A single instance of a MOVIE root object “branches” up to 1000s of instances of MOVIE@THEATER, adding more specifying metadata like that all-important recliner seating availability. And when MOVIE@THEATER branches off further into dozens more specific fruit-instances of SHOWTIMES, we can actually get date and time. We can also select seats on a SHOWTIME and a SHOWTIME only. (Wait! Is SEAT an object? We will get back to this…steel yourself.)

The root is where it all starts. Branches get more specific, and the fruit, well that’s the real stuff: the root object fully manifested into a more tangible, consumable object.

***

Aside: For those paying attention, yes, the MOVIE@THEATER object is a Junction Object between MOVIE and THEATER. I know. Junction Objects are sometimes part of Tree Systems but not always. 🙃 Read more about JOs here.

***

Modeling this Tree System in an Object Map, we can get an x-ray of the current state we see on Fandango today.

What’s not a Tree System?

When OOUXers first learn about Tree Systems, they tend to get excited. They start wondering if everything is a Tree System…

A TOPIC has many ARTICLES! And an ARTICLE has many COMMENTS! Is that a Tree System?

Well, let’s go back to that definition of a Tree Systems:

As the set of objects move from root to fruit, the concepts that these objects represent move from general to specific.

Well, is an ARTICLE a more specific version of a TOPIC? Not really. Is a COMMENT a more specific version of an ARTICLE? Nah. So, not a tree system.

What about… a HOUSE has many ROOMS and a ROOM has many PEOPLE in it! Tree System? (Play the general-to-specific game. What do you think?)

But is a MOVIE@THEATER a more specific version of a MOVIE? Well, yeah. And is a SHOWTIME a more specific version of a MOVIE@THEATER? Yes!

Three Reason why this matters in UX

Maybe you: Come on, Sophia! Are we just over-complicating things?

No. No, we are not! I promise. As designers of digital environments, I like to say that we are the tinkerbells of complexity. We deal with the poison of complexity so that our users don’t have to. It is our job to tame it. To make a system as elegantly simple as possible, we have to fully understand the complexity and not sweep it under the rug, hoping that someone else will deal with it down the line.

In beta-reading this article, OOUXer Shivanand Yerva was reminded of this quote from the late, great Steve Jobs:

When you start looking at a problem and it seems really simple, you don’t really understand the complexity of the problem. Then you get into the problem, and you see that it’s really complicated, and you come up with all these convoluted solutions. That’s sort of the middle, and that’s where most people stop…but the really great person will keep on going and find the key, the underlying principle of the problem — and come up with an elegant, really beautiful solution that works.”

-Steve Jobs

Tree Systems (and the ORCA process as a whole) is a tool for breaking apart complexity so we can reduce the time we spend in that messy middle of “convoluted solutions,” and get to the elegant solution faster.

Now seems like a good time to dig deeper into those three reasons why you need Tree Systems in your life.

#1: Clarity in the User Experience

Users need to know what they are looking at. Are they looking at a MOVIE or a SHOWTIME? If I am a teacher, am I looking at a LESSON TEMPLATE, A CLASS LESSON, or a STUDENT LESSON? Only one of those has a score attribute. Only one of those has a due date. (Read more about finding Tree Systems in Edtech.) We need to recognize things that are fundamentally different because we need to translate that differentiation to the user experience. Clear and meaningful objects lead to clear and meaningful UX.

It can be tough to recognize things as different when they are bound up in tight relationships and fuzzy common language (we often say “I’m going to a movie” even though technically we go to a SHOWTIME). But if we designers don’t get clear on the things and their relationships, we will never be able to clearly communicate things and relationships in our screen design. And these are foundational aspects of human understanding — what are the important things here and how do they relate? (Read more about our object-oriented brains)

#2: Smart content authoring and propagation

A smart Tree System eliminates extraneous content duplication and authoring busy work, while also locking in permissions, and making sure data stays synced across a system.

Let’s take a look.

The 19-year-old theater employee shouldn’t have to type in the release year value and upload a poster graphic for all 250 SHOWTIMEs of The Little Mermaid. Nor would we want them to — hello, human error. Instead, that information will get pulled up from the root MOVIE to the branch MOVIE@THEATER and then to the SHOWTIME. Release year and the poster graphic display on the SHOWTIME detail page, but those attributes are housed on the MOVIE object — likely maintained at Fandango HQ. Or even pulled in via an API from production studios.

So, if the fine folks at Fandango get an updated poster graphic from their friends at Disney, they will (hopefully) only need to update that poster graphic in one place, on the MOVIE object. That new graphic is then pushed to the thousands of branch MOVIE@THEATER instances and to each of their dozens of SHOWTIME instances.

This might seem obvious in our showbiz example, but I cannot tell you how many clients I’ve worked with that don’t have smart Tree Systems in place, resulting in painful, expensive, error-prone content-authoring busywork.

#3: Better analytics

While information needs to flow effectively from root to fruit, the inverse is also true. A smart Tree System means multi-level rollup data. You know that “big data” buzzword? Crafting elegant Tree Systems is one way we can help our users make sense out of big data. Let’s take a look.

For every SHOWTIME, Fandango likely has an attribute for number of tickets sold. This data should pass back to the MOVIE@THEATER object to show the performance of a MOVIE@THEATER.

Mountain Cinemas can now see that they might want to open up more showtimes for The Little Mermaid and reduce showtimes for The Boogeyman. And at the root MOVIE level, Fandango could even start providing theaters with analytics on MOVIE instances and how they are performing in various regions, within various times, and on certain days of the week . If Fandango could create predictive analytics, they could theoretically sell that data to theaters.

Back in 2017, I was object mapping with a client that builds software for managing large apartment complexes. I’d been glomming a Tree System into one object and the gears were grinding. When I realized that we needed to blow out that object into four objects with some smart up-and-down data flow, the client literally said, “you just made us millions. If we can provide this kind of data at the PROPERTY-level, the COMPANY-level, and then to our whole industry, we will be unstoppable!”

BOOM. Tree Systems FTW.

Roots, Branches and Fruits…are contextual

Still here? One last note that will hopefully not blow your mind…you made it this far so why not? Let’s do it.

What about SEAT/TICKET? Is that an object?

And what about STORY? There are at least five movie renditions of Hans-Christian Anderson’s original storyline (like The Lure, a 2015 Polish horror take on the story).

If we want to introduce these very-valid objects into our Tree System, we go from this:

To this:

Our new root is the STORY. And our new FRUIT is the SEAT/TICKET.

Did you notice that the MOVIE has 0–1 STORY? And the STORY has 2-many MOVIES?! Can you guess why I modeled the cardinality like this?

Also, can you think of one more branch that’s likely very important for our theater manager role?

Let’s discuss this over in the OOUX Forum! If you haven’t created an account yet, it’s totally free and there are so many goodies over there, including Q&A on this article, ongoing monthly Q&A, and the first two modules of my OOUX Fundamentals course.

OOUXers are wired to make a system as simple as possible, but if we cross that invisible line into over-simplification, we actually make structuring data and content harder. We need to make the system as simple as possible, but no less. Tree Systems don’t introduce complexity — they help make inherent complexity more elegant, effective, and understandable.

If you got through this article, congratulations! You are the exact type of person who would love the OOUX Masterclass.

Learn more about this complexity-wrangling deep dive