Object-Oriented UX (OOUX) with Sophia Prater

Introduction [00:49]

Thomas Betts: Hello and welcome to the InfoQ Podcast. I'm Thomas Betts, and today I'm talking with Sophia Prater about Object-Oriented UX. We'll be talking about how OOUX framework helps digital product designers create naturally intuitive user experiences. And since I like to say that every software problem is fundamentally a communication problem, I'm also interested in how OOUX can improve communication among designers, product owners, engineers and architects. So Sophia, welcome to the InfoQ Podcast.

Sophia Prater: Thanks for having me.

Thomas Betts: So first, please tell me a little bit about yourself and your involvement with OOUX.

Sophia Prater: Yes. So my name is Sophia Prater and I consider myself the chief evangelist for Object-Oriented UX. I allegedly coined the term I did not coin, of course, Object-Oriented or UX, but I shoved them together. People in the nineties were using terms like Object-Oriented UI, so it was not a huge leap for me to start using the term Object-Oriented UX. It all started with modular design and responsive design and trying to think about how do I create designs that are using the least effective dose of moving parts. So my granddad was a chemical nuclear engineer, and he always said the more moving parts, the more likely it is to break. And I just grew up with that in my head. When responsive design came to town around 2011, 2012, and all of a sudden I was designing for a moving canvas, that became so much more important.

So what I thought I was doing is I thought I was doing modular design, the precursor to a design system. And then what I realized I was doing was actually identifying not the components but the entities that the components housed. So I was working at CNN and I wasn't so concerned with the cards and the details and the sliders and the navigation elements. I was trying to figure out what are the things within an election, I was working on the election results. So I was thinking, okay, we've got races, we've got states, we've got candidates, and how do I keep those as consistent as possible because I don't need those things changing around? Because as soon as we have two different versions of the candidate card that has to now be across all of these devices, those two different versions, those two arbitrarily different candidate cards now have to be designed for mobile, for tablet, for desktop. And the QA, it kinda just gets exponential.

So that's where it all started was this idea of thinking about what the entities are. And I was doing it from a design perspective, and also then I started looking into the psychology behind it and how people actually think and how people identify objects in their environment. And really to be able to function properly in an environment, whether that is a physical environment or a digital environment. What the brain does is it identifies what the objects are. And even for folks that have visual disabilities, they're still doing that. They're using amazing coping mechanisms to also identify what the objects are in a given space. So I got into the psychology of Object-Oriented UX and how it benefits from a user perspective.

And then finally I came around, and this is before I was even calling it Object-Oriented UX, I came around to recognizing this is how developers are thinking too. They're thinking in data, they're thinking in databases, they're thinking in how these databases relate to each other and how data is passed. And I was realizing that, oh my gosh, what I've been doing in the first five years of my career is I've been showing a bunch of flows, a bunch of static screens and a flow. Sometimes they were fancy and you could click through them, and then the developer was looking at those screens and then reverse engineering them to figure out a data model. And I was like, this doesn't seem like the most efficient way to work. Maybe we could work together on this data model from a user-centered perspective, make that data model, that domain model really, really clear and really aligned with how users think about the environment and the domain.

Identify the nouns before the verbs [04:40]

Thomas Betts: Yes. I think that you got to, one of my first questions was going to be like, well, object-oriented programming is how we've been doing software for decades. It's pretty much the only way I've known to do business applications. I think that's true for most of the InfoQ audience, and you really only need the designer for those business customer-facing applications. You don't need it for a shell script, whatever. You guys aren't doing some user interface and UX design. So I think the naive aspect of a developer thinking of this is, "Well, isn't that how you always think of it, think of it in objects?" But that's not how the designers think about those workflows and that's been the difference. And that's how OOUX is different than a traditional approach to design.

Sophia Prater: Yes. A traditional approach to design is very verb-focused instead of noun-focused. And my hypothesis on why that is because of–we got our name around the e-commerce revolution–and we started getting to be at the table for usability testing because people needed to go through a transaction, they needed to get from point A to point B. And often our metrics are on conversions. So being able to get, and often that conversion was like, did they successfully get their credit card information in there and did they purchase the product? So those were some of those original usability tests of how do we get a user from point A to point B for that cha-ching. So that's in our DNA, even though a lot of UX did evolve from information architecture, which was about organizing information, but in information architecture, a lot of that information was very taxonomy based and organizing pages, not necessarily different types of content objects.

