Flipping the Object Map and More OOUX Adventures in Ed-tech

Classbloom: An Object-Oriented UX Case Study

Sophia V Prater
18 min readDec 21, 2021

THE PROJECT

Classworks is a decades-old ed-tech company based in the Atlanta suburbs. Out of a spacious office atop a Trader Joes, overlooking vast parking lots mitigated by tasteful landscaping, the Classworks team builds software for teachers.

Mostly former educators themselves, they work to alleviate one of the biggest problems in primary education: classrooms jumbled with students at widely-varying skill levels. Classworks helps teachers with “response to intervention” (RTI); in other words, Classworks helps identify the specific knowledge gaps of struggling students and provides customized content to fill those gaps. Students usually plug into Classworks during “tech time” or sometimes during recess if they are dangerously behind.

Around 2015 Classworks introduced a new content set for live “front of the classroom” instruction. Teachers are on the hook, teaching to specific government-issued standards designed to ensure students are learning the same stuff in the same grades across the country. There’s controversy around Common Core standards, but the idea is sound: a common curriculum should help teachers keep kids on track in a world where parents are relocating them more and more. For instance, a fourth grader who moves from Montana to Georgia will transition more smoothly if they are not behind in division.

With the addition of the new “teacher-led” content, Classworks started to notice their user experience buckle under the strain of the additional features. They were introducing new complexity: standards-based lessons would come equipped with practice problems geared toward various skill levels. For example, the same problem would appear on students’ tablets, but each kid would see a version of that problem appropriate to their skill-level. The question and the answer would be the same across the classroom, but a more advanced student wouldn’t see the hints and they’d have to draw their own diagram. Another student might receive hints and the scaffolding of a diagram.

To make sure teachers were leveraging the various types of valuable content effectively, they started to consider a ground-up redesign of their platform. And for the first time, to stand out against increasingly tough competition, they’d invested heavily in UX.

THE CONTEXT

In early 2015, I spoke at a development conference about Object-Oriented UX while Classwork’s CTO listened intently in the audience. After the talk, Jerry Henley introduced himself and told me he wanted his whole team to hear everything I’d just said. Jerry explained some of the challenges at his company and we exchanged contact information. I left the talk thinking, “I might have just scored a totally different kind of client.”

At the time, I was doing UX solely for Atlanta startups. I’d built a reputation as a no-nonsense, fast, developer-friendly UXer within the startup community. My days were usually split hopping between clients at ATDC (Atlanta Technology Development Center) and ATV (Atlanta Tech Village), the two biggest incubators in the city. My niche was working with dev-heavy startup teams — not OOUX.

OOUX was still in its infancy — I hadn’t published my first OOUX article and I hadn’t started running “formal” OOUX workshops with clients. A light version of OOUX was a part of every project, but it wasn’t what my clients were specifically hiring me for. However, that was about to change.

Classworks was no ragtag group of developers scrambling to get out a beta product. This was a well-established, mid-sized company made up of ex-teachers, trainers, and sales folks. They had a legacy system and a legacy database. And most of all, Jerry wasn’t hiring me for UX. He was hiring me for OOUX.

THE GAME PLAN

Classworks wanted teachers to thrive using their existing and new content, but their product had not been redesigned in over 10 years and, like most edtech software, it was sorely dated. It no longer met the expectations of millennial teachers who wanted a clean, mobile-friendly user experience.

In future interviews with teachers, I’d find out that teachers loved Classworks, but only after they’d been using it for about a year. At first, after a school or a district bought the software — and mandated usage — teachers would need intense training (hours and hours of unpaid time). So in the beginning, teachers resisted the new software. It would take months for them to start seeing the benefits. And most of that frustration was a direct result of bad UX.

The original game plan was a full, ground-up redesign of their flagship product, Classworks. We’d integrate new features while also giving the existing system a total overhaul.

A few months into the project, after my research started coming in and the leadership team and I started getting into the weeds on UX strategy, the team started exploring the idea of creating a separate product for the “teacher-led” feature-set. Instead of redesigning the legacy product, we’d leave Classworks alone and introduce a sister product: Classbloom.

The sales team loved the idea — these products could be sold separately or together. The developers also loved it — no untangling 20-year old legacy code riddled with technical debt.

In retrospect, I know this was a good decision. But I remember pushing back at the time, disappointed with the zoomed-in scope. I desperately wanted to redesign the whole thing!

