How to build a better product using Object-Oriented UX: Part Two

Welcome back, readers! If you’re just joining us, you might want to flip back to the first article in this series to get acquainted.

The Object-Oriented World

It’s safe to say that we designers all share a common goal: to build easy-to-use products. To be successful, we need to understand who our users are and how they think. Identifying who’s using the product has always been the easiest part for me, but now — I’m practically setting up a chaise longue to analyze brains and behaviors. I need to know their why. Step inside my office.

Rustle through the mental cobwebs and remember your first foreign language class (for me it was Spanish 1). You start with the alphabet. You learn to pronounce all the letters, making noises you never knew your throat could. Once you’ve got these basics down, it’s on to the nouns. Why is that? We can communicate using only nouns (and in my case, butcher far fewer verb conjugations) and still get our point across. Saying “airport” with a shrug will most likely yield the same results as asking where the airport is.

Back in Part One, we went through a few experiments to prove this. They showed that communication seems to be object-oriented. So, what happens if we start our designs there? As a team, identify objects and what these objects are made of to ensure that everyone is on the same page from day 1. By streamlining our understanding, we can communicate more easily to those less familiar with the product. This clear understanding serves as the basis for users to be successful before they start their interactions. Hello again, easy-to-use.

How to Start

Buckle in. It’s time to get to the meat of this process. Initially, you might guffaw at what I suggest, but I swear to you this is far easier and faster than trying to iterate on your designs. So, without further ado, allow me to introduce to you the ORCA process: Objects, Relationships, Calls to action, and Attributes. For each step along the way, we’ll focus on identifying a different piece of ORCA and determining how it relates to the others. Added bonuses for all you visual learners: each step comes with a special map/model to help define it.

STEP 1: OBJECTS

Ah, yes. The objects. Finally! Our first activity is locating yours. All of them. Don’t worry about consolidating or prioritizing, as we’ll get there a bit later. Initially, we just want to do a massive brain dump of all the objects in your product through an activity called noun foraging. Start your hunt by highlighting all the nouns you can find — the people, places, things, and content types. Look through your website, your product briefs, your project requirements — basically any content you can get your hands on will work here. This will tell us what things need representation in the system.

Once you’re finished, write all your nouns on blue stickies. I like using a Mural board for this because key commands are a gift, and my handwriting is decipherable by no one.

After you’ve collected your objects, group them into categories. Here’s what I came up with when browsing through athenahealth’s website. I’ve identified 4 main groups of similar objects and put a pin (literally) in some stickies to come back to.

Initially, I’d recommend shooting for between 3 and 5 objects, as things tend to get pretty wild with more than that. To get there, use this step to downgrade anything that could be supporting data, or data that describes an object, rather than being a top-level “primary” object itself. For example, in building an electronic health record (EHR) app, Patient and Appointment are absolutely necessary. However, I could downgrade a patient’s photo or address to supporting data (or metadata) associated with that patient. With an appointment, I could use time and location as supporting data instead of primary objects. More on this in step 4.

From there, write some examples of these objects on another color of stickies and post them directly underneath your main objects. I’m using yellow stickies for my examples of objects. These can be a mix of actual examples you gathered during noun foraging or brainstorming ideas for how you eventually want them displayed in your product.

Meet the object map (the start of one, at least):

STEP 2: RELATIONSHIPS

Next up, we’ll be thinking through how these objects relate to one another. Start out by assuming that there are 2-way relationships between all of your objects. To help visualize this, I suggest using a system model. A system model is a diagram that outlines flows between objects.

Using the 3 objects from my blue stickies above, I’d have:

• Appointment -> patient
• Patient -> appointment
• Claim -> patient
• Patient -> claim
• Claim -> appointment
• Appointment -> claim

Translation: An appointment has a patient. A patient has an appointment.

Here’s our system model so far:

However, a patient could have multiple appointments or a patient might not have any appointments. To account for these variations, we’ll want to include the number of elements, or cardinality, in our model. We’re not looking for explicit number estimates here — no need to clarify that your patient has 13 previous appointments. Instead, pull from this master list of options:

• Has 0–1
• Has 1
• Has 0-many
• Has 1-many

It helps me to read these out loud and swap in other verbs when I’m having trouble defogging the relationship. For example, a claim is billed to one patient, or a patient may be scheduled for 0 — many appointments.