So when you look at traditional user experience design and basically how user experience design is by and large practiced today, it is very flow-based. Let's start with the flows. Let's start with how a user moves through it. And all that is so important. It is so, so important to figure out the verbs in a system, but it's way easier to figure out the verbs in a system if you've already defined the nouns, and then you can iterate back and forth. So what are the things in this space? And then figure out what do people want to do to those things?

And basically that's the crux of the process is figuring out those nouns, figuring out those things that users are actually coming for, that they care about, that they expect to be there, that you're going to need to build your databases and your APIs around. What are those things that need to be shown and what is their structure? And then figuring out what do people want to do to those? And then of course, you iterate back and forth.

Similarities with object-oriented design [07:12]

Thomas Betts: And I think that's where it starts to sound a lot like object-oriented design, that you have your classes and they have properties of the data elements inside them and they have behavior. Here are those verbs you can do. I want to save the invoice, I want to save the order or delete it, or whatever it is. And you're saying that that now gets brought into the design aspect, not just the architecture design side of "here's where all the objects are, and here's my UML diagram." You're talking about doing that as part of that user flow, thinking about those things?

Sophia Prater: 100%. And I've had some of the developers that I've worked with, and also very early in my career, I got to work with a lot of software engineers. I was working in startups, so I was usually the one UX designer surrounded by software engineers. And I still remember one of them saying jokingly because he was loving the process, but also saying, "You're taking the fun part away from what I do." And I was like, "No, we're just doing it together now so that we could be on the same page and it is going to be a little bit different." So from a UX perspective and from an Object-Oriented UX perspective, I'm thinking about the objects that are user-facing. I am thinking about the attributes that are user-facing. I am thinking about the relationships that are user-facing, how somebody's going to navigate through.

And just to get some terminology clear, when I'm saying objects, you're probably thinking classes. I use the philosopher term of the objects, and then I use the term instances for the actual lines in the database would be the instances. So in Object-Oriented UX, we basically work with developers to figure out what are those things? And it is very, very similar to... I would say the philosophy is so similar to domain-driven, very similar to what you might do. I think you mentioned the entity relationship diagram or UML or something like that. So I think that your audience is just going to be really interested, and unfortunately this is an audio podcast, but the diagrams that we create in the object-oriented process and in the ORCA process, so ORCA stands for objects, relationships, calls to actions, and attributes. We go through four rounds of ORCA to get to basically really, really solid requirements that describe the O's, the R's, the C's, and the A's from a user perspective.

OOUX artifacts are very scalable [09:27]

Now, a software architect could go through that entire process and do it also from a backend perspective and use this exact same process and it would feel very familiar. The cool thing about the artifacts that we create within this process is that they're really, really scalable. The problem with an entity relationship diagram is once you have 60, 70 objects, once you have 10 objects in an entity relationship diagram, and maybe some of those objects have dozens of attributes in them, it gets a little bit untenable. You get a bowl of spaghetti, it gets a little bit unreadable. And a lot of the systems that I work on and then they work on with my clients and my students work on, have triple digit objects, user facing objects. And from a technical perspective, you're going to have even more objects. There's probably going to be some non-user facing objects as well that you would need to be dealing with.

So even user-facing concepts, Autodesk who I got to work with recently, easily 300 objects in their ecosystem. Try to make an entity relationship diagram with 300 objects and some of those having hundreds of attributes. So what our artifacts do, the object map is scalable. So that was what I was really running into is doing boxes and arrows is really great when you have a handful of objects and a handful of relationships. But even when you start having multiple relationships between two objects, if you're trying to map multiple different types of relationships, just taking something as simple as a person and a post.

So a person has many posts that they've created, a post has one person who created it. Okay, great. But a person can also have many posts that they've saved or have many posts that they've liked or have many posts that they've created that are in draft state. So there could easily be six, seven different flavors of relationships between something as simple as a person in a post. Trying to do all of that with crow's feet or an entity relationship diagram can get really, really messy and difficult to read and difficult to collaborate on.

Thomas Betts: Well, yes, and I think that's one of the struggles that a lot of architects find is how do we communicate our design and say, okay, these are the relationships. And when you see that one line with the little crow's feet, you're like that's it. It's just one thing. And you don't realize that that might mean six different things and there's no way to stack that up. And if you do stack it up, is it clear what those mean? And yes, I've seen the diagram where, we'll put everything on it and it becomes like a PDF the size of Montana in order to be able to read the legibility of the text on it. And it's not useful for anyone to comprehend.

