Undercover OOUX: Seven Tricks to Sneak in Object-Oriented UX

Georgia Tech Research Institute: An OOUX Case Study

It was the perfect project for an OOUX case study. Unfortunately, the client wanted nothing to do with OOUX. Or me.

After killing it with my victory lap of OOUXing CNN’s 2016 Election Results, I was feeling very confident. I knew I was on to something big with Object-Oriented UX and I wouldn’t tolerate projects done the “wrong” way ever again! #Hairflip

But — a girl’s gotta eat. During this particular project, I not only learned to check my pride, but I also learned that my process doesn’t have to be perfectly executed to be effective.

Any OOUX is better than no OOUX.

In this article, I’ll tell you this story of OOUX resistance and the seven ways we snuck it in.

THE PROJECT

At the end of 2016, the digital agency CoolBlue was tasked with a full redesign and redevelopment of Georgia Tech Research Institute’s website. CoolBlue brought me in as the UX brass: my assignment was to get an object map in place, then build a prototype from that approved wireframe. The team at CoolBlue would support me in the UX, handle client relations, and then build the site in Drupal. And it all had to happen in something like four months.

GTRI’s existing website was over eight years old and a mess of dated content and drill-down navigation.

An internal page on the existing GTRI website. Check out all of that persistent navigation!

The existing site was rife with one-off “snowflake” pages, dead-end pages void of contextual navigation, and completely un-templatized content. I couldn’t wait to OOUX the hell out of it.

THE CONTEXT

CoolBlue was the first agency to adopt OOUX into their process. The founder Bo Simmons and his technical lead Angie Lane had participated in some of my earliest workshops. They became enthusiastic fans and brought me into their office to train their team. By the time we were kicking off work for GTRI, we’d already had success applying OOUX to another client of theirs. We worked well together. We liked each other.

On top of all of these good signs, Georgia Tech is my alma mater! Doing a project for one of their departments just felt SO RIGHT. What could go wrong?

Well.

With a tight timeline and a group of very busy stakeholders, we needed to get through that pesky phase of research, discovery, and information architecture as quickly as possible. Yes, like so many projects, it became clear that we’d be in a rush to wireframes.

I didn’t see how to shoehorn my glorious OOUX process in this tight spot. I was frustrated. I thought I’d said goodbye to projects like this!

During the first client meeting, things went pretty sideways. I don’t remember the specifics, but most likely I came on strong with my evangelical belief in OOUX and made it obvious that I thought they were doing everything wrong.

After the meeting, I sent Bo a…candid email. I’m sharing it here with you, verbatim, because I want you to know: I now cringe at my lack of flexibility.

As you probably could tell, I am a little concerned with the fact that the client has not been ramped up to my process. I don’t exactly know how to move forward without at least a half-day collab session with them. Otherwise, it will be total guesswork. And I just don’t do that anymore.

Removing the collaborative object identification/mapping is not the right place to cut corners. If we cannot get user input OR the client input on objects and their relationships/structures, I don’t think that this project is going to be a good fit for me.

BIG apologies if any frustration showed through yesterday. I just don’t feel like we were using the client’s time or our time wisely and I got impatient. Sorry again if that showed through too much.

Let me know how you’d like to go forward. Ideally, I’d have at least 3 hours with the right people locked in a room: the stakeholders, the director, and the business development guys.

Let’s do this right!

Sophia

If you are new to OOUX, you might have similar thoughts — that the process is all or nothing. I sure did, obvi. But, after Bo and Angie talked me down from the ledge, we carried on. We applied “OOUX-lite” behind-the-scenes — to surprising success. And the client? What they didn’t know didn’t hurt them. In fact, it actively helped them.

How to OOUX without direct stakeholder — or user — input

GTRI, The Georgia Tech Research Institute, was not incredibly interested in gathering user research for their website redesign. (No, the irony was not lost on me.) Talking to users was off the table. And after my arrogant kerfuffle with the stakeholders, talking to them was off the table, too.

If you’ve been in this isolated situation, hopefully for reasons less embarrassing than mine, you know how hopeless it can feel. But here’s some ways that we got to the right objects and built an object map that gracefully translated into solid wireframes that required little revision.

Here’s how a little guerilla OOUXing can help your UX designs sail through client approval and usability testing — saving you so much time in the long run.

1) In lieu of access to stakeholders, access their artifacts

Put on your detective hat. Gather as much stakeholder-created material as you can. Use documents, whiteboard sketches, spreadsheets, and diagrams as sources to extract potential objects. (In OOUX parlance, we call this noun-foraging. Look for those nouns that get used over and over again!)

Here’s a few resources you should try and track down:

1. If it exists, the original RFP (Request for Proposal)
2. Vision documents: initial emails outlining goals, hopes, and dreams for the project
3. Spreadsheets that attempt to organize the content
4. Stakeholder “design” documents: sketches, hacked-together site maps

A note on that last one: sometimes we loath inheriting design attempts from stakeholders. But a good UX designer can read between the chicken-scratch and glean useful information. Most stakeholders don’t expect their attempts at screens and information architecture to be written in stone. But if you use their powerpoint wireframes as an input (and make sure they know how helpful they were), your design will be more inline with the business needs and your stakeholders will likely be more receptive to your designs.

A few snippets of useful artifacts I inherited from the client team. (To be accurate, that site map is Bo’s cleaned up version of a stakeholders whiteboard sketch.) Per OOUX color-coding, potential objects are marked in blue boxes, core content in yellow boxes, and metadata in pink boxes.

Using just these three artifacts above, I can start seeing that MISSION AREAS and LABS are incredibly important objects. And I can see that they are related to each other. Both objects have location metadata (with values of cities).

I’ve also got a short list of specific questions for the next time I get a chance to ask them:

1. What’s a directorate? A person?
2. What does IRC stand for? Is this a type of location?
3. What information do we need to show about buildings?

Sure, I still always push for a series of thorough stakeholder interviews followed by at least a half-day OOUX workshop with all the important decision-makers. But if I don’t get exactly what I want, I can still do good work by channeling resourcefulness, humility, and my OOUX foraging skills.

2) In lieu of access to users, access their artifacts

It’s always disappointing when budget for user research is cut. But the good news is — users are modern humans and modern humans create a significant digital paper trail. You can analyze this paper trail with an eye for ORCA (objects, relationships, calls-to-action, and attributes) — just like you did with the stakeholders’ artifacts.

Here are a few things to look for:

1. Customer service chat logs (or, even better, the opportunity to interview customer service representatives)
2. Analytics to see what pages are the most popular on a site
3. Search logs on a site to see what users are searching for.

Bo got ahold of #3 and passed that information along to me.

When looking at search logs, you’ll probably need to back into potential objects by looking for instances of objects and asking, “what is this an instance of?” People don’t search “Labs”, they search for the particular lab that they are looking for.

For example, here are some of the most common search terms we found on GTRI’s website:

UAV

ATAS

SEAL

ICL

ESD

EOSL

These are all instances of LABS. Obviously, LABS turned out to be one of the most important objects in our system.

3) Send busy stakeholders true-or-false questions

Simply ask stakeholders very specific questions and make those questions easy to answer. My weapon of choice for this? Clearly writing everything I am unsure about as a statement and asking, “True or false?” You can do this in an email (as I did below), or you can create a survey and send it out to all of your stakeholders.

A screenshot from an actual email. I sent these questions and Bo got the client to answer them for me. Not ideal, but effective.

Sending a survey has the advantage of allowing you to gather several answers and easily identify where they might conflict. For example, on statement #4, most stakeholders say “true” but the director says “false.” Ruh, roh. We need to have a conversation about that, and sooner rather than later.

4) Translate artifacts into a format that speaks your stakeholders’ love language

Before getting into object mapping, I really really like to get 80–90% sure of what the objects are. On this project, I got pretty far along by using the methods outlined above. Following my usual process, I put all the potential objects on cards with definitions and cute icons.

A consolidated list of potential objects with questions in the comments.

Usually, these would be printed and used for a collaborative card sort. Which…was not really GTRI’s style. To my continued disappointment, we worked on these definitions internally. Then Ava, a member of the Cool Blue team, sent the client a very official looking document for approval.

A stroke of genius! Put the object definitions on an official-looking memo.

Looking back, I see Cool Blue’s savviness. They knew their client and they knew that bubbly, illustrated cards wouldn’t be taken seriously enough. These clients were steeped in the world of grant-writing, government contracts, and white papers. We needed to meet them where they were.

Today, we have the Object Guide, a much more robust version of the object glossary (template). Depending on the project and the stakeholders, an Object Guide might be the first design artifact a client sees. If needed, give it a new name and format to evoke the gravitas it deserves! At the end of the day, you are trying to ensure you agree on what the important concepts are and what to call them.

5) Internally review your Object Map

Even if your stakeholders are not ready to collaborate over color-coded columns of data-organization bliss, hopefully at least a few people on your team can take a look. Even though the GTRI folks never saw the Object Map, the folks at CoolBlue definitely helped iterate on it — especially those who would be developing the new site in Drupal!

An early object map with Bo’s feedback scribbled atop it.

I was using Axure at the time for digital Object Maps. You can’t see it here, but I heavily leveraged the annotations feature in Axure to capture questions and internal discussions.