It’s important to ask questions and push back on business agendas if they seem completely at odds with the UX. But, it’s also important to know what you don’t know and respect the expertise of other professionals on your team. Back then, I knew nothing about educational software sales and the challenges of their legacy system. But as I learned more, I began to appreciate this decision.

Part of maturing as a UX designer is realizing how product design strategy has to work within technical constraints, timelines, and business opportunities. This was a humbling lesson I had to learn multiple times in my career — scope changes and business pivots are inevitable.

THE WORK AND THE LESSONS

My role on the project started small. I was to help them clearly define their goals and use those goals to run an OOUX workshop with the leadership. But one thing led to another and this project led to an engagement that lasted over three years.

In short, we did it all — user interviews, information architecture, strategy, ethnographic research, brand identity, detailed UI, art direction. And OOUX provided a principled backbone for all these activities.

What follows is not a step by step process of this immense project. Instead, I’ll walk you through the four main lessons I learned from this project — lessons that continue to influence OOUX today. I’ll take you through a major innovation to the object map, new thinking when it came to object relationships, my first struggle with “tree system” inheritance, and exploring complex object-permutations. Strap in and stay with me!

Flipping the Object Map

Before we jumped into an OOUX Workshop, I needed to wrap my head around this complex ed-tech domain and we needed a clear set of goals.

I started with some initial desk research (like less than 10 hours) just to prepare myself to swim in the ed-tech waters. I watched product tutorials, skimmed ed-tech blogs, and lurked in teacher discussion boards. I started listing potential objects and articulating questions about them.

With enough lingo and context to ensure I wouldn’t waste my clients time with stupid questions (and yes, there are stupid questions — those with answers on Google’s first page of results), I conducted a basic UX strategy and discovery workshop. Like many companies, Classworks didn’t have an existing company vision or product goals neatly articulated and documented — it was all locked in the beautiful minds of the leadership team.

A whiteboard with pink and blue sticky notes on it. The words “Steroids for teachers” and “simple tools to free-up your nights and weekends” and “classworks simplifies, streamlines, and extends teaching/instruction” are written on the board in blue dry erase ink.
One of the many whiteboard and sticky-note-explosions from our initial goal-setting. The main theme that came through? Steroids for teachers.

With some refining, we had a few simple vision statements and a list of product goals.

WHAT we want to accomplish: Help teachers do more, with less busy work. Empower teachers to make more informed teaching decisions while also making their lives a little easier. Get more kids to graduation day by providing personalized, effective, engaging remediation. Create future generations of smarter, more prepared, better-educated American adults. Product Goals (HOW we will do it. Extract objects from here) Allow teachers to easily browse, search, explore.
A screenshot of the document used to drive the first object-mapping session.

With this document, we could point our OOUX work in the right direction.

During our object-mapping session, we had A-list participants: the president of the company, the CTO, the marketing executive, an account executive, and 2–3 lead developers. After a bit of OOUX-basic-training, I split the group into two cross-functional teams and sent them to separate rooms.

Both groups had the list of vision statements and product goals to work from. I instructed them to extract objects from the product goals section; a company vision is important to keep top-of-mind, but it’s usually too high-level and abstract to use for gathering potential objects (what OOUXers now lovingly call “noun-foraging”).

Over the course of the afternoon, I popped back and forth from room to room and coached the two groups through the breaking-down of objects into attributes, mapping the relationships between them, and logging the potential actions users could take.

Team 1’s object map. Objects are blue, listed down the y-axis to the far left. Core content is yellow, metadata is pink, and nested objects are blue. Calls-to-action are green.
Team 1’s object map. Objects are blue, listed down the y-axis to the far left. Core content is yellow, metadata is pink, and nested objects are blue. Calls-to-action are green.
Team 2’s object map. Objects are blue, listed down the y-axis to the far left. Core content is yellow, metadata is pink, and nested objects are blue. Calls-to-action are green. Slightly different objects and structure.
Team 2’s object map. Same color-coding, but slightly different objects and structure.

If you know about how object maps are arranged today (if not, download this handy Object Mapping Guide), you’ll see something odd about these object maps. Yup, they are horizontal! During the first year of object-mapping, we’d orient our maps to be read from left to right. It was actually during this project that I realized stacking attributes vertically made more sense. When we rotate an object map to list attributes in columns instead of rows, each object’s column illustrates a mobile-first low-fidelity detail page for that object!

