Cookie Consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Cookie settings
Article

The Dawning of OOUX - CNN Election Results 2012: An Object-Oriented UX Case Study

This article is part of a series of case studies that follow my journey of practicing and refining my Object-Oriented UX process. In many ways this project is where my career as a designer of the design process really began. It was a project of many firsts: my first responsive design, my first time working very closely with the development team, and my first real system design.

Image Credit:

To get access to this guide, enter your email below. If you are not already part of our OOUX world, you'll be added to the weekly OOUX Newsletter. You can, of course, unsubscribe at any time! We will never sell, spam, our otherwise disrespect your information. And we strive to provide only top-notch valuable content in our newsletter.

No items found.
Find your player

This article is part of a series of case studies that follow my journey of practicing and refining my Object-Oriented UX process. Read the case study of the 2016 CNN Election Results here.

First, a bit of a disclaimer. I am telling this story as I remember it and as my previous accounts of the story have reminded me of it. I remember being pulled onto the project four days before development was kicking off, on a Thursday. Could it have been a Wednesday or Friday instead? Of course. I remember the 2008 design having 10 templates — but could it have been 9 or 11? Sure. So allow me a bit of creative license as I take you through this project as truthfully and authentically as possible. Thanks!

THE PROJECT

“I loved working with Sophia at CNN. The woman’s ideas are big, mold-breaking, boundary-ignoring ideas, the kind of ideas that are often not just “designs” but inventions.”

-John Hayes, lead developer on the CNN Elections Night Project

Even though I’d been working as a UX designer for about 3 years, in many ways this project is where my career as a designer of the design process really began. It was a project of many firsts: my first responsive design, my first time working very closely with the development team, and my first real system design. And what resulted is my first take on creating an Object-Oriented UX.

THE CONTEXT

I wanted the project to be a success more than anything, but I knew I’d need to break the rules to make it work. In my bones, I felt that the work that I would do over the next few months would be career-defining, but little did I know it would change the trajectory of my life.

It’s another hot Atlanta summer and I’m commuting to downtown via foot, bus, and train — happily. My office building, overlooking Centennial Olympic Park, is also a major tourist destination and the beacon of a worldwide brand name: CNN.

The CNN newsroom on election night 2012. A room of low-walled cubicles with people seated at desks in front of computer screens.
The CNN.com newsroom where I worked alongside journalists, photographers, editorial staff, and a team of talented designers. This is a deep cut from my Instagram, on election night of 2012. Remember the days of excessive filters?!

I’m early enough in my career that I still feel like I am playing “professional working woman,” so the commute (and complaining about it) just feels like an exciting part of living big-city life in the fast lane.

I’m one of three UX designers within the CNN digital design team. I was hired in 2011 to assist in an effort to create a fully responsive redesign of CNN.com. But in June of 2012, just a few months before the 2012 election when Barack Obama won for the second time, I was temporarily pulled off the main redesign project to lead the UX for election night.

At CNN, election night is a massive night for revenue. Circa 2012, CNN.com would expect around 200 million unique page views.

200 MILLION. That’s a lot of potential ad dollars. It was incredibly important that the experience worked well — on election night, most Americans would come to CNN first, but if the experience sucked or broke, they’d hop over to one of the competitors. All news outlets were getting the same data feed. It was just a question of how that data would be presented. So to hit our numbers, we’d need to keep people on the site.

This was not CNN.com’s first election night rodeo, but 2012 brought a twist to the project.

It would be responsive.

(Well, technically, it would be “adaptive” with three breakpoints, but since we don’t use that term much these days and the distinction is irrelevant for this story, I’ll continue to use the term responsive.)

Going responsive totally made sense strategically. We’d be dealing with massive amounts of data, and keeping that synced across devices — which was not a concern in 2008 — would be difficult across multiple codebases. One code base would ensure the integrity of the numbers as our viewers frantically refreshed screens on their laptops, tablets, and phones.

But from a project management and timeline perspective, going responsive was an incredible risk. No one on the team had experience with responsive design (this was 2012, after all) and we were up against a tight timeline that was NOT going to budge for another round of quality assurance. For just a little perspective, the site-wide responsive redesign of CNN.com did not launch until the beginning of 2015 — nearly three years later. We were also planning to launch a complex data visualization as a responsive experience in just a few months. And failure would be catastrophic — to the business and potentially to my career.

THE GAME PLAN

Like I said, it was June 2012 and CNN.com/election/2012/results was going to launch on November 7th no matter what. (No, the URL is no longer available. Don’t even try that URL on WaybackMachine.com — I already did. But I do have screenshots coming up!)

The Thursday before the first sprint’s Monday kickoff, I was brought onto the project.

You might think that I should have been flattered to be selected to take on the UX of this high-profile challenge! But in reality, having a UX designer on the project at all was a last-minute afterthought.

The original plan was simple. Project management has referenced the non-responsive election night screens from 2008 and built a sprint schedule based on those 10 screens. The original plan was to take an existing 2008 screen, “responsify it” in development over the course of a sprint, and then move on to the next screen.