Use the nested object matrix to identify relationships [12:03]

Sophia Prater: And if we just think about relationships, just the relationships, not even thinking about the calls to action, the operations on the object or the attributes, the properties, just thinking about the relationships are so, so important. I'll give your listeners, I'll try to describe the nested object matrix just to give you something right now to help you document that, because again, those boxes and arrows, you can do little whiteboard diagrams, but really digging deep with a cross-functional group and collaborating on those relationships. And again, collaborating on those relationships from a mental model perspective, how do users think about how these things connect to each other? You can do something called a nested object matrix. So basically you put your objects across the x-axis and you put your objects, again, the exact same objects down the y-axis, and you map the relationships through the intersections.

So this is a way you can systematically go through it too so that you're not missing any relationships because again, if you're just boxes and arrows there, you have one box and the other box is on the other side of the whiteboard, then they might not get connected even if they are actually connected in the mental model and they should be connected in the system. So you can do this nested object matrix, start mapping out all the relationships, and describe the cardinality. If you've got six to seven relationships in one cell, you just stack those sticky notes. So you can do this in sticky notes, do this in Miro. In Miro, you can do this in Notion, you can do it in Airtable or whatever tool, and you basically build a matrix instead of doing it in boxes and arrows or doing both.

Thomas Betts: And I was going to ask, how do you do the multiple, and you're saying that intersection, it's not just a single point of intersection, it can be all the different relationships are in there. That's useful.

Sophia Prater: Yes. I will put maybe 10 sticky notes in that one cell between... So you basically think of your top ones, I call them the host objects, and you can just read it in natural language. So I might say an article, and then if I'm in the post row, I would say an article... I'm sorry, not a post, an author or person has many posts that they've created; has many posts in draft; has many posts that they've liked; has many posts that they've saved; has many posts that they've commented on. So you could have all of those relationships just stacked up and it scales beautifully.

Seeing all the relationships helps define requirements [14:13]

Thomas Betts: I think it's one of those challenges of seeing all those relationships and getting those captured in requirements. This actually came up in a discussion this morning on one of my teams. It was I'm solving this one problem that's a cross-cutting concern. It's like everyone has this type of relationship, but I'm solving it for my data, and someone else has that same relationship with their data. Am I supposed to solve all of those problems and is it documented in the requirements that I'm actually solving all those requirements? There might be five different things I should be checking for, but I'm only handling it on this one screen for this one data type. And getting all those relationships spelled out is very, very useful to be able to then look at the requirements and someone can check off, we can meet all these requirements.

Sophia Prater: Exactly. And in a meta sense, you're objectifying the relationship. You're creating a little card, whether it's a sticky note, a sticky note in Miro. We love using Notion and Airtable in the OOUX world. You're creating a thing that represents that relationship in one way of that relationship. It's a two way street. So you have one card, if you will, for "a person has many articles that they've created," and you have another card for "an article has one person who created it." And then what you can do is you can put your documentation on that relationship between the two things. And then if you need to copy and paste because you have that relationship that is in two different systems and in different requirements. But then you can go in there. And what we do in the requirements round of the ORCA process, what we do is for every single relationship, we look at what we call "My Cat Saving Fire Department," and that stands for the Mechanics.

"My Cat Saving Fire Department" is a mnemonic for Mechanics, Cardinality, Sorting and Filtering, and Dependency [15:51]

So what is the mechanics? How do these things actually connect? How do they get connected? Is it by user manually hitting a button? So is it by a user action? Is it by an API? Is it a system recommendation? So is it automatically being connected? Is it a content creator and a CMS connecting these things manually? How are they actually getting connected? Then we go through the Cardinalities, we get deeper in the cardinality. So instead of just saying a person has many posts that they've created, we're going to say a person has many posts that they've created, but on average, how many posts does a person create within our system? Is there a maximum number? So this is getting into that performance question.

So I know in your world, performance is a big issue. So we can start talking about that super early as the UX designers are designing it, and we're saying, okay, is there a maximum? How many do we actually expect in this particular system? Are people on average creating 10 posts or is it averaging 5,000 posts? That's going to have different implications there with performance, as well as also mapping all those relationships and seeing how you might pull through information through those relationships.

