Object Modeling for Designers: An Introduction

As a user experience designer, it can feel as though I am waging an on-going, never-ending battle against complexity, especially when working on enterprise systems.

A popular route to simplify an experience is to implement a design system. A number of full-fledged design systems are accessible on the web, and it doesn’t take much of a discerning eye to see the influence these systems have had on application design (an influence I’ll say more about later).

Design systems are essential, but what I hope to show in this article is that a design system alone — particularly if it’s primarily a component level design system — does not guarantee a simple, consistent experience. I believe this because I see it regularly with the enterprise clients I work with. Most (though not all) have moved to a design system. And yet when I look at the result, there are still significant inconsistencies across screens that should be fundamentally similar.

Design systems also don’t prevent what I call “feature tack-on,” where new functionality is merely tacked on to what is already there. Over time, this can create a labyrinth-like application structure. Feature tack-on is particularly endemic with enterprise systems, where customer requests can drive the development of highly specialized features.

How an Object Model Can Help

This is where an object model can help.

An object model is a visual representation of a system’s objects, actions, and associated attributes. An object model can be used, in conjunction with a design system, to create a consistent experience across a system’s higher-level constructs.

What exactly is a higher-level system construct? This idea is illustrated by Brad Frost’s Atomic Design Methodology, which uses a biology metaphor to describe how a design system can be organized. The smallest possible system components (such as an individual button) are considered atoms; atoms, in turn, can be arranged into molecules (for example, a group of components used for global search). Organisms, as a higher-level construct, are a grouping of molecules. The metaphor isn’t perfect, but it does convey the general scheme.

Brad Frost’s Atomic Design Methodology

I believe that design systems often struggle to represent higher-level system constructs because there isn’t enough of a framework to identify what should be included there. This issue is what object modeling can address.

Roots of Object Modeling

A command line interface
Xerox Star 8010, 1981. Note the window with the conference paper: they are talking about objects and actions! These are key constructs underlying a GUI.

In the 1990s as software began to proliferate, development processes became more formalized, and there was interest in representing software requirements in a consistent manner. UML (Unified Modeling Language) was developed to meet this need. The UML diagrams that are most likely to be familiar to UX-ers even today are the Use Case Model and the Class Diagram.

The Use Case Model is a behavioral model and depicts the system from a task perspective (similar to user stories in Agile).

A simple use case diagram for a banking system.

The Class Diagram is a structural model, which shows a system’s objects and the relationship between them. Each object rectangle includes the object’s associated actions (in the lower pane) and attributes (in the middle pane).

An example UML Class Diagram for an ATM.

Within development processes reliant on UML, there was an emphasis on object-oriented user interface design, using the Class Diagram as the basis. And, indeed, in the 1990s whole books were written on this methodology.

Books promoting object-oriented interface design. You can still purchase these today via Amazon.

Admittedly, a complete Class Diagram can be time-consuming to complete and requires a set of analysis skills more typical of an engineer or analyst. It’s not something a UX professional today would typically prepare.

I would argue, however, that object-orientation is a lost and necessary part of UX design, particularly for more complex applications.

The Narrative Object Model

Creating a Narrative Object Model

1) Identifying the Objects

2) Characterizing the Relationship Between Objects

3) Identifying each Object’s Actions and Attributes

Source Materials for the Model

In my consulting work, I usually am starting with an existing system that we will redesign or re-envision in some way. Starting the model by inspecting that system’s existing interface accomplishes two things: 1) it gets me intimately familiar with that system in its current state 2) it provides a baseline object model that can then be extended to depict the desired future-state.

The other primary source for an object model is user stories or other requirements-oriented artifacts. For greenfield design work, these may be the only sources available.

We’ll begin an example model by looking at an existing interface, using the relatively simple example of Twitter.com.

First, however, it’s important to define two central concepts: an object and an action. Simply stated, objects are the nouns in a system and actions are the verbs. In an existing interface, menus and button bars often contain clues to a system’s objects and actions.

