Stop thinking about flows, start thinking about objects
Why an object-oriented UX approach helps build scalable and consistent systems
Task-based user flows are the golden standard of UX design. First, you examine the user’s goal. Next, you identify the tasks required to achieve them. Finally, you put those tasks into a logical sequence, et voila, a user-based flow. This approach is one of the main staples of UX design. It is tested and proven. Yet, I want to propose a different approach. An “object-oriented” approach that models the user experience around the content elements. A mindset that helps you to keep the UI scalable and consistent.
I have been designing applications and websites for more than 20 years. As a designer, I always referred to myself as a system designer. This is because I see applications as an orchestration of individual content pieces, each with distinct attributes and functions. In concert, they create the user experience. In the past, this helped me build more coherent experiences that can grow with the needs of the business.
The problem with task-based thinking
I still use design flows, but I see them as a method to exemplify the system, not my thinking process. A case-by-case approach will force you to constantly consolidate requirements. And in consequence, update any involved components. This will cost time, but if not done, it will result in many components and a system that is hard to maintain.
Eventually, with more flows layered on top, the design system reaches a breaking point. You will either have to redesign significant parts or create expectations that dilute the design system. If development hasn’t started, a redesign is possible. But it will need a significant amount of design work. If development has started, it gets much trickier. The design update requires not only extra design work but also extra development efforts.
I am pretty sure we all have been in this situation. What did you do? And how did this impact your UI in the long term? Creating one or two of those exceptions isn’t the end of the world. But, with every update, you will have more components and exceptions to consider. Keeping the system clean and simple for the user, designers, and developers will get exponentially more difficult.
Introduction to the object-oriented viewpoint
Let me use an analogy for the thinking approach. Imagine you are trying to map a dark basement. You could use a flashlight and walk through it. Or you switch on the top light and look from an elevated position. Using a flashlight will give you more detail for one specific route, but you might miss the bigger picture. Likewise, the toplight provides you with an overview to understand the organization. Initially, you might miss some details. But it is easier to detail a system than change it.
Object-oriented thinking goes beyond individual user goals (flashlight). It approaches the interface from a holistic point of view (top light). It first looks at all the content and data (boxes in the basement). Then it attempts to create a high-level map, an orientation system, a scalable mental model. And then it starts to detail its parts (unpack the boxes).
Object-oriented thinking is nothing new. It is common practice in many programming languages. Some of us might already apply object-oriented thinking somewhere in our process. But it was only a couple of years back, in 2016, when Sophia Voychehovski Prater first coined this approach Object-Oriented UX (OOUX).
OOUX starts with the content instead of screens or flows. An object-oriented approach models the application based on real-life objects. Those objects don’t need to be physical objects, but something users can relate to. To make an example: within a shopping experience, those objects would be products, shelves, a shopping cart, and a cashier. The goal is to identify all involved objects, their core content elements, metadata, nested objects, and user actions.
OOUX approaches this as follows:
- Starting from the user goals, identify all required objects to achieve those goals. Make sure those objects mean something to your users.
- Identify the relationship of your objects. Determine how they relate when you work through your use cases.
- Next, you determine the required actions for each object. Map everything users need to do with those objects to achieve their goals.
- Lastly, you need to identify the actual content elements: the core content and object metadata (also referred to as attributes).
Keep in mind that this process might not be linear. You will need to go back once in a while until the system as a whole feels stable. Once everything is indexed, those elements get prioritized. So no matter when and where the object is shown in the UI, it follows a consistent content hierarchy.
I won’t go much deeper into the actual process. There are plenty of great articles which cover this from all kinds of angles. If you want to know more, check out “An introduction to object-oriented UX and how to do it” from Lindsay Eryn Sutton.
Instead, let me walk you through two key concepts of an object-oriented mindset. Considering those will help you to make better decisions throughout the process.
Designing with an OOUX mindset
Abstraction is one of the central concepts behind object-oriented programming. The idea behind it is to simplify an object to only relevant information. From a UX point of view, I would extend this concept. Playing with abstraction is important. It enables you to determine if certain information should be combined into one object or split into multiple.
Imagining your application sells fruits. Thereby fruits could be an object. As long as the UI handles all fruits the same, this abstraction level is great. If certain fruits need different content elements, you might want to split them. Instead of having one object called fruits, you’ll have multiple objects e.g., apples, bananas, etc.
Playing with the level of abstraction enables you to steer the complexity of your system. The more objects, the more complexity! Understanding which level works best for your application can take time. You might need to create different abstraction models and do some iterations. Don’t rush it. The content objects determine your baseline. Together with their relationships, they will govern the architecture and mental model.
The objects and their relationship create coherent and consistent building blocks that form a recognizable and relatable mental model.
Furthermore, those objects can help to determine and design the individual components. In most cases, content objects are used in different locations throughout the user experience. To understand where they are instantiated and in how many variations they appear, you can check where they are nested. The prioritization of its parts will help you to know which parts are required at which moment. This approach ensures a consistent appearance across the application or website.
The objects and their relationships can give you an excellent understanding of the interface’s needs. Although it does need some more theoretical work upfront, it will create a more consistent system. In addition, it will save you time and effort in the long run.
So what about scalability?
Scaling an object-oriented system
Encapsulation is another key concept of object-oriented thinking. Objects should work independently, without little to no outside influence. Only nested objects should have some degree of dependency. From a UI point of view, this is useful to create more independently working UI components.
From a UI point of view, each object should be rendered via its own components. Most objects will have multiple instantiations, but those instantiations’ hierarchy should be independent. They should be protected from outside influence.
Let’s go back to the fruit example and imagine a fruit object within an application. No matter if the object is shown in a grid, on a detail page, or in the shopping basket during check-out. Each component should be independent of where it is shown. The location might influence the visible actions. But the content and how it is rendered should stay the same. This concept will help to design more enclosed interactions and independent UI components.
Object encapsulation creates more enclosed and independent UI components that scale independently.
Earlier, I talked about the moment when a significant redesign is imminent due to a flow-based approach. If done thoroughly, this is where an object-oriented approach shines. The initial effort to map the system and its content should have made you aware of any game-changing objects. The extra time you took to model your system should provide you with a scalable foundation. Also, due to the encapsulated nature of the content objects, there should be only a small need for consolidation on the UI level down the road. Even if new requirements occur, they should have less impact on the overall system. They are only additions to one or two objects. Thus, the need changes become mostly an evolutionary process rather than more extensive redesigns.
Why flows are still relevant
As I mentioned in the beginning, I still use flows. They still play an essential role in my design process. Once the system is in place, they help to catch some of the contextual details. Furthermore, an object-oriented approach is relatively abstract. They align with the developers’ mental model. Yet, they might be hard to grasp for the product team or other non-technical stakeholders. Flows help to demonstrate the system and make it tangible.
Summary
Object-Oriented UX (OOUX) proposes a different mindset to design applications. It approaches the UI from a holistic point of view. It puts the content first. It helps designers to establish a foundation based on relatable content objects. It establishes a system centered around the objects and their elements, attributes, actions, and relationships.
Playing with the abstraction level of the system enables designers to control the complexity. As a consequence, it helps to create coherent and consistent building blocks. And together, they form a recognizable and relatable mental model. The element prioritization of the object drives the individual content hierarchy. It ensures consistent UI components across the application. The concept of encapsulation helps to design enclosed UI components that scale independently. Consequently, the approach supports the natural growth of an application. And it reduces the need to redesign and redevelop significant parts.
Eventually, if this article inspired you to look deeper into object-oriented UX, maybe you even try it in your next project.
For more on OOUX, check out some of my other articles.