After the workshop, I took pictures, and in the most organized way possible, stacked the sticky notes into tidy piles so I could analyze them. My next task was to find the commonalities between the object maps — and the differences. The spots where the object maps disagreed highlighted areas where we needed more clarity and more conversation.

While digitizing the object maps in Axure (my tool of choice in 2015), I also interpreted them and combined them into a single “recommended” object map. I read between the lines and layered on my own ideas. And using Axure’s annotation tool, I captured all of my questions, such as: “Is a CLASS preserved year after year?” and “can we list the STANDARDS that a CLASS needs to learn based on subject and grade?”

Note: I emphasize objects with an all-caps treatment.

The digitized object map, now in vertical orientation. Objects in blue squares across the top, core content in yellow, metadata in pink, calls-to-action in green are all cascading down underneath the object squares.
The digitized object map, now in vertical orientation.

After sheepishly explaining the re-orientation of the object map to my client team (if I remember correctly, the smart people of Classworks didn’t skip a beat), we started reviewing the questions. This process took…weeks of working sessions. Every question answered seemed to spawn three more questions. The object map laid bare all the complexity behind what we were trying to build, and now, we had to contend with it.

Notice that I used the term “working sessions” instead of “meetings”. By moving sticky notes around in our object map, we were collaboratively designing a new solution. A single question in an object map could lead to an hour of white-boarding and debate. We were also gathering requirements and questions for future user interviews. We’d leave these sessions exhausted — and sometimes more confused than when we started.

The intensity that object mapping precipitates benefits from proper framing — framing that I didn’t have back then. I knew I needed to get clear on these questions before I began wire-framing, but some days, morale got low. Untangling all that complexity was critical to making sure our design was well-structured, but it was overwhelming. I was nervous that my clients were wondering if we were going down too many rabbit holes and when or if they’d ever start seeing some wireframes. But to their credit, they stayed patient and engaged as I continued asking hard questions.

Today, I make sure to positively frame this uncomfortable and difficult complexity-exposing process. I remind myself and my clients that every gnarly problem we solve now is like diffusing a ticking time bomb that would have inevitably blown up weeks of design work later. Even identifying the problem is a reason to celebrate!

This early work not only helps us prevent expensive, late-in-the-game gotchas. Grinding through these difficult conversations improves collaboration. For Classworks, as we clarified our language around LESSONS, UNITS, ASSIGNMENTS, JOURNEYS, and PATHS, we were learning to communicate more effectively, accelerating our process in the long run.

Navigation through content, to define the content

Before I joined the world of ed-tech, my main argument for building navigation based on object relationships was practical. On a mobile device, where the persistent navigation is usually hidden behind a “hamburger menu,” I want the content to become the navigation. This helps users navigate in fewer clicks.

For example, if a teacher is looking at a CLASS Detail Page with a list of STUDENTS, I want to present navigation to each of those students. Clicking or tapping a STUDENT card should lead the user to the STUDENT detail page. And conversely, on that STUDENT detail page, the teacher should see a list of CLASSES and have the ability to navigate to a CLASS detail page.

This seems obvious, yet this UX best practice is often…not practiced, leading to what I call Isolated Objects. In fact, in the existing Classworks, the CLASS detail page does not even show students enrolled in the class, much less provide navigation to them.

A screen shot of the classworks software showing Assignment, Change status, Quiz Average, Activities remaining, total time, mode, percent mastery, date assigned. A speech bubble is superimposed over the screen shot that says “Why can’t I see the students in my class?”
The above legacy CLASS detail page shows a list of ASSIGNMENTS applied to that CLASS, but not a list of STUDENTS in the class. One of the number one comments we’d get from users about this screen was “Why can’t I see the students in my class?”

The Classworks leadership gave me unprecedented research time and budget. Never before had I been given the luxury of truly getting into the heads of my user-base. I was allowed to sit in on classes, training sessions, and interview teachers.

As I learned about a teachers’ work day, I started to glimpse teachers’ mental model of their professional world. There is truth to the educational system they live and breathe — there are things and the connections between those things that exist outside of any software.

Connecting objects in context is not just about providing easy navigation, it’s about reflecting a user’s mental model and improving understandability.