Thomas Betts: Yes. That's a useful example because architects are concerned with the quality attributes of the system. So performance is probably related to how much data and if the relationships are the data, the relationships are just as important as the articles, the posts, the authors, how does that scale? So if you can establish early and say, "Our requirements expect this, or maybe for your MVP, for the first year, maybe someone's going to create 10 posts a day, so the maximum's going to be about 3,500 in a year." But fine, we can scale to that level. They're not going to create 3 million. One person isn't going to do that. So you can get that written down and then your architecture can be just enough to support those use cases. And having that quantified early is always very helpful.

Sophia Prater: Yes. I mean, number of instances is something that we go through right off the bat. I mean number of instances when it comes to connections and also when it comes to the object overall. So we create something called an object guide, and one of the sections of the object guide is how many instances do we expect within the first couple months, within the first couple years, people or posts or events so that we can start gauging that idea. And from a design perspective, it's a huge implication from a design perspective. So that's really been my main concern. And then the more I grow up as a designer and learn, "This is a performance implication too as well," but to go back to my cat-saving-fire department, we have the mechanics, the cardinality, and then we have sorting and filtering.

So this is why, okay, if a person has many posts and I expect them to have about five posts, I don't need to worry so much about sorting and filtering. If I'm on a person detail page, there's just their five posts. But if we're averaging 500 posts on a person, I probably need to provide the user with sorting and filter mechanisms so I can start looking at that right there. What are the sorting filter mechanisms of posts within context of a person? And then the last one is dependency.

So if somebody deletes their account, what happens to those posts? Are the posts dependent on the author object? And this is just things that most of the time designers don't think about and we throw it over and we leave it to the developers and it's like, you all have enough to think about. This should come from user research. What do users actually expect? For the dependency question, this is major implications. Thinking about Yelp, if a restaurant closes on Yelp, what happens to all the reviews? Do the reviews go away? Do they stay there? Do people who have reviewed the restaurant get alerted if the restaurant closes? What actually happens? But this has big implications when it comes to architecture as well.

The ORCA process in detail [19:34]

Thomas Betts: Yes, that's really fascinating. So I wanted to go back, you've mentioned ORCA a couple of times. Walk me through the whole process, spell out the acronym again, and then what are you doing? I want to understand the techniques that you're using to walk people through this process, and why do you do it four times?

Sophia Prater: Yes, iterate, iterate, iterate. So ORCA, objects, relationships, calls-to-action, and attributes. So objects, what are the things? What are the things that people actually care about? We do something called noun foraging, which AI is getting better and better at doing that. We're definitely using some tools for noun foraging now, used to do that manually. But basically looking at a bunch of data, whether that is user interviews, customer chat logs, the vision deck from the CEO, whatever. Subject matter expert interviews and we're looking for the nouns. We're looking for the nouns that we hear over and over and over again. We're looking for nouns that have structure, instances and purpose. So that's what we call SIP. And we do a little champagne "cheers!" every time we find an object that has structure, instances, and purpose.

So the first round is discovery. We're just figuring out, okay, what are we working with here? And in that first round of figuring out your objects, your relationships, your calls to action, your attributes is all about asking just really good questions. It is like shining a light in all the dark dirty corners, shining a floodlight. I sometimes make the metaphor from a design perspective, I'm sure this is true in your world as well, when it comes to requirements and scope and what are we actually building, it sometimes feels like you've got a old dim flashlight with the batteries are flickering in and out, and you look in one and you see a little bit of the picture over here and you see a little bit of the picture over there, and then you move the flashlight back and add the picture's changed. So this is like let's just turn on the floodlight and figure out what are we actually building here? What do we not know? What are the unknown unknowns? We can ask a whole lot of really good questions.

The nested object matrix [21:26]

So we start with that, figuring out what those objects are. We do a first round of nested object matrix, then we go into a call to action matrix. We go ahead and go into roles. So right off the bat we're thinking about roles and permissions. I know that's another big concern on your side is security and permissions and who can see what. So that is also something that traditionally UX designers are not great about thinking about until much later on. Or they'll just think about the one user. We're just designing for this user right now, and then later on the next sprint, we'll design for the other user. Don't love that approach. It would be like the metaphor I give for that one is like an architect, like an actual building architect saying, "We're going to design this bank, but we're just going to design the customer side of the bank first. We're not going to worry about what happens behind the counter." That would be ludicrous way to design a building to just design for one side of the story.