A few days before the first sprint, one of the managers on the design team caught wind and made a case for adding a UX designer to the mix. That UX designer would take the screen that development was about to start on and clean it up a bit — “responsify it” from a design perspective before the developers got ahold of it.

And, goodness, did they pick the wrong lady for that job.

MY JOB

The project manager sat me down and explained to me that development would be starting on Monday — “I know, I know, that’s not a whole lot of lead time, BUT DON’T WORRY.”

She reassured me, “We only need one screen on Monday — the state detail screen, you know like the template for the Georgia, California, or Ohio landing page. We will need a wireframe for mobile, tablet, and desktop versions, but it’s just that one template. And then you will have two weeks to design the next screen!”

And, this is when my brain broke.

In the past, I’d been asked to design a cog in a machine without thinking about the whole machine. And I’d complied. But, even though I knew very little about responsive design, I knew in my heart of hearts that I needed to build a system.

I knew that churning out wireframes assembly-line style and slapping on a main navigation to link everything together was not going to result in a good experience. The voice of my grandfather, a chemical-nuclear engineer, rang in my head:

“The more moving parts, the more likely it is to break.”

At the risk of sounding overly dramatic, what happened next was the beginning of my rebellion against myopic, fractured UX and the beginning of OOUX.

WHAT I DID

First, I dove into research.

Did I interview users on how they felt about elections? Did I gain insight into what they expected to see on the site, their motivations, and their fears?

Did I conduct interviews with stakeholders to find out what success meant to them?

HELL NO!

I had four days, including the weekend! For me, research meant desk research. I analyzed our past election experiences, those of our competitors, and read up on the American election process on Wikipedia. I also had a thick requirements document written by the lead politics editor, which I printed, read, and highlighted like crazy. I dug for answers to questions like:

  • How does the electoral college work?
  • How do districts relate to counties and representative races?
  • How many states are having a gubernatorial (governor) election this year?
  • Do any races have more than four candidates?
  • What are the main parts and concepts represented in our past election night experiences and those of our competitors?

I started piecing together the reality of elections before thinking about the screens that would represent them. I came up with questions for that first kickoff meeting, questions like…

  • What if there are 12 candidates in a race? Do we show them all?
  • What makes a battleground state? What content are we providing about battleground states?
  • What stages can a race’s results be in? No data? Percent votes in? Projected winner…?

No one told me to do this research and ask these questions. I don’t know if anyone expected me to. After all, couldn’t I just look at the screens from four years ago and gussy them up to be responsive? Sure, I could have followed directions. But if I had, I honestly believe the project would have failed.

On Monday, I did not present three views of the state detail page as I was instructed. Instead I presented a very low fidelity diagram of a completely new structure — a design with only four main templates and just four main components that could be reused over and over. This simplified design still met all the requirements and didn’t cut any corners delivering the data.

An 8.5x11" piece of paper with screen wireframes printed on it, redlined with edits in red ink.
Here is what I presented as my first deliverable. All the main screens that would be needed, diagramed on one 8.5x11 sheet of paper.

Without knowing what one was, I’d created my first system model or “entity relationship diagram.” And I remember thinking — this will be a part of my process until the end of time.

I’d printed out about a dozen copies of the diagram: an array of low-fidelity screens and repeated components. I did not print the arrows that showed how a user would move from screen to screen.

I was incredibly nervous as I handed out the diagrams — which were obviously NOT state detail templates. I had thrown the “ask” out of the window and instead did what I thought should be done. In retrospect, I am still pretty impressed with my younger, fiery-self. Try this at your own risk. I remember saying things like:

“Just hear me out”

“Hang on, this will all make sense”

“Just give me a few minutes to explain”

I brought the group of stakeholders through the main screens: the state detail (California, Georgia), the race detail (President, Senate, House, etc), and the state-race detail (California Senate, Georgia Gubernatorial, etc). And then, together, we drew the arrows. They saw how the reusable components became the navigation. How the state icon on a results card would bring the user to the state detail page, and how a balance-of-power graphic would link to the race detail.

A diagram showing that a results card is made up of a state, a race, and the summary results data.
Here’s a post-project diagram that shows a cleaned-up version of what I presented to the room. A results card is made up of a state, a race, and the summary results data. And wherever a results card showed up, it would provide navigation deeper into the granular data, but also “up” to a state overview and a race overview.

As the group drew the lines with me, lightbulbs went off and I began to breathe again.

Fortunately, I was working with a smart team of people who saw the benefit of a simplified structure. Even though I had set back the schedule for that week (no high-fidelity state detail templates), I’d cut the total number of screens in half. The team agreed to rearrange the sprint schedule based on this new design. Green light.

I wish I had more artifacts for you, to show you more of the process. I can’t seem to dig up any of my old prototypes and UI sketches. But I saved the most important part. That first diagram described a system of objects and nested objects, contextual navigation, and repeatable components — and it paved the way for how I would continue to practice, and eventually teach, UX.

CONCLUSION

Remember when I said that if I hadn’t defied the directions, I believe the project would have failed? Here’s why.