Before we determine that a CLASS detail page should display a list of STUDENTS, we have to know the inalienable fact that a CLASS has many STUDENTS and a STUDENT has 1 to many CLASSES (depending on the grade of the STUDENT).

A cartoon image of a classroom seen from above is in a circle. A smiling cartoon girl (student) with glasses is in another circle. There an arrow pointing from each circle to the other one that is captioned: “Has 1-many.” So a student has 1-many classes. A class has 1-many students.
A CLASS has many STUDENTS. A STUDENT has 1 to many CLASSES. This is deeply ingrained in the mental model of a teacher and if their software does not reflect this truth, the software will be, without a doubt, less intuitive.

The relationship between CLASSES and STUDENTS is obvious. But what about the less obvious relationships? Like how a LESSON and a POST and ATTACHMENTS relate to each other?

Seems like I SHOULD be able to attach lessons to posts — this is basically finding it, queuing it & starting it all in one fell swoop. But attachment on lessons gums this up a bit. Your attachments would have attachments! Comment: mtg 12/17 — No. We will have 2 different types of posts, per whiteboard sketches. Regular posts are teacher-initiated & can contain any attachments EXCEPT lessons.
Screenshot of one of our many “Weekly Notes” Google Docs where we kept a log of questions and decisions.

So many of those grueling-but-insanely-productive working sessions revolved around figuring out how our objects should relate to each other. Often there is no clear right answer. Like in this case, there are pros and cons for allowing a POST to have LESSONS as attachments.

Sometimes, analyzing the relationship between two objects results in a new object that is needed to connect the original two! For example, How might Classworks provide recommended LESSONS for a specific CLASS, based on what that CLASS is struggling with?

To build that important connection, we had to read between the lines. One theme that kept coming up in my conversations with Classworks leadership and our users was “filling gaps.” I’d hear statements like:

“We need to identify a student’s gaps.”

“A student will often have several gaps in their knowledge.”

“I want to teach to the gaps that my class is struggling with the most.”

First, we had to confirm if a “gap” was even an object! It sure sounds like it, right? But after hours of rolling this concept around, we determined that a “gap” is simply a STANDARD that a student does not grasp. Instead of making “gap” another object, adding more complexity, we realized we could make “gap” a potential state of the STANDARD object. STUDENT has 0 to many STANDARDS with the state of “gap”. (Don’t worry, we will get into object states soon.)

In the legacy Classworks, standard codes were unstructured metadata on the LESSON. Upgrading STANDARD to an object allowed us to give it various states and connect LESSONS to STANDARDS and STANDARDS to STUDENTS…thus connecting STUDENTS to LESSONS that were most relevant to them! (Read that twice.)

In addition, by rolling up information about STUDENT’s STANDARDs, we could potentially show how an entire CLASS was doing on each standard. A teacher could see that a majority of the CLASS was struggling with a STANDARD and then find a LESSON to teach the whole CLASS.

A system model made up of grey circles with objects in them such as “class,” “standard,” “master lesson,” etcetera. There are blue arrows going between them that show the relationships between each object such as “student” has “1 or 2” “journey.”
An early system model that upgraded STANDARD to an object, making the system more powerful and useful.
3 high-fidelity mobile prototype screens. the STANDARD (with the green, orange, and yellow icons) played a major role in how a user could see how CLASSES and STUDENTS were progressing and what LESSONS would be best to assign. From left to right: the STANDARDS tab on a CLASS, STANDARDS listed on a LESSON detail screen, and the STANDARDS tab on a STUDENT profile.
Later on in high-fidelity prototyping, the STANDARD (with the green, orange, and yellow icons) played a major role in how a user could see how CLASSES and STUDENTS were progressing and what LESSONS would be best to assign. From left to right: the STANDARDS tab on a CLASS, STANDARDS listed on a LESSON detail screen, and the STANDARDS tab on a STUDENT profile.

This figuring-out is not design innovation. This is simply understanding the truth of the real world and making sure the software reflects and supports that truth. But all too often, designers jump straight into the screen design without first understanding the real world objects it represents. Defining objects and their connections is a power-tool for understanding.

Then, once you gain understanding, you can bake that understanding straight into the design, reflecting exactly how a user would expect the screens to work together. So, maybe that is innovation?

A special flavor of inheritance

In our first round of object identification, LESSON bubbled up as a main player. In the beginning, I modeled the system with just STUDENT, LESSON, STANDARD, CLASS, and POST as our objects.

