About ten years ago, I was part of the digital design team for one of the biggest dutch supermarket chains. While going through the motions of designing new features and user stories, the product owner kept asking the same question: “Do we need that button?”

A story from the past

In one of those cases, we looked into a significant website upgrade. The web application served primarily as a shopping list to plan groceries. The upcoming set of features was supposed to bring it to the next level and enable grocery delivery.

This seems normal today, but at this time, it was something new. There were no best practices to lean on, so I followed e-commerce standards. I extended the information architecture to make room for a shopping cart and a check-out flow. As mentioned earlier, the first reaction from my product owner was, “Do we need this button?” Or, in this specific case, do we need to extend the IA and add new components and flows?

My approach to organic growth would make the application unmanageable. Not only for the design and development team but even more critical for our users.

I assumed that big features needed a new UI. And consequently, I would need to extend the information architecture. It was one of the first projects where I would help to grow a product. I didn’t consider the consequences. My approach to organic growth would make the application unmanageable. Not only for the design and development team but even more critical for our users.

And my product owner was right! Following his approach, we could enable new functionality by reusing and extending existing components. His way of looking at new features kept the UI and information architecture simple. At the same time, it saved design and development efforts. But how did he get to this solution?

Scaling the information architecture

In some cases, we are lucky. We can start with a somewhat blank slate and establish a new information architecture. I often compare this to moving into a new house. The floorplan is the only restriction. Based on what we know, everything can be arranged in the most ideal way.

However, as with our homes, new needs occur over time. Some things might have been anticipated, but others haven’t. Sometimes, it is enough to rearrange some rooms. But there will be a moment, like my shopping cart example, where it seems more difficult. So we start to add new rooms. Our information architecture becomes more and more skewed and harder to use. Ideally, we would take a step back and reassess the overall structure, but we often lack the time or a framework to do this on the fly.

Introducing OOUX

My product owner understood that you must look beyond components, flows, and even the information architecture. He looked at the system — the objects — that drive our application. He used something similar to what we would call OOUX today.

In its essence, OOUX is mapping an application via relatable objects. In my example above, the shopping list and the items on the list would be such objects.

Scaling with OOUX

New features always feel like something different, which could certainly be the case. Yet often enough, those features are related to existing objects in one way or another.

We first need to understand the existing object model to make this assessment. The ORCA (Objects, Relationships, Call-to-Action, Attributes) framework provides a starting point for breaking down the application and creating a baseline map. This should help you understand the existing objects, relationships, and attributes/ content elements.

• O — What are the objects used in the mental model
• R — How do those objects relate to each other
• C — What are the call-to-actions of each object
• A — What are the attributes (or elements) that make up each object

Dale Owen’s article “What is object-oriented UX?” gives you a great overview of the detailed process. Once we have our baseline, we can do the same with our new features and start to compare them.

Here are a few pointers to think about:

• Consider if there are existing objects that have a similar meaning.
• Check if there are objects that have similar content elements.
• Assess if there are other objects with the same relationships.

As long as the elements or relationship elements don’t contradict each other, we might be able to incorporate them by simply widening their scope. This might not be as straightforward as it sounds, and we will need to play with the object models to make them fit.

In my example above, we had a shopping list object that contained a shopping list item. The new objects were a shopping cart and a shopping cart item. You probably see where this is going. The shopping list and shopping cart were very similar. The only additional need was a check-out button. The same applied to the items. We only had to extend them to show the price and their availability. With a few tweaks to the existing components, we could enable a whole new level of features. As a result, the information architecture could remain the same, and we could reduce the design and development.

Summary

Next time you work in a team that scales an application, do an initial assessment of the underlying object model. Dissect each new feature into its required elements, and compare them. Try to find ways to leverage existing objects. In many cases, this will help you prevent adding new rooms and keep the information architecture lean. The initial effort up front will save time during detailed design and development.