Introduction

In the last Design Dive article, I reviewed a few items from my attendance of the Design & Content Conference in Vancouver, which, among other topics, covered conversational interfaces and developing chatbots. As a Convergence UI/UX designer, I want to unpack the rest of Sophia Prater’s discussion on how to develop an Object Oriented User Experience (OOUX).

Prater runs Rewired, a UX studio based in Atlanta, Georgia. She is known for pushing her OOUX process onto all of her web and mobile projects, and I’d like to share some of that here. I’d also like to give some examples and share how she might lay out an app with a few simple steps at the outset of a project.

What’s the point of OOUX?

The goal of OOUX is to make software interactions more intuitive. If we can lay out the app much like the way the mind is laid out, the app will feel more intuitive. Without this User Experience effort, your app may “function”, but users will be frustrated using it – and may be eager to hunt out competing platforms. Let’s look at some examples of sloppy User Experience.

Objects Example 1: iOS Volume

Say you’re an iPhone user on iOS 12, and you want to adjust the volume. Naturally, you use volume buttons on the left side of your phone. What happens on the onscreen volume indicator? Is it also moving up and down?

Right – it moves horizontally. In English we use the terms “turn it up” or “turn it down”, but here we have a problem: the design is actually decoupling the physical action from the digital visual feedback. Your mind can make it work, but there’s always a disconnect.

Someone at Apple spoke up, and now it looks like this in iOS 13:

This newest design is much more intuitive, partly because the physical objects match the language.

Objects Example 2: GoDaddy

GoDaddy has long been a leader in the domain retail space; however, by just picking up a few domains we can already see the inconsistencies in their design. The objects are not well defined. The mind subconsciously picks up on these differences and we may feel exhausted by them:

Observe these two different views of the same domain. In one view, it says that the domain expires on April 17, and in the other it says that the domain cancels on the same day – each label using a different colour. The language “expires on” and “cancels” likely refer to the same concept, but this is not clear. And what does the red colour mean? We don’t know. What about Privacy? What does ‘privacy’ here mean? Though we see the tooltip, it causes the design to look, feel and be inconsistent. That inconsistency irks the mind and makes the design feel incomplete and unintuitive.

Objects Example 3: Amazon

Amazon, despite flying high these days, does make mistakes in terms of Object Oriented User Experience. These are Amazon’s price card screenshots. This is how Amazon represents a product, depending on where the product is showing up.

Here we’ve highlighted all sorts of inconsistencies.

Look at the prices: they’re all different sizes and positions. Some of them are red, but it doesn’t mean the item is on sale. Moreover, even when there’s a 20% discount, you may not see any change in typography. It’s kind of a mess. Again, I know Amazon is doing well – the store works, but this kind of inconsistency is a recipe for confusion and frustration among users.

Where does Intuitive Design come from?

Intuitive design is often heralded as design so instinctual that you don’t have to think to use it. More often what it actually means is that it uses design patterns (a general, reusable solution to a commonly occurring problem in software) that you’ve already seen in social media, email and web browsers many times before, which makes things feel intuitive.

Is Slack similar to an email client? Not really, but the sidebar navigation reminds you of email, or of the oldschool iTunes. The sidebar gives you a familiar instinct when you see it in a new app.

Other than relying on classic software patterns, how else can we create an intuitive design? One answer is to employ OOUX at a basic level when mocking up an app; users should be able to easily answer the following questions.

The problem with the previous examples, particularly the ones from GoDaddy and Amazon, is that despite the popularity of these apps, it’s hard to identify what the objects are in each case. Let’s start with the first question at the top left: what are the objects?

Object-Oriented User Experience Process

The Object-Oriented User Experience process is there to identify and lay out these objects and how they relate to each other. OOUX is the practice of aligning your software to your user’s real-world mental model of concrete, defined objects. This is rooted in user-centered design and understanding how a user is thinking about these things and making sure that it matches up accordingly with the graphical representation.

Here is the OOUX Process that Prater employs to get all her projects ready. Once we define the objects, we can then define their relationships, capabilities and attributes. This will lay out the mobile UX, which will then lay out the desktop UX. The goal here is to best match how the users already see the world, and how they see your software. Then, we look to best fit their mental model.

Object Oriented App Design: Vegan Recipes Demo

Let’s run through some of these steps with an example app design, following Prater’s color map above. She holds out a hat filled with ‘objects’ and you pick out three: you get parents, recipes and plants. After a minute chatting with a partner you decide that this app will help you add/manage vegan recipes for your kids!

First thing we do is to lay out our objects as such:

Next, we define the objects’ relationships. This is an interesting way to think about who owns what. Parents own many plants, but the plants only have one owner, and so on. We’re doing this to build features and functionality between the objects.

The next step is to define capabilities users have with respect to objects. Parents can create themselves, follow other parents, and so forth. Next, we consider the direct object – that which is being acted on. We can start thinking about attributes that make up the objects.

Below is a simplified version of the object map, with objects listed in blue, the characteristics in yellow, and the functionality is highlighted in green.

Conclusion

What you see above is a simplified object map of the app. Prater typically uses either Trello or Whimsical to share it with clients. She typically does this three times (accept approval or add functionality, rework the map, etc) before she gets into the mobile UX sketches.

Once that’s approved, she can easily port that mobile UX to layout the desktop UX and more. Although OOUX feels like a lot of concept work up front, once it’s done, the actual app layout work really flies. Most importantly, you have object-oriented integrity, and users can feel it. The app makes sense and isn’t a clumsy mess that users are forced to sift through.

In conclusion, using tools like these help us to solve real problems – and to create the type of software that we love to deploy.