But I ran into trouble when I tried to add metadata like class average grade and student grade to the LESSON. A LESSON would actually have many student grades, depending on the number of STUDENTS that took the LESSON!

And the more I thought about it, a LESSON didn’t have just one class average grade either. A teacher might teach the same LESSON to three CLASSES. One CLASS might do better than another.

I’d diligently shove notes into my object map to explain all of this complexity. But things just got messier and messier. What about the due date? That will also depend on the CLASS?

I was trying to cram all of this complexity under the umbrella of LESSON. It took me a few weeks, but eventually, I realized that the LESSON object actually needed to be split into three objects:

CORE LESSON: a lesson template used across schools and districts.

CLASS-LESSON: a CORE LESSON applied to a CLASS by a teacher.

STUDENT-LESSON: a CLASS-LESSON applied to a STUDENT.

These three objects were closely-related. Yet they were not only different from a technical perspective, but they were different in the teachers’ mental model. As the object map evolved in fidelity, I split up the LESSON object into these three levels of specificity: from district-wide, to class-level, to student-specific.

A wireframe-object map hybrid. Three levels of the LESSON object. I misuse the term instance. Today I am much more careful to use “instance” only when describing the real-content manifestations that are churned out by objects. An instance is a record, a row in the database, a tangible example of an object. In contrast, what I am calling here a “Class-Lesson Instance” and “Class-Lesson-Student Instance” are not instances at all, but objects themselves that have their own instances.
A sort of wireframe-object map hybrid. Note the three levels of the LESSON object. Also note my misuse of the term “instance!” Today I am much more careful to use “instance” only when describing the real-content manifestations that are churned out by objects. An instance is a record, a row in the database, a tangible example of an object. In contrast, what I am calling here a “Class-Lesson Instance” and “Class-Lesson-Student Instance” are not instances at all, but objects themselves that have their own instances! Instances of the “Class-Lesson” OBJECT might be “Mrs. Prater’s Period B lesson on How Rainbows form”.

Back in 2015, I was just beginning to recognize this general-to-specific inheritance pattern. On future projects it would come up again and again, and each time I would recognize it with a little less time and struggle.

After much discussion with developer friends, I couldn’t find a name for this particular pattern. It was a kind of parent-child relationship for sure, but it was different from an ARTICLE with its child COMMENTS or a COMPANY with its child DEPARTMENTS.

Eventually, during Cohort 1 of the OOUX Certification Program, the OOUX community came up with a name for this pattern: a “tree system.” It came as no surprise that having a name for this makes it easier to identify and handle — this is a core tenet of the OOUX philosophy!

The tree is a good metaphor. The most “general” object can be thought of as the “root” of the system, from whence the “branch” objects sprout. Finally, you have “fruit” objects, which are usually the things that the users actually consume. It’s not until a LESSON gets to the STUDENT-level that answers are actually added to the questions!

Today, tree systems are still one of the stickiest inheritance patterns for new OOUXers to grasp — and it doesn’t help that junction objects often show up within tree systems! Stay tuned for a full-fledged article on tree systems, but until then, here is a simplified object map breaking down the LESSON tree system.

From left to right: The [CORE] LESSON is the root object and contains the questions and answer key, subject, and grade level. The CLASS LESSON branch object referenced the [CORE] LESSON, but now it is joined with a CLASS object. It’s given a due date and a class average score. Finally, the fruit object, the STUDENT LESSON, references a CLASS LESSON and it is joined by a STUDENT object. The STUDENT LESSON is what contains the student’s answers and a teacher’s feedback MESSAGES.
From left to right: The [CORE] LESSON is the root object and contains the questions and answer key, subject, and grade level. The CLASS LESSON branch object referenced the [CORE] LESSON, but now it is joined with a CLASS object. It’s given a due date and a class average score. Finally, the fruit object, the STUDENT LESSON, references a CLASS LESSON and it is joined by a STUDENT object. The STUDENT LESSON is what contains the student’s answers and a teacher’s feedback MESSAGES.

Why is it important to distinguish tree systems from other kinds of inheritance? There are two main reasons.

  1. We need to explore and define how data funnels down the tree system. STUDENT LESSONS can be averaged to provide a class average score on a CLASS LESSON, and even a district average score for the [CORE] LESSON. Do district administrators want to see that high-level information? How might it be segmented? Can I see averages over time?
  2. We need to explore and define how changes at the root object propagate up to the branches and fruits. What happens when an admin adds a new question to a [CORE] LESSON? Does that new question pop up on completed STUDENT LESSONS, rendering them incomplete? Maybe not, but what about in-progress STUDENT LESSONS? And, whatever the answer, how does this change affect our average scores?!