See if you can run your Object Map drafts by a business analyst, a developer, or another designer. Your reviews will generate confidence in some areas and additional questions in others. That awareness — what you know and what you don’t know — will be key when it comes to asking specific and intelligent questions during the slivers of time you get with your stakeholders.

Through these conversations, carve out the truth of the system as best as possible. You might have to move forward into wire framing with some of those questions. Keep them organized and carry them over to your screen design as annotations so they are in-line and ready for that first wireframe review.

6) Start with super low-fidelity wireframes

If you have a design system at your fingertips and mad Figma skills, it’s easy to go straight to high-fidelity. But if a certain amount of guesswork is going into your designs, there’s a good chance you’ll be reworking them after the review.

To clarify, I mean low visual fidelity. I also mean low interaction design fidelity. If you are using OOUX-style sketching (download templates here), you’ll translate your objects’ Object Map columns into cards, details, and lists. You’ll place your calls-to-action strategically, but you won’t design all the interaction behind those CTAs. Your focus in those initial wireframes should be confirming the following:

• Are my objects right?
• Are the objects connected in a way that makes sense to the business, the users, and the developers?
• Are we missing any relationships and contextual navigation?
• Are the CTAs correct? Are these the interaction triggers that we need for each object?
• Are the objects’ attributes giving all the information users need?
• Are we missing any attributes?
• Are these attributes prioritized correctly?

Use that first round (and perhaps second and third round) of wireframes as a vehicle for getting these questions answered — as well as any other outstanding questions. For GTRI, my first wireframes were just a tiny step above an Object Map. A low-fidelity, mobile version of your system is practically an Object Map — columns of data arranged by object.

My first wireframes were created in about two hours. They were static, color-coded the OOUX way, and built to be ripped apart.

Whatever you do — don’t concern yourself with layout early on! Get the mobile “non-layout” version of your system approved before expanding into the world of desktop layouts. What I will often see is UXers going into a review for a single screen, say the Project Detail Screen, with the mobile version, the tablet version, and the desktop version. The desktop version of the Project Detail Screen gets approved before the mobile version of the Profile Screen is even explored.

I designed almost all of the screens in a mobile layout before moving to desktop screens.

Try to get as many mobile screens approved as possible before tackling the layout decisions that come with a wider X-axis. If your system will never see the light of day on a mobile device, I still encourage you to stay in the “one-column” layout for as long as possible. Call them “hierarchy diagrams” if that helps!

7) Give OOUX-y feedback on the visual design

If at all possible, communicate to your visual designers the principles of OOUX and how they can avoid shapeshifters, masked objects, isolated objects, and broken objects. (Check out this mini-workshop for a full exploration on these four common UX mistakes.)

Our visual designer, the talented Elliott Strauss, was well-versed in OOUX principles. That helped a ton. But when it comes to making sure objects are consistent and recognizable — the more eyes the better.

I gave lots of feedback on the use of white space to help group objects, avoiding arbitrary inconsistencies, and differentiating objects.

If your visual designer is not cognizant of the OOUXy thinking that went into your wireframes (how you carefully ordered the attributes based on prioritization…how you designed that card to look different than that other one because it represents a different object…), they might assume that those decisions were arbitrary.

A ton of good OOUX work can unravel in visual design. So, communicate, educate, and help visual designers understand how to avoid unintuitive object design.

CONCLUSION

Today, GTRI.gatech.edu is looking a little visually broken. The navigation and header images are no longer rendering full-bleed, and there are some wonky broken hover states.

But, the information architecture seems to have served them well over the last five years. It’s still identical to how I designed it in 2017 and the site is still clear and navigable. The content has scaled — new instances of articles, people, and initiatives are added constantly — without weighing down the website. It’s still an elegant site that surfaces what’s important.

Looking back on the website, I definitely see some shapeshifters and masked objects! Back in 2017, I was only just starting to hone my eye for those pesky creatures. Can you find them? Let me know in the comments!

In summary, a little undercover OOUX can go a long way. Here’s what you can do.

1) In lieu of access to stakeholders, access their artifacts

2) In lieu of access to users, access their artifacts

3) Send busy stakeholders true-or-false quizzes

4) Translate artifacts into a format that speaks your stakeholders’ love language

5) Internally review your Object Map

6) Start with super low-fidelity wireframes

7) Give OOUX-y feedback on the visual design

Push for the workshops, do your best to sell the whole process, but take what you can get. And let me know how it goes!

This article is part of a series of case studies that follow my journey of practicing and refining my Object-Oriented UX process.

2012: CNN Election Results

2015: Classbloom

2016: CNN Election Results

2017: YOU ARE HERE!