The call-to-action matrix and object map [22:21]

So we go into the call to action matrix. That is we figure out our roles. We have a roles on one axis on the y-axis, and then across the x-axis we've got our objects, and then we put the verbs in the middle. So what can these different roles do to these different things? And then we go into the attributes, and that's where the object map, the holy grail of the Orca process. It's basically we've got that nested object matrix and we start adding attributes. It's a very beautifully color coded diagram, which includes, we separate metadata from core content. So we have the two different types of attributes. So core content being our unique identifiers, our titles, names, images, that kind of thing.

Iterating through the ORCA process [23:00]

A lot of the time the more unstructured content, and then we have our metadata. That's our more structured content that users are typically going to be sorting and filtering by. So we go ahead and start separating that. That's a discovery round. We're usually in sticky notes. We're loosey-goosey. We're figuring out all the questions. We often have to go back to research, and then we go through a requirements round. That's when we basically put everything under a microscope and we go back through the O's, the R's, the C's, the A's. We built an object guide, which is like a glossary on steroids. We go deep with our nested objects and go through that "my cat saving fire department." We also get a little bit more into inheritance. We will from a design perspective, create object bases. I know inheritance is a little bit of a touchy subject, but from a user perspective, sometimes it's really good to know that we have people objects, but every person object is either going to be a celebrity or a fan within this whatever Hollywood website that we're making, there's never any just people objects.

You're either going to be a celebrity or a fan, but there's a lot of stuff in common. So we'll start pulling out some things into bases, like little starter kits for objects. We look into junction objects. We've got something that we call tree systems, so we get a little bit more into hierarchies of objects and just get a little bit more detail than in the CTA, I told you it was 15 steps. I'll summarize this as best as possible, give it all away here.

Build prioritized object-oriented user stories [24:22]

And then for the requirements with the calls to action, we basically build object oriented user stories. We already have the who is doing it, what are they doing it to what object? We go deeper with the why and the when. So why are they doing it? Do we have a really good reason? Do we understand the user's motivations for why they are actually acting on this object? And when are they doing it? In what context? Is there any conditions that need to be met before they can do this thing? So we get into a little bit of conditional logic there, and then we go and we get deeper with the attributes. I won't get into that.

The third round is prioritization. Now that we have a really good picture of our O's, our R's, our C's, and our A's, we can prioritize from a user perspective and a business perspective. Our O's our R's, our C's, and our A's. So we can say, this is what we're launching with first and based on what we're launching with and there's this great trickle out effect. You eliminate some objects, well then you're eliminating relationships, you're eliminating CTAs, you're eliminating attributes. So our templates do a pretty good job of that to trickle it down and we could say, "This is what we're building first."

And then from a user perspective, what objects are most important? What attributes? What's more important on the post? Is it the timestamp or is it the author? This is a really simple example, but we want to keep that consistent as possible throughout the experience so we can actually prioritize that. Again, like before we haven't gotten any screens yet. It's not until that last round where we start getting into screens and we have OOUX style sketching, which really helps ensure that we can keep all those objects really nicely consistent and basically creating that beautiful modular design based on the objects. I know that was a lot.

Thomas Betts: It was a lot, but there were so many points that I'm like, that's how you should be designing software. And it goes back to that almost naive approach like, well, isn't that how you've been doing it? But if you're thinking just flow-based, like, "The user's going to create a post and they hit save and we're done." And that's all you describe, you missed out on a lot of things, which gets to one of the big problems in software development is the requirements are missing the details. And then the developer is told, go and build "the user creates new post and saves it" and here's the wireframe and figure it out. And from there, they have to then decide, "Well, what's the data model? What already exists from other stories? What is implied in that requirement?"

And are they allowed to save or do they save and immediately post it and can they delete one and all those different things. If they weren't in that one workflow that was designed and that is all that got put into the user story for them to work on, you end up with half developed software. And then you get back to this doesn't meet requirements. Well, I did what the requirements said or what I interpreted and it looks just like the picture. So aren't I done? And anytime you can avoid that. So hearing you describe all of these details and iterating through and understanding that first pass doesn't get to the end state. You have to keep going around. And I like having the specific, this is why we're going through it again. We're going to go deeper on this part until we get to it. Is four rounds always the thing, or do you science go back and like, "We got to go through it again?"

