Flipping the Object Map and More OOUX Adventures in Ed-tech
Classbloom: An Object-Oriented UX Case Study
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.
With some refining, we had a few simple vision statements and a list of product goals.
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.
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.
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.
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).
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?
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.
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.
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.
Why is it important to distinguish tree systems from other kinds of inheritance? There are two main reasons.
- 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?
- 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.
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.
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.
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.
2015: YOU ARE HERE!
