How to Build a Better Product Using Object-Oriented UX: Part Three

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

A Quick Recap

I’ve spent the past month or so working through the bones of the Object-Oriented UX process. Once we established the theory behind it and looked at some supporting evidence, it was time to get to work.

• In Step 1: Objects, we “noun foraged” documentation. We identified all of the objects our product needs and we grouped similar entities.
• For Step 2: Relationships, we examined how our objects are related to one another and determined the cardinality of each relationship.
• Next up, in Step 3: Calls to Action, we thought through potential user roles and what actions users would need to take on each object.
• Finally, in Step 4: Attributes, we fleshed out what our objects are made of, producing a gorgeous object map.

Now that I’ve gone through some basics of OOUX, let’s step into the real world and explore an actual example from my work at athenahealth.

A Practical Example

So, I’ve established that I work in healthcare. Back in Part 2, I worked with a very simple example to get everyone acquainted with the basics. Let’s discuss what I’m actually building.

At athena, our approach to healthcare revolves around an ecosystem. We know there isn’t a “one size fits all” medical charting approach that will work for all healthcare providers, across all specialties, across all states in the USA. To solve for these huge variations, we have the equivalent of an app store — allowing those providers to customize their little hearts out. We know we can’t build everything in-house, so we partner with external companies to list their apps and offer the ultimate customization experience. Once downloaded, these apps interact with athena data and show up embedded within athena’s own apps.

What’s my role in this? I’m trying to make it easy for those external companies to contribute. This covers everything from the how-to documentation to the onboarding experience. Onboarding is essentially the Wild West of design and here is no exception. There’s a suite of products a developer can take advantage of to build the best app. This means our onboarding process not only needs to be transparent and easy to follow but also be flexible enough to support different types of onboarding for different products (head exploding emoji). Talk about a puzzle.

I’ve been hinting at some objects that might be included in my work, but I haven’t shown you the official goods yet. Allow me to present my real object map.

Here are some basic definitions of the objects in my map:

1. Console

• The onboarding website I’m building for developers
• Where the magic of building/updating a product will take place

2. Apps

• The “thing” the developer is building to solve an existing need in healthcare
• For example, an online scheduling widget that allows patients to register for an appointment

3. Interfaces

• An integration that allows 2 software systems to communicate
• Similar to an API

4. Organization

• The company a developer works for

5. Marketplace

• Applications shown on the athena “app store”
• Each app will have it’s own listing page — like something you’d see on Google Play

6. APIs

• A connect between 2 programs that allows them to talk to one another
• Added to applications

Now what? How do I translate these into an onboarding website framework?

Transforming Objects into Designs

Up until this point, I still haven’t opened Figma, spending my time working out specs. Now is where the fun starts (for me at least). Once I’ve fleshed out all the details around what objects my product is made up of, it’s time to start designing.

Picking up where I left off with my object map I started in Article 2, it’s time to ruthlessly prioritize it, placing the stickies in order of importance. This will help determine where objects should fall on the page.

Here’s my original object map and what these sticky colors mean:

• Objects are listed in blue
• Core content is yellow
• Metadata (used for filtering) is shown in pink
• CTAs are green

Now let’s prioritize these stickies.

1. I’ll keep the first core content sticky at the top. It will become the official name of the API on the website.
2. I’m going to eliminate a big chunk of related objects, as I don’t think they’ll add any additional clarity onscreen.
3. I’ll move the CTA to the top of the list. Since the purpose of the console is to enable products, I think the add functionality is the most important piece here.
4. Next, I’ll keep all relevant metadata lumped together. These 3 stickies are related to each other and need to appear together on the screen.

Here’s the difference between my original API object and my new one with prioritized stickies:

It’s with this step I’m able to finally start visualizing some of the details for our objects. I’m picturing how to present these options/this information on a page, so I want “Add API” to be more visually prominent than anything like “See reference docs”. The higher the object is on the list, the more important the item is in the UI. We can achieve this a few different ways, whether it’s through placement, color, or size. Once I’m finished prioritizing, I’ll decide just that.

With attributes and CTAs prioritized, it’s time to design a few different views at a mobile screen resolution. I do this to begin with the most simplified version of a page and work up to the more complicated, full-screen web sizes. Specifically, I’ll begin with one of the most common elements — a card. Cards show up repeatedly over most sites and applications, including in search results and list views. I’ll use the card to signify one of my objects and copy the most important stickies onto it. It becomes the initial design for the detailed view of an object.

I’m starting small, with a mini card. It’s recommended to use no more than 3 details from the object map. Using my API example, here’s what I came up with for my mini card:

I’ve taken my top 3 stickies:

1. The system example core content (which I’ll start referring to as “Name” for ease),
2. The “add API” CTA
3. The metadata “certified/standard”

I swear I didn’t cheat and take the top 4! I think the certified and standard metadata will always need to be displayed together, so I’m pairing them as a single element. I’ve applied a few design elements including using font size to denote importance and stylizing “Add API” to look more like a button. I’m not sure how I’ll end up showing the certified/standard details, but I can figure that out once I move into a higher fidelity.