After you’ve identified these relationships, write them on blue stickies building on your object map from step 1. Our first row represents the nouns we cannot live without, or host objects. The second row shows examples how these objects will be translated into the system. From there, the remaining rows include the relationships between our objects, or our nested objects, we’ve identified above.

However, in doing this, I’ve identified 3 new relationships we didn’t account for using our system model. These 3, shown inside dotted boxes, are how the objects relate to themselves.

I’ll admit this concept made zero sense to me initially, so let’s break this down. How can a patient relate to a patient? Think about a family, perhaps. Would a 2-year-old roll up to an appointment by himself? If he does, we are all in trouble, but knowing he will not, we’d need to know who’s answering medical questions on his behalf, what their relationship is, and whose insurance the child is covered under. That person is another patient in the system. That’s how a patient can relate to a patient.

STEP 3: CALLS TO ACTION

Our C is for calls to action. We’ll smoke out how people (or our system) will need to interact with your defined objects. This step makes sure you don’t overlook important actions needing to be connected to their objects. Imagine not being able to remove a song from a playlist just by using the song’s menu, and instead, you have to go to a separate playlist screen. It’s frustrating! And this problem can happen if a designer forgets to connect that “Remove” action to a “Song” object.

By creating a CTA matrix, we’ll have direct manipulation for all objects we’ve identified.

To do this CTA discovery, start by identifying your user roles. Don’t get caught up in personas. We don’t need to get to the granularity of Primary Care Physician level. No OBGYNs. No Oncologists. We can lump all 3 of these into one user role: Provider (as in a professional who provides healthcare, such as a doctor or nurse). Underneath each, add any actions a user might take for each object. Using green stickies, start by jotting down as many CTAs as you can think of. Later in the process, we’ll whittle out any lesser actions that may be reprioritized.

Here are some examples from our imaginary EHR app. I’ve identified 3 possible users: patient (tricky tricky!), provider, and admin/system. That’s right — even though I’ve identified patient as an object, I think there needs to be a patient user, too. Some starter actions include CRUD (create, read, update, delete) or at least parts of that process. Maybe you only want to archive instead of deleting.

STEP 4: ATTRIBUTES

Finally, we need to determine what our objects are made of. For this, we’ll be listing our attributes, which are divided between core content and metadata. If you’re having trouble fleshing this out, borrow from step 1 and forage for attributes using any documentation you might have.

What’s the difference between core content and metadata?

Core content is the meat of an object and what makes it unique. If we go back to Patient as an object, what are some fields needed to differentiate one patient from another? Fields that have unique values?

Here are some examples I’ve identified for a patient:

• Name
• Email
• Phone number

These are several pieces of core content and should be added in yellow to the object map.

Metadata, on the other hand, can describe multiple examples of an object. These are fields where the values are probably not unique. An easy way to think about this is fields that can be used for sorting or filtering. For example, category, status, and date are some typical filters you can find on sites. Normally, these have formatting and or taxonomy requirements — think of choosing a value from a dropdown list versus entering something in a free text field. Add any metadata in pink to your object map.

For our patient, I’ve added:

• Gender
• Ethnicity
• Has insurance (yes/no)

But wait — did we just identify a NEW object? Here, we’ve listed “Has insurance” as a yes or no question but surely, we need more information about what “insurance” is actually made of. Here we go again. Let’s add a blue sticky for a nested object underneath “Patient”. In the future, maybe this will become another host object which would be added to the top row. For now, let’s leave it where it is to limit our scope.

And that’s it! We’ve gone through each letter of ORCA, and the result is our object map.

What’s Coming Next?

Can you believe all the details we’ve already fleshed out — and we still haven’t touched a single wireframe. Now that we’ve got a serious jumpstart, let’s move on to what this looks like when put into real world practice. In my next article, I’ll walk through some more examples of how this theory and process translate into my everyday design life. Also, I’ll share how it’s being received by my team — the good and the bad.

Would you like to know more about OOUX? Check out OOUX.com for more resources.

Have you tried using an object map before? Do you have any lingering questions you need answers to? Let me know in the comments!

If you are interested in athenahealth, please reach out via LinkedIn. I’d love to have a conversation about the great work being done here in platform services and discuss open roles that might be a good fit.