When working with objects, it’s also important to remember the difference between the object, which represents the concept, and an instance of an object. For example, most systems have the concept of an Account, which would be an object. However, there are many instances of an Account: the account of Louise Hughes, the account of Ramon Woods, etc.

Identifying Objects

The button bar (bottom) and menu (right) can be a source for identifying objects.

Looking at the menu labels, I can see that one noun is a Tweet. We have for example:

  • Copy Link to Tweet
  • Embed Tweet
  • Report Tweet
  • I don’t like this Tweet

Additional nouns I can identify are:

  • An Account, represented in this case by the account name Fine Cooking Mag (an instance of the Account).
  • A Moment, indicated by the menu item “Add to new Moment.”
  • A Direct Message, indicated by the envelope icon which means “Send Direct Message.”

The marked-up screen capture below shows the objects we’ve identified thus far:

Objects identified from a Tweet’s button bar and menu.

In our model, the objects become titled rectangles that we will connect together to show relationships. Here are our object rectangles so far:

A set of initial object rectangles.

We definitely can (and will) do more with our objects. However, sometimes if I’m trying to make sense of a poorly organized system, it’s enough, at least initially, to get the objects identified and laid out on a page.

I find the most logical next step, once I’ve identified the objects, is to identify the relationships between objects.

Relationship Between Objects

A UML Class Diagram uses various line notations to describe the relationships between objects.

Rather than rely on notation to characterize the relationship between objects, the Narrative Object Model uses descriptive text. The diagram below shows the objects we’ve identified thus far with their relationships described.

Narrative Object Model describing the relationships between objects.

The descriptions help illuminate the purpose of each object in context of the larger whole:

  • An Account can send a Direct Message
  • An Account can publish Tweets
  • Tweets can be curated into groups call Moments

Again you could stop your model at this point, after the relationships have been defined, if you feel the model serves your purpose. However, it can be helpful to fill in more information about each object…specifically its associated actions and attributes.

Identifying Actions

Actions (highlighted in yellow) identified using a Tweet’s button bar an menu.

In an object, the actions are listed in the bottom pane of the object rectangle, as shown below.

The object Tweet with its associated actions.

A stylistic note: I retain the traditional notation for actions in an object model, appending each action with parens. This notation is a preference on my part (completely unnecessary), but it does help visually distinguish actions, which can be helpful on larger, more complex object models.

Note also that I’ve added some actions that aren’t depicted in the screen capture of the Tweet, but are found elsewhere in the interface — for example, the ability to remove a Tweet from a Moment.

We’ll now fast-forward and assume that I’ve repeated identifying actions for our remaining objects. Here is what the model looks like at this point:

Narrative Object Model for Twitter showing the relationship between objects and each object’s actions.

Identifying Attributes

The object Tweet with attributes (middle pane) and actions (lower pane).

Here again, I’ve retained some notation from a Class Diagram. The colon after the attribute Text indicates the type of data — in this case, the fact that Text is limited in length (280 characters or less). I’ve only included data type for the Text attribute because I’ve deemed it to be especially meaningful to the user experience.

Building Out the Model

Narrative Object Model for Twitter

In addition to including more objects, I’ve added some visual elements to help me interpret the model more easily. These include:

  • Indicating which objects are the core system objects (in bold outline)
  • Using traditional UML line-end treatments to characterize relationships further
  • Using color to associate objects with a similar purpose

Indicating Core System Objects

For Twitter, I’ve indicated the Tweet and the Timeline objects as core, capitalizing the object name and using a bold outline treatment.

Indicating Specific Types of Object Relationships

The four main types of relationships are:

  • Association
  • Aggregation
  • Component
  • Inheritance

Association Relationship

An association relationship, indicated by a plain line.

Aggregation Relationship

An unfilled diamond notates an aggregation relationship.

An aggregation relationship, indicated by an unfilled diamond.

Component Relationship

A component relationship is notated by a filled-in diamond.

A component relationship, indicated by a filled-in diamond.

Inheritance Relationship

Our example model for Twitter isn’t showing any inheritance relationships. However, if I was building a full object model for Twitter, I might use inheritance to depict different types of accounts, for example, a User Account and an Administrator Account. These objects, which share a subset of characteristics, are best treated as children of an Account.