Tree systems introduce all sorts of questions about data integrity over time which was a massive concern for Classworks. Learning to recognize this pattern has served me well, time and time again!

(In a future case study, I’ll talk about my work with a property management software company. Recognizing on day 1 that the INSPECTION object was actually a tree system of four objects earned me immediate respect with the developers and the business.)

Object states

The main purpose of our project is to help deliver Classworks’ great content to teachers and in turn, help them deliver it to their STUDENTS. But, to do that, teachers need to select the right content. Then, they need to track the completion of that content and how STUDENTS are doing with that content.

Thus, instances of CLASS LESSONS, STUDENT LESSONS, QUESTIONS, and STANDARDS had several multivariate states. For example, an instance of a STUDENT LESSON could be completed but failed. Or not started and past due date. Or in-progress and past due date. To further complicate things, all this data on STUDENT LESSON instances would affect the state of the CLASS LESSON parent instance!

The team and I spent a ton of time white-boarding solutions on how to clearly represent all of these potential permutations.

3 pictures of whiteboard notes. The notes are messy and written in green, pink, and purple dry erase ink. The largest picture shows “in progress,” “turned in,” and “complete,” labels at the top with diagrams underneath them representing status with a rudimentary “traffic-light” style design.
Whiteboard scribbles in an attempt to untangle the complexity of object permutations by exploring UI.

In 2015, when faced with complexity like this, I still fell back to sketching UI. Before we’d even figured out all of the logic, I was thinking about a fancy “traffic light” UI, color-coding, and icons. With my OOUX-transformation still incomplete, I even attempted to add low-fidelity UI to my object map, desperately trying to parse out all of these permutations.

A zoomed-in look at my attempt to bake-in “status/state” to this object-map-wireframe diagram. The diagram shows “queued,” “in progress,” and “complete.”
A zoomed-in look at my attempt to bake-in “status/state” to this object-map-wireframe diagram.

I slowly learned that this logic was too complex to shove into an object map. Figuring it out through screen-sketching was not effective either. I was multitasking: designing UI and trying to understand business logic at the same time. I’d need an exploded view of all the states based on these variables of time, performance, manual overrides, and due dates.

One of many conditional logic diagrams that helped us explore, understand, and agree on how a STUDENT’s answer-data would flow. The diagram consists of lots of colored circles that represent students, lessons, etcetera. There is a pie chart showing how much of the whole each color represents: grey, pink, yellow, lime green, neon green.
One of many conditional logic diagrams that helped us explore, understand, and agree on how a STUDENT’s answer-data would flow.

This diagram focused on the intricacies of only a few bits of metadata: the potential values of “status” across three objects. It was one of many diagrams used to show my thinking visually so that the leadership team could have something to mark-up and rearrange.

Every project is different. The more complex a project is, the more we have to get creative with our diagrams! OOUX artifacts like an object map can’t do it all, but they do provide a solid foundation for exploring conditional logic and object states. I can’t imagine being able to get into this kind of metadata-level thinking without first working out the basics in an object map!

CONCLUSION

Classworks is still my longest running client project to date. Today, most of my projects are short-term engagements — but through the deep experiences with gloriously complex projects like this one, I’ve trained my eye to spot the gnarly knots of complexity quickly.

Before this project, I’d never thought about object relationships, inheritance, or conditional logic in such detail — but that’s not to say I shouldn’t have. I can think of many projects earlier in my career where these tools would have saved me so much time and helped me create better outcomes.

Looking back on this project with Classworks, it’s clear that thinking about macro-data (objects) sets me up to think about the micro-data (metadata) with more nuance. Collaborating on an object map is critical to my process — but it’s just the beginning.

An object map provides a stable foundation for more advanced — and strategic — problem-solving.

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: YOU ARE HERE!

2016: CNN Election Results

2017: Georgia Tech Research Institute

--

--

Sophia V Prater

UX designer, OOUX Instructor, and Chief Evangelist for Object-Oriented UX | Download the OOUX Launch Guide! OOUX.com/resources/launchguide