Even with a greatly simplified system, we barely pulled it off. We worked weekends and nights and the QA team was testing and finding bugs the weekend before election night. Responsive design meant that every screen had to be tested and tweaked for multiple devices — so much more could (and did) go wrong as opposed to designing and developing with a fixed 960 grid. If we’d stuck with the original design and attempted to layer on the complexity of responsive design, I don’t think we could have hit that immovable deadline.

But election night was a success for CNN, and for me. The system I designed was in no way perfect. But it worked. We retained our audience and we hit our numbers. Other than the Associated Press, CNN was the only news outlet with a responsive election night.

Here’s what CNN.com’s Election Center looked like after President Obama won a second term.

A screenshot of the CNN election results webpage from election night 2012.
Screenshot of election results from November 8th, 2012. From top to bottom: Presidential election summary graphic; a United States map showing state-level results for the presidential election, senate races, house races, and governor races; state-level presidential results for key battleground states; state-level key senate race results.

The system consisted of hundreds of pages, but each page followed one of the four templates and was made up of four main components.

The four main components, clockwise from the upper left: balance-of-power election race graphics, state-race results card, exit poll graphic, map graphic.
The four main components, clockwise from the upper left: balance-of-power race graphics, state-race results card, exit poll graphic, map graphic.

Granted, a ton of rules, logic, interaction, and edge-case handling went into each of these components and templates. But that came later, as we iterated on the fidelity of the system. First, with a foundation of that simple working system, illustrated on a single sheet of printer paper, the team could layer on the detailed complexity with confidence.

I will say it again: the system I designed was in no way perfect. In fact, looking back on it, I can see that I broke one of my cardinal design rules — completely arbitrary shapeshifting. We had two versions of the state-race results card: a map-view fly-out card and a list-view card. Can you see all the arbitrary shifting of data and display between these two cards?

The map-view fly out and list-view card for the Ohio presidential results. The display and position of metadata like estimated percent in, the timestamp, and electoral votes changes — for no reason at all! This shapeshifting introduced extraneous complexity: for the designer, the developer, and most egregiously — the end user!
The map-view fly out and list-view card for the Ohio presidential results. The display and position of metadata like estimated percent in, the timestamp, and electoral votes changes — for no reason at all! This shapeshifting introduced extraneous complexity: for the designer, the developer, and most egregiously — the end user!

In addition to shapeshifting, there was also some weirdness with the persistent navigation. I was so enamored with my new friend Contextual Navigation, I didn’t spend enough time thinking about how the persistent navigation would work. And that map fly-out interaction was a little finicky on mobile.

I learned so much from the project by living it, but the real learnings came a year later. Jesse James Garrett, the organizer of the prestigious Adaptive Path UX conference, UX Week, wanted speakers to present responsive design case studies. As another testament to the success of the design, he reached out to our CNN.com’s design director Marisa Gallagher and asked her to speak at the conference about it. And Marisa turned around and graciously handed that speaking opportunity to me.

Crafting that talk required deep retrospection. And it was in that reflection, leveraging my 20/20 hindsight, that the realization came: the principles that emerged through the crucible of responsive design are not just principles for responsive design. We should have been working this way all along.

If you want to hear more details about my biggest takeaways from the project that became the seeds of the OOUX philosophy and everything that I teach today, check out my first big conference talk: The Simplicity Imperative.

In preparation for writing this case study, I rewatched this talk that I gave eight years ago and I am happy to say that I still agree with everything I said back then! If you decide to watch this blast from the past, I recommend 1.25x speed. Apparently, when I am very nervous, I talk super slow. I honestly sound a little drugged in this talk. But the content is spot-on!

Sophia on stage at UX Week 2013, showing off CNN designs
Me on stage at UX Week, showing off CNN designs. Watch the talk to hear my five principles for simplicity.

As a final word, here is how I really know that the design was a success. Three years after leaving CNN, I was asked to return to the newsroom as a consultant and lead the UX for the 2016 election results. That story can be read here.

Episode Transcript

Subscribe to OOUX Podcast

A dive into the weeds on UX systems, information architecture, human psychology, data wrangling, structured content, UX process, and above all simplifying the complex.

Join OOUX Happy Hour Meetup

OOUX virtual meetups feature amazing guest speakers, Q&A, discussion, networking breakout sessions, and important OOUX updates. Bring your coffee, wine, or whiskey.

Related Resources

No items found.
See all resources

Spotlighted Resources

The OOUX Launch Guide
The OOUX Launch Guide
Sophia V. Prater

In this FREE guide, get the inside scoop on the creation story behind OOUX, learn the most critical activities in the object-oriented framework, and guide you to the best resources for learning the foundations of OOUX. You'll get the rocket fuel you need to go from 0 to 60 in just a few hours.

get it
Open in new tab
get it
UI Breakfast Podcast. Episode 229: Object-Oriented UX with Sophia Prater
UI Breakfast Podcast. Episode 229: Object-Oriented UX with Sophia Prater
Sophia V. Prater

Sophia was interviewed on the UI Breakfast Podcast. How can object-oriented UX help designers solve complex product problems? You’ll learn why object-oriented thinking is well-suited for design processes, how a shared vocabulary enables collaboration, practical mapping tips, and more.

listen
Open in new tab
listen
Search all resources