An inheritance relationship is shown using an unfilled arrow pointed at the parent object. The parent object contains the shared characteristics; only the unique characteristics are shown for the children.

An inheritance relationship, shown by an unfilled arrow.

Note, however, in this example Account isn’t an actual object in the system — it’s an abstraction we used to create a parent. Here again, we can use traditional Class Diagram notation to indicate the abstract object <<Account>>.

Though inheritance may seem a bit fussy to include in the model, it’s also one of the most useful relationships to understand. When designing, you want to make sure parent functions are presented consistently across all the children.

Indicating Objects with a Similar Purpose

  • Core Experience (blue)
  • Categorization & Discovery (green)
  • Account Management (orange)

A More Real World Model

Below is a more real-world model for an enterprise system. This model is based on an actual workflow management system, though some details have been changed for presentation here. You can see the more extensive use of inheritance, component, and aggregation relationships — and expanded use of the verbal descriptions to help “tell the structural story” of the system.

Narrative Object Model for an enterprise workflow management system.

Mastering Object Modeling

Tips for Creating a Model:

  • Start with the easy stuff — for example, just identifying some objects.
  • For larger systems, it may make sense to create two or more smaller models and then bring them together.
  • Build out the model over time, in a series of shorter work sessions.
  • Do just enough to serve your purpose; avoid analysis paralysis.
  • Two people may model the same system slightly differently, and that’s OK.

Using the Model

To begin, I want to emphasize that the Narrative Object Model provides a single, specific view of a system — a structural view. It’s not designed to replace other artifacts such as storyboards, journey maps, user stories, and use cases that represent the user experience from a task perspective. The object model is always a compliment to other design artifacts.

Let’s look at how the object model fits into the design process. The model can be used to identify:

  • A system’s signature elements
  • Objects that are similar either in purpose or function
  • What might be functionally incomplete
  • Controlled vocabulary terms

I also use the object model when doing screen-level design to make sure there is a clear relationship between an object and all its associated actions.

Identifying the System’s Signature Elements

Identifying Objects Similar in Function or Purpose

It’s also helpful to identify objects that have a similar purpose. In the previous section, we used color-coding to group objects into categories.

In the Twitter model, there are three object categories:

  • Core experience
  • Categorization & Discovery
  • Account Management

In the enterprise workflow system model, there are four categories:

  • System Users
  • Roles in a Transaction
  • Components of a Transaction
  • Work Management

Here again, it can make sense to design the objects within a category concurrently so that the experience feels consistent.

It’s also useful to look at cases of inheritance (parent-child relationships). You want to make sure parent functions are presented consistently across all the children.

Identifying What Might be Functionally Incomplete

A starting point is looking for CRUD actions (create, read, update, and delete). For example, Twitter famously doesn’t allow users to update a Tweet once it’s been posted. As I am modeling Twitter and checking that objects are complete, I would notice this omission. In this case, the lack of an update function is intentional, but it could also have been overlooked. In my experience overlooked basic functions are not uncommon.

It can also be helpful to look at objects that serve a similar function and compare them. For example, in Twitter, a Tweet and a Direct Message serve a similar function — to communicate with others. You can favorite a Tweet, but you can’t favorite a Direct Message. Should users be able to favorite a Direct Message as well?

Identifying Controlled Vocabulary Terms

One reason to more completely fill out the actions and attributes for each object rectangle is to do a thorough vocabulary cross-check. The model can ultimately serve as a source for a controlled system vocabulary.

In addition to checking vocabulary across objects, it’s also handy to review terms within an object. In Twitter, the word “Tweet” is used both as a noun and a verb. It’s evident that for Twitter this makes sense, but it could be a legitimate question to raise.

Keeping a Clear Relationship Between an Object and Its Associated Actions

Wrapping Up

For additional perspectives on object modeling for design, I invite you to explore these other resources:

Happy Object Modeling!

Principal UX Designer & Partner at Blink UX • iPad enthusiast • GTD practitioner • Crafting better enterprise experiences since 1988