Next, I’ll move to a grid card. This view works best with no more than 5 details. Using the mini card as my base, I’ll start with the original 3 details, copied over exactly as they were from the mini card. Doing this ensures the same information pattern, making it easy for users to understand quickly.

Then, I’ll add 2 more of my prioritized details. With the extra space, I’ll include a description. Descriptions are core content and may vary in length. I left plenty of space to accommodate these variations, but I will make a note to come back later if I need to specify any overflow rules if the character count ends up out of control. The final attribute I’ll add is the “0-m related APIs” object. I wasn’t sure how to interpret this visually initially. Normally, I’d suggest not making visual changes to objects between card types, since it increases cognitive load and development time. With the size constraints of the cards, though, I don’t think I have the space to list out several related APIs. Instead, I decided on a more simplistic version — a “View Similar” CTA.

My final card will be the table row card. No rules for how many attributes to include, but it’s recommended to keep the details in the same order. For me, I think I can keep the same layout as my mini card and simply expand it into a row.

If I repeat this card design practice for each object, I’ll make a huge chunk of progress in the wireframe department.

Once my 3 card views are complete, I’ll move on to a sketching a details page. Using my card views as a base, I’ll transfer all of my details into a lo-fi design. Since I already have the items prioritized, I’ll want to keep them in order of importance, whether that’s by using the position on the screen or by sizing. I ended with 8 attributes for APIs, so my details page is fairly simple:

Once I’m finished with my card views and my details page, I’ll repeat this process for the other objects in my map. Afterwards, I’ll translate the mobile designs into web views.

A Site Map on Steroids

The final step of our OOUX process is here. The later I get in my career, the more complex the problems and products become. With this used to come site maps you’d need a magnifying glass to read. Look at this one:

…and it’s not even complete. It’s the base for all documentation — with the second set of pages is repeated 9 separate times. Imagine how much harder to read/follow it would be if I had included all 9 instances. And if your stakeholder is unfamiliar with how site maps are structured? It’s simply not going to resonate, in my opinion. I’m shocked I was able to find any traction with this overwhelming amount of information. However, once I introduced a different type of flow to my product team, their verbatim reaction was, “This makes so much more sense.”

What is this mythical design? It’s called a Navigation Flow — a graphic that shows the interactions and flows between the objects.

For this, my prioritized objects become my top navigation: Console, Applications (Apps), Organizations (Orgs), Marketplace, APIs, and Interfaces. I’ll represent these with different colored boxes for each object. I’ll assume that each navigation item links to a page containing a list of these objects, so I’ll draw a line using the corresponding color to said list page.

Next, I’ll start to visualize what these list pages may look like. I already have a rough idea from the card designs, so I’ll build on those in low fidelity. With a rough layout of my objects, I can start visualizing and drawing the connections between them.

Let’s look at my Apps list page in pink. Here, I know a few things:

• Developers always need a way to add applications to athena’s console.
• A user is likely to have multiple applications.
• Applications can be at different stages in the build process, resulting in different details for each.
• A finished application will usually have a set of APIs associated with it and a Marketplace listing.

Using pink to signify an application, grey for APIs, and yellow for a Marketplace listing, I end up with a color-coded wireframe. A very rough wireframe, but still a very solid starting point.

On these list pages, a click on each item will most likely navigate to a details page. I’ll account for this by drawing a third level on my new, OOUXy site map. Again, this details page is meant to start visualizing connections, so I don’t need to be exact. Here’s a closer look at my object details pages:

Now that I’ve drawn the different detail levels of objects, it’s time to account for how they relate to one another. Using my relationship matrix, I’ll draw colored lines showing the existing connections. I’ll do this for both the list levels and detail levels.

Here’s how my final Navigation Flow ended up:

At the end of this process, I’ve connected all of my objects. None of them are left isolated. And I have a diagram based on an actual mental model of how the real-world works. I trace my happy path of navigation through these relationships while detailing additional paths a user might take.

Since I’ve started using this process as part of my work, I’ve found countless, time-saving benefits. Here’s what my developer users and athena’s end users get of this OOUX work:

• The end result of my work is a really well-planned product for external developers.
• The developers are then better equipped to create useful and effective apps for the athena ecosystem.
• These apps fulfill the needs of healthcare workers and help them do their jobs more efficiently,

With some careful planning early in the process, my team and I can improve things for a lot of people!

OOUX in the Real World

Now we’re at the end of our little OOUX journey! We talked about the importance of defining objects using the ORCA steps to make sure we didn’t miss anything, we ruthlessly consolidated and prioritized, and finally we made it to sketching — designing several different views for each object.

…and that’s not even everything there is to OOUX! There is so much more to this process I haven’t shared with you (I can’t reveal all the secrets). I cannot say enough good things about how this course is impacting my daily work. Before touching a design, we’ve established a common understanding about what each object is and how all of them interact with one another. Not only am I saving time which used to be spent reworking mocks, I’m also generating assets that immediately resonate with product and business stakeholders. Hallelujah!

Ready to join the party and bring OOUX into your work? Check out OOUX.com for certification resources.

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.