Adapting the process to your needs [27:31]

Sophia Prater: No, it's never the thing. Does it ever actually happen the way that I want it to happen in my head? No. I'm just talking to you about my dreams.

Thomas Betts: This is the textbook definition of the-

Sophia Prater: This is the textbook canonical definition. No, you always adapt it to the situation, that is to your timeline, to your product, to what your needs are. It is people look at the orca process and they're like, "Are you kidding? 15 steps of process. I've been so burned in my process. I don't want that rigidity." You can think about it as a bag of tricks that go really well in that order, but you can mix them up. A lot of times people will mix up the prioritization and the requirements round.

So go through discovery, then prioritize, and then just write your requirements on what's been prioritized. That is a really nice little shortcut. The purest in me is like, "Well, how are you going to prioritize if you haven't gotten a really good idea on what your stuff is?" You'll do a better job prioritizing if you take... I mean, and all this is entire process, I'm talking days, weeks, not months, depending on how complex your system is. But taking two to three weeks to do this every four or five years, I mean, I might be underplaying it a little bit. Again, it depends on how complex your system is.

OOUX is ideal for defining core system concepts that do not change [28:44]

But a lot of this stuff, the good news is we're talking about these concepts that don't change. If we think about those pace layers, this is the bottom of these pace layers. When I work with these companies on, let's say for example, so one of my colleagues works in farming, shout out to Allie Ofisher. So actually it's a pig farm. This has been done the same way. Unfortunately it's not beautiful how it's done, but it's been done the same way for decades. And even if certain things change, they're going to have pins, they're going to have barns, they're going to have pigs, there's going to be farm hands. Those things are not going to change.

In marketing, we've got campaigns, we've got segments, we've got people in those, customers in those segments, the things actually don't change. So if we can get that right, we take, oh my gosh, an entire month to really figure this out and then can pay dividends for years if not even decades for your company. What is that worth to get clarity to get everybody speaking the same language too. Just calling these things the same thing. I mean, if you're only... Sometimes I'll say just do the first step of the process, just build a glossary. Build a glossary of the concepts so you're not using different words for the same thing or the same word for different things because it's really hard to build complicated software when you're doing that, when your language is messy.

Thomas Betts: Right? And that goes to, you mentioned domain-driven design earlier, and that's one of the core tenets of domain-driven design. You have bounded contexts with ubiquitous language, and the ubiquitous language is ubiquitous within that smaller bounded context. I work on financial systems and accounting. We have accounts payable and we have accounts receivable. They both have invoices. If I just say invoice, which way is the money flowing? But if I'm in the accounts payable department, I only know that those are invoices that come in that I have to pay.

And if I'm in accounts receivable, those are invoices that I'm going to be sending out to get paid. They don't say an accounts receivable invoice and an accounts payable invoice, but within that structure, you have to put the bounded context around so that invoice has the right direction implied. And that's I guess getting back to your idea that you just get the language right, come up with the glossary, come up with the terms and get to the same language. And anytime you can be speaking the language of the business in the design and in the software and it just gets embedded, it removes so many problems with communication.

Identifying taxonomic hierarchies [31:13]

Sophia Prater: 100%. And I'll just add to that. Sometimes we say, "We need to use the language of the end user, and that is true to a certain extent, but as professionals, we need to be a little bit more precise with our language than how things are talked about colloquially. So this is getting into this concept of tree systems. Maybe the word for this. I searched, I was like, what is the technical term for this in our community? We just came up with the word tree system. So basically this is going from a general to a specific thing, not objects and instances, general to specific objects. So an example I give all the time is you have movie. So a movie is The Little Mermaid 2022, I think, or 2023. All right. And then you have the movie at a theater. All right.

So then you have an instance of that would be The Little Mermaid at Mountain Cinemas, and then you have a Showtime. You have The Little Mermaid at Mountain Cinemas at 8:00 PM on Friday, and that's the thing that can be sold out. That's the only thing that has a sold out status. Another one has, whether it is in 3D or not, what do they call that? Or Dolby Vision or whatever, or is handicap accessible. So that's information about the theater that gets passed down. Now, the movie poster is probably only going to sit at the movie object because probably Hollywood, this is getting into permissions too. The people that can edit the movie object, where the movie poster lives and the runtime lives and the release date lives, and the official synopsis lives. The person that is editing the showtimes at Mountain Cinemas should not be able to edit the movie object. They should only be able to edit the showtime object.

So we've got these three objects that are all highly connected to each other, but they are different things with relationships. So you've got movie, you've got movie at theater, and you've got showtime and it colloquially, I'm not going to say I'm going to a showtime, I'm going to say I'm going to the movies. What I mean is I'm going to a showtime. So that is one example, and that's where OOUXers get into that beautiful wordplay of figuring that out and realizing we're confounding these three concepts into one. And what we can do then is split that out and make it really, really clear. Also, to the end user, you're looking at a showtime versus a movie, and I'm looking at the showtime, now let me navigate up to the main movie so I can see all the other theaters it's playing out. So this is also a navigational construct as well. Is there a technical term for this thing that I'm describing, this general to specific?

Thomas Betts: Nothing comes to my mind, but that hierarchy is definitely an aspect of, I think you got to data taxonomy and how do you structure your data and how are the relationships stored? And yes, that winds up to the problem of I could just create the movie table in the database. And then what goes in there? If you start putting showtimes at theaters in the movie table, that just smells wrong. Okay. Well, I have a movie and I have a theaters and I have a showtime. The engineer is automatically going to, how do I structure the data? But that isn't the same way as how do I talk about it and what does the design look like?

And you mentioned the person editing the showtimes. That's a different user interface to that same data, and that's a different workflow. That's different UX design. That's maybe more data you need to have in the system. Maybe it's a different view of the data. I don't want to have all of that data visible to every user who's going to book the showtime. They're going to buy a ticket, but maybe the person who's at the theater needs to be able to edit more data and see additional things like how many seats are in the theater, or you can't buy seat 7B because the chair's broken or something.

Sophia Prater: Exactly. So you get that. Also, you get the roll-up data too. So if on the movie, if I'm an admin, I may be able to see things like the gross sales across all theaters, across all of America if I'm admin in Fandango or something like that. So I can get these high level analytics that get pulled, that gets passed from the Showtime to the movie at the theater all the way up to the movie. And you can basically then from a user experience perspective, I can start really thinking, okay, who gets to see what on these different objects? How is the end user going to navigate? But also who can do what to what object? What are our permissions as far as visibility and actions are concerned? And then where does this information belong? This is also a content editing question too. So if we're putting whether it's handicap accessible, is handicap accessible?

Is that on the theater? Is that on the theater room? Now I'm using theater in two different ways. Is it in the theater as in mountain cinemas or is it on mountain cinema theater three. Is theater three handicap accessible? But theater one is not, or is just the entire theater handicap accessible? So if I wanted this showtime is handicap accessible, where am I pulling that information down from? And if it changes, how do I make sure that the user's not having to change it in a whole bunch of places? And we get that nice trickle down effect.

How to revise the design [36:20]

Thomas Betts: That's where I think we're getting to is that if you think about all these things up front for the really core concepts, those are established terms. You're not inventing the idea of a movie theater for this thing that we're coming up with. We think those exist and we're just trying to model our system to support that. You have to get those right day one or it's not going to evolve. Now you can prioritize it and say, "Hey, this is all we need to handle for day one. We're not going to handle handicap accessibility for horrible reasons. We're going to deal with that and version two, but maybe we don't release the MVP to everybody and it's just in beta test." That's where you get to… The question I want to have is how do you revise the design? Say we did almost everything upfront, or do you wait until things are out in the real world and come back and how do you make the changes and what does that look like? Do it go back to the mural board and the air table and move the stickies around.

Sophia Prater: That's a great question. It depends. It comes into that prioritization round of like, okay, so this is what we're building now. And what I will say about changes is we want what we're building now to be, I’ll quote John Gaal, because I always quote John Gaal, you want to create a simple system that works before you create a complex system that works. You can't really create a complex system that works until you've already created a simple system that works. So I really encourage companies to think about that. What is your simple system that works, but also have you sketched out your complex system? So sticky notes are really cheap. Moving stuff around on Airtable and Notion and Miro is actually pretty cheap. So I always encourage people to build your 18 month plan. This is not huge design up front because we're not designing all the screens, we're just thinking things through so we don't paint ourselves into a corner and have a bunch of tech and UX debt.

