{"id":3747,"date":"2016-10-13T14:57:23","date_gmt":"2016-10-13T13:57:23","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=3747"},"modified":"2020-11-05T15:18:40","modified_gmt":"2020-11-05T15:18:40","slug":"ooux","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/ooux\/","title":{"rendered":"Object-Oriented UX"},"content":{"rendered":"

In June 2012, while working at CNN.com, I was tasked with designing the user experience of election night. The next five months of my life would be dedicated to that single night\u2014but success to me had nothing to do with who won. I was concerned with findability, data visualization, a shape-shifting canvas, and how the hell mouse-over flyouts were going to work on an iPhone. For the first time in history, CNN.com was releasing a responsive experience. And, for the first time in history, I was going to design a responsive experience.<\/p>\n

The stakes were high. Election night is like Super Bowl Sunday for CNN.com. If well executed, it\u2019s one of the highest revenue nights in a four-year cycle. To add to the pressure, we were on a tight timeline with a deadline that was not going to budge. November 6th or bust.<\/p>\n

Then I learned that the first development sprint kicked off in four days. Four days?! My project manager calmly told me, \u201cDon\u2019t worry. The devs only need one template for the first sprint. While they are building the first template, you can move on to the next.\u201d<\/p>\n

<\/div>
<\/svg><\/div>

\"Huh? How was I supposed to design a cog in a machine without first roughing out the design of the machine?\"<\/p><\/span><\/blockquote>\n

Thinking myopically worked okay when we were designing in pages on fixed screen sizes; we could get away with quilting together pieces designed in silos. I was pretty clueless about responsive design, but I did know that we\u2019d need a clean and simple system, not pages strung together. And as all engineers and designers know, the more moving parts in a system, the more opportunities for disaster.<\/p>\n

So during those first four days, I did not wireframe one disconnected template. Instead, I blocked out a holistic system made of reusable, interchangeable parts. Here\u2019s what it looked like:<\/p>\n

\"proposed-election-night\"

The diagram of the proposed election night experience I first presented to the CNN.com team.<\/p><\/div>\n

I presented this diagram to a conference room of stakeholders who expected to review a single \u201cfinished\u201d template. I demonstrated that I had reduced the number of components and templates compared to our 2008 design, and that the new system was simple enough to fit on one 8.5 \u00d7 11 sheet of paper! Thankfully, a critical mass of people in the room saw the value of what I presented: less stuff to build.<\/p>\n

The diagram I churned out in 2012 was far from perfect, mostly in that I was trying to do too much too soon. I jumped the gun on implementation, blocking out flyouts and bar graphs. I was still thinking desktop-first, worrying about positioning<\/em>, as opposed to prioritization<\/em>. I packed in a premature homepage, a cover sheet for the experience (which I would now design last<\/em>). I took a stab at persistent top-level navigation, instead of focusing on the content modules first.<\/p>\n

Although imperfect, the spirit of the diagram, and the thinking behind it, hit a chord with me. It wasn\u2019t a sitemap; it showed no hierarchy. It wasn\u2019t a storyboard; it didn\u2019t block out a task flow. Instead, this diagram mapped out a system of things. And it changed the way I do UX.<\/p>\n

Stripping away interaction, persistent navigation, homepage, and layout, here\u2019s the diagram that I would have created then if I knew what I know now, showing a system of three objects: States<\/a>, Races<\/a>, and State-Race Results<\/a>.<\/p>\n

\"election-night-sketch-if-designed-today\"

How I\u2019d present the election night experience if I were designing it today.<\/p><\/div>\n

It worked: our responsive election night turned out to be the Super Bowl Sunday CNN executives hoped for. But we did it by the skin of our teeth, working late nights and weekends to make sure the design performed on a myriad of devices. I\u2019m not sure we could have pulled it off with a design any more complex.<\/p>\n

Today, I\u2019ve evolved this trial-by-fire experience into a proven, structured object-based process. In this article, I will introduce object-oriented UX, share my process of object mapping, and help you start doing it yourself.<\/p>\n

Mobile first, content first, and objects first<\/h2>\n

\"Always separate thinking about real-world things from the documents which describe those things. Resource before representation.\" - Mike Atherton<\/a><\/span><\/em><\/p>\n

It took me about about a year to retrain myself to truly think mobile first<\/a>, but today, I do so even when designing desktop-only software applications. To me, mobile first simply means forced prioritization. It means think about layout later. Start with a single column \u201cdesign\u201d (also known as a list), and force yourself to prioritize content and functionality with sequential ranking.<\/p>\n

This approach dovetails nicely with the concept of content first: \u201ccontent-out design\u201d as opposed to \u201ccanvas-in\u201d design<\/a>. You have to know what you\u2019re saying before you can prioritize it.<\/p>\n

Sometimes, this means having real-deal copy first\u2014particularly when you\u2019re working on a site with a critical mass of evergreen or instructional copy that can be organized, prioritized, analyzed, and updated before design work begins.<\/p>\n

But if you are working on a site that is 99 percent instantiated<\/em> objects (news articles, products, campaigns, donations), there\u2019s no way to build a complete copy deck up front\u2014or ever. Instead of prioritizing actual copy, I have to think in objects.<\/p>\n

That\u2019s OOUX: putting object design before procedural action design, and thinking about a system through the lens of the real-world objects in a user\u2019s mental model (products, tutorials, locations), not digital-world actions (search, filter, compare, check out). We determine the actions after first defining the objects, as opposed to the traditional actions-first process that jumps straight into flows, interactions, and features.<\/p>\n

OOUX is powerful<\/h2>\n

Newsflash! This is how your backend engineers work. In the \u201980s, the software engineering community began to transition from procedural languages to object-oriented languages, which have benefits like code reuse, data encapsulation, and easier software maintenance. Most programmers bring your designs to life using object-oriented languages like Java, Ruby, Python, C++ or C#.<\/p>\n

Engineers start their process by mapping out the objects that make up the problem domain\u2014something UXers should be doing from day one. When they look at your wireframes or prototypes, they first reverse-engineer your design to parse out the objects. They think, \u201cHow will object X talk to object Y? Will object A be made up of lots of object Bs<\/em>? Which attributes will each object have? Will this class of objects inherit from that class of objects?\u201d<\/p>\n

On the web, we develop object-orientedly, but still design procedurally, focusing on drill-down hierarchy or linear task flows. But there\u2019s another option. In his 1995 book, Designing Object Oriented User Interfaces<\/a>, designer and engineer Dave Collins argues that basing both front-end and backend design on object-oriented principles \u201cbrings coherence to the software development process. Object-orientation reveals deep structural correspondences between the artifacts of analysis, design, and implementation.\u201d<\/p>\n

<\/div>
<\/svg><\/div>

\"Defining objects that mimic the mental model of your users provides a scaffolding for team communication.\"<\/p><\/span><\/blockquote>\n

It gives you a shared language. On top of team cohesion, designing object-orientedly can also help you:<\/p>\n