So we can go and say from using the architecture metaphor, we know that there's going to be a porch over here. I would love a porch over here. We're not going to build the porch now, but I'm going to go ahead and do the grading in a way that the porch can be built there. Or we're going to go ahead and stub in the plumbing for this third bathroom. We're not going to build out the third bathroom right now, but we really want a third bathroom in the basement. So let's just go ahead and get the plumbing in there. And we're making our lives so much easier later on. And that's what OOUX can really, even if things change and we say maybe that it's going to be a wet bar or not a bathroom downstairs. Things might end up changing, but to have a really good idea of where you are going helps you avoid that tech debt. And you are nodding. So you're on the same page about this.

Treat the object map as a source of truth [38:58]

The other thing that I was going to say, so when it comes to actually changing in your documentation, this is a really good question. Now, it depends on what that source of truth has become. I love the object map to be a source of truth. I think it's a great way to document requirements. It's totally scalable. Every little bit and piece of the design gets its own if it's Airtable or Notion gets its own page that you could add structure to it. So you could basically add... It's like meta. It's taking it one level deeper where your attributes actually have back end attributes, whether this field is required or not and things like that. The maximum character length for this field. So you can get into a whole lot of detail with that.

When you have that and it's documented and you're all in agreeance on it, then our technical side can go ahead and start building out technical architecture. Can start building out maybe some of the things that's going to be a little bit harder. Build out those APIs, figure out some okay, we're going to want to be pulling information from this nested object and then from this nested object, okay, what are our performance considerations there? You can start doing that without any screens, which is a beautiful thing. So I can go ahead and start designing some screens while you're working out some of the hairy parts of the technical architecture, getting that all set up. And then you can see screens. And the screens are no surprise because it's like yes, this is what we talked about. So now you've released that. The good news is if you're using Object-Oriented UX, it's going to be very naturally intuitive.

And these are things that just are the truth about the world. All right. What we are doing so much in Object-Oriented UX, I think a lot in technical architecture and software architecture is we're trying to reflect the truth of how the world works. What is this business? How do things work? If it's movies, okay, I'm not changing the way that Hollywood works and distributes their movies. And I really realized this when I was working on election results, I'm not designing how the information architecture of how our election system works. I'm trying to figure out what is true about this system and how do I reflect it in the best way possible.

And if you're doing that, there's not a lot of changes that have to happen after that. That 80-20 rule, instead of major issues that you've launched that you're going to have to go and rewrite and rethink and rework. You're going to have very, very little of that because you're just like, this is just a reflection of how the world works. Now when you do have those changes, yes, how do you decide to change this? Do you change them in the screens and then you go and change them over in Airtable or Notion? That would be up to the team? What becomes the source of truth? Is the sticky note Miro board that probably is just a sketch. Does it end up going into Confluence or Jira or something like people have created object maps in Confluence before? So does it go into another system and that becomes a source of truth? So it's a tough question and I am considering that as I consider what the custom software would look like for the ORCA process where these things, you don't have such a big issue with change management.

Additional resources [42:01]

Thomas Betts: Well, I think that goes through a lot of stuff. I think there's a lot of analogies, like I said, to how developers are thinking about this. So I love having the designer perspective meshing really well and just getting more people involved in a collaborative process upfront. If people want to know more about OOUX, where can they go or how can they contact you?

Sophia Prater: There's ooux.com. We've got so many free resources. You can go to "Getting started with OOUX". Connect with me on LinkedIn. I'm Sophia Prater. I love it when people connect with me on LinkedIn. And we also have the OOUX forum, so that's OOUX Forum. It is free to join there. We have an entire space for OOUX and developers, so we already have some developers in there. And I honestly think that this is just going to be such a good tool for software architects to really be able to document in a, it's hard to say delightful, but I would go ahead and say, this is the closest thing to delightful documentation that you could find. Because documentation, can it ever really be delightful? But we're talking color coded, we're talking really, really methodical, and it brings a lot of stress out of the documentation and making sure all those decisions were clearly documented. Does a really, really good job of that, some of the artifacts. So send people to those places. And I am excited to connect on LinkedIn and in the OOUX forum.

Thomas Betts: Well, I will be sure to get those added to the show notes when this publishes. I need to give a shout-out to one of my coworkers, Brad Bonham, who introduced me to OOUX, connected me to Sophia. So thanks Brad for that. And Sophia, thank you again for talking with me today on the InfoQ Podcast.

Sophia Prater: Cheers. Thanks so much for having me.

Thomas Betts: And listeners, we hope you'll join us again next week. Thanks.