Intro to Object Oriented UXβ€” World IA Day 2022 β€” Twin Cities, Minnesota

Transcription

Carissa Merrill β€” Conference host All right team and I see Joey's on ready and raring to go. I love it. Thank you so much. Welcome back, everyone. We are about to kick off object oriented UX with Joey Perlman.

Thank you again to everyone for coming out today. It's been such a fabulous time, I was just messaging with student one on one about just like how incredibly grateful I am. And we all are that y'all not only are choosing to share such fabulous content, but also that so much so many of the community are available to come in, to come in, share the experience with us and give feedback and learn together. So just over the moon with gratitude.

So thank you all so much for making this day. So fabulous. All right, onward. Here's Joey.

Joey's a designer that is passionate about content systems design and design systems. Joey earned his UX certification from Prime digital Academy, where he now helps guide new students through the program as a UX program coach, when he's not compulsively collecting and sometimes reading books on design. He's fighting the ever present temptation to buy audiophile accessories that make music sound imperceptibly better at frequencies humans almost definitely can't hear. All right, I will turn it over to you.

Thanks, Joey.

Joey Pearlman β€” Presenter Thank you. Alright. So I'm going to start my screen share and just want to double check my audio is coming through on these air pods right. Okay, sweet. All right.

So welcome to an Intro to Object Oriented UX. And also happy World IA Day.

Really excited about this.

So about me, I graduated prime in August 2020. I work at Prime currently as a program UX program coach and I just finished a contract working on agency working on education products.

And on that contract, I had kept on running into issues about basically, we would make new features, I would pass those off to developers and they would ask me questions about Okay, so we have this new feature, how's it going to link to these other pages? And or is it going to show up on this page as a card? Or is it going to show up over here as a list? Or what do we do with this information? We don't have it is empty.

So I started reading a lot about IA stuff. And it was really trying to hone those skills. And I went back into that project thinking that I had a whole bunch of IA information I would do great.

And I kept on getting the same questions of Okay, so what do we do? And this is empty, how will this link to these other things?

I was like, Oh my God, this must be because, you know, I'm still sort of a new newish design. I'm sort of newish to the field, there's probably, this is something that I still just have to build up over time. There's not any silver bullet that's going to instantly solve all those problems for me.

And then I found Oh, UX, I was like, Oh my God, this silver bullet solves all these problems for me.

So let's dive into this a little bit. So object oriented UX is a philosophy or framework of viewing interfaces as a system of objects.

It was created by Sofia Prater, she started this in this 2015 article, object oriented UX published analyst apart and since then, she's continually evolved in and built in iterated upon this framework. She currently has like a very, very great course that goes into so many details about this process, and also has a podcast and YouTube channel and just is continually adding and sharing more information about it.

The very quick summary is that it combines some information from object oriented programming framework that engineers use of saying the things in our system are basically objects and containers of information that will link to other things, and combining that type of thinking with UX methods to create this really powerful and robust and simple framework that you can use to build up the spray information architecture for your products.

So before diving much deeper into Object Oriented UX, let's talk a little bit about objects.

Objects in the physical world help us to do a whole bunch of stuff, they help us to understand, interpret, and move through our environment.

So if you walk into a coffee shop, the first thing that you do is you're looking around, find where the walls where the doors where the tables where the chairs were the people. And then from there, you're able to say, Where's the table, I want to sit up, where's the person I want to talk to where's the door that I want to walk through, and you're able to navigate around this environment because you're recognizing all these objects.

They also help us find related objects. So if you have a spot in your home, where you keep your pocket and your hands, it's probably going to be really close to the spot where you keep your forks and your knives and your plates and your glasses. It would be very odd to have a room where you keep your frying pan and then in the attic, you have your spatula.

You want those to be near each other because those objects are related to each other.

And objects in the physical world, they also help us understand what their design helps us understand what actions and objects fail for. So a handle on a suitcase is an affordance, for lifting it, switch on a light switch is an affordance for turning it on and off.

So let's compare that to the digital world.

In the digital world objects help us to understand, interpret, and move through our environment. So one example is just the iPhone home screen where you open it up and you have all these different objects on your screen that you can go into an explorer and then go back out, walk back out to and kind of walk through your whole library. Another example might be a usability test for a website, a lot of the time, they'll run in this way where unless you explicitly ask your park participant not to do anything, they'll go to this website, the very first thing that they'll do is they'll scroll up and down, because they want to get a sense of what this environment is and what all the objects are, and what information might be available to them.

Digital objects also help us find related objects. So one example is Google. So if this happens to me all the time where I'll be thinking of a film, but don't remember the name, I'll be thinking of an actor, I don't remember their name. But I'll be able to remember, a film The actor was in a decade ago, and from there and able to kind of connect those pieces and say, Oh, Ethan Hawke, or snow falling on cedars bass, sorry, Ethan Hawke, who was then in this other film, The before trilogy, which is the one that I was thinking about, I can never remember the name of.

So objects in the digital space help us with those interconnections between those pieces of information.

And digital objects also help us understand what actions an object is built for.

So if we look at the Netflix card, it has all these affordances to allow us to play it, read it, review it, and add it to our list to watch later.

So if you didn't notice, these features are all identical between the physical and the digital space, there is a huge overlap between the way that we think about objects in the physical world, and the way that we see them in the digital world.

And this overlap isn't immediately obvious. And hearing it for the first time was just conceptually like mind blowing for me.

So objects are foundational, and the human brain really wants to interpret things as a whole bunch of objects that we can interact with.

But most design frameworks don't start with objects.

So let's dive into a little bit about how OOUX is different from other design frameworks.

So there are some common methods, some common design methods.

One is the jobs to be done framework, where it focuses really on the unmet needs of the user.

So basically, you do a whole whole whole ton of research, you'll end up with a very, very long list of tasks and unmet needs. And basically, things that your users want to do, that they aren't currently able to do or don't have a great way of doing now.

And then you're able to kind of reverse engineer it and say, Okay, so this is what people want to do. So this is how the things that we need to design for.

Story mapping is kind of similar, where it's mapping out the required series of actions to complete a task. So you'll end up with a whole bunch of sticky notes that line up and say, basically, to do this one thing, a user will first do this, and then they'll do this, and then they'll do this.

And then we also have job stories, which is this format of writing the stories from a user's perspective of when I blank, I want to blank, so that blank, and you basically get this context, task context sandwich.

And what all of these things have in common is that they're very focused on the tasks, but it's the voice from the user's mental models and the way that they're thinking about the optics on the system and things like that.

So you basically, you're starting at this endpoint of we want the user to be able to do this thing, and then kind of reverse engineering from there to build backward to say what do we have to build in our system to support that?

What OOUX does is it kind of flips the script, where it says, the very first thing that we want to focus on are the things that the users are going to manipulate the objects that they think about their mental model. And from there, we'll go on to build out those other things.

So the object oriented UX way of looking at the world is basically seeing it through the lens of these four different types of components.

So first, there's objects. These are basically the things that you have going on in your system.

Then there's relationships, which is now that you have all the objects in your system, how are they all connected to each other? How are they related?

Then there's calls to actions where now that we've have the objects, we have our things, we have the connection between things, what actions will users want to take on those objects?

And then finally, we get into attributes, which is what these these objects hold. They're just like in the physical world, you would have a box or mason jars or whatever that holds things. These objects are also holding things. But what most objects are holding our information. That information is things like names and images and content, and metadata like date created and things like that.

So let's dive just quickly a little bit deeper into into these four things.

So objects, these are going to be the things in your system, the nouns. And you can find these by primarily by talking to people and doing research, interviewing your stakeholders interviewing your users, you can also find look at how similar products might define there.

You can also use things like competitive competitive analysis, to look at how competitors where objects might exist in those systems. And after you've built out a library of all your all the objects that you're going to have in your system, can start build out relationships and say, how are those objects connected to each other?

And then you can start thinking about what are the affordances those objects are going to offer to our users? So what verbs, what actions do our users need to take? And how can they do that directly on this topic that they're looking at?

And then finally, you'll think about the information that the object contains. So those are going to break down into two attributes are going to think break down into two categories, content, which are things that make up that give an instance of an object, its uniqueness.

So if you're working on a blog, or a news website, articles, and blog posts are going to be really important objects in your system. And the things that make each article and blog posts unique are going to be these content pieces. So things like the name or the headline, the actual text on the article, images and videos.

And then metadata is things that you can sort and filter by. So things like the date that they were posted, or the date that they were edited, and things like that.

So going back again, I'm going to run through this one more time, because it's very important is we have objects, and those are, those are basically the nouns in your system, we have relationships, those are the connections between all your objects, we have calls to action, which is basically your verbs. And then we have attributes, which is content or metadata.

And taking all these four things together, forms this acronym, ORCA. And this orca process is the core process of OOUX.

It's a series of methods to define the mental models and the objects in your system, the relationships that they have to other objects, what calls to action are offered through affordances, and how content and metadata are prioritized.

And if you're looking at this, and thinking, Orca, that reminds me of one of the main characters from the classic 1993 family film Free Willy, the story of troubled orphan youth, and a friendship you could never imagine. totally right. If you can understand Free Willy, you'll understand the process, I don't make the rules. That's just how it goes.

So going back to this, at the end of this process, you will end up with a basically a whole bunch of sticky notes, and a column of sticky notes that looks something like this, where you have the object that you're defining, all the objects that is connected to, the verbs that are connected to that object, and the content and metadata that make up the object.

And from here, you can start to do prioritization. So there was about a decade ago, there was short trend, that… sorry, zoom, zoom message just popped up so participants can now see your screen. And I started panicking that I haven't been sharing my screen this whole time.

About a decade ago, there was a thing called a page description diagram. And it was basically a really kind of short lived design fad of when thinking about a page, you would go through the process of ranking the pieces of content that will go on that page. So we would have like a column for priority one. One or two pieces can be priority one, and then everything below that, that would be priority two and five pieces can be priority two, and then below that is priority three, and priority three is going to go underneath priority one and two.

And that process is done a lot in the back of a lot of designers heads. But this makes it explicit. And you can do that same type of thing here.

So now that you've like really defined things about it, you can start to rank these attributes and kind of reorder them and say, This is the most important thing. So it's going to go on top of this list. This is related or the second most important thing. So it's going to go there at the top as well, I think can take that and turn it into kind of a low fi wireframe that you can use to communicate and get feedback and find out what what pieces Am I missing.

And the the purpose of doing it like this is that you have this really explicitly defined hierarchy of everything on your page, which prevents you from rearranging things for no reason basically.

So Sophia Prater has this great term called shapeshifters, which is objects on the web that will change shape for basically no reason. So one example is Amazon, you probably know them as an organization that continually overworks and underpays workers and uses devious tactics to prevent labor from organizing and forming a union. But they're also known for selling books.

So this is the page I think of when I think of the product page for Amazon.

So on the right hand side, you have the add to cart Buy Now stuff and at the very bottom at the Add to List. They also have other variations of this page.

So this is just this is one of those variations where it's very similar. On the right hand side, you have the Buy Now thing you have other buy actions, like the quantity and buy for others. But what's missing from here is that this Add to List button. This is just not over here on this right hand side.

First time I saw this design, I thought I thought that they removed wishlists for me and was like, Why? And it's actually hiding way over here on this bottom left hand corner.

And so that is very disorienting and very annoying. And it's bad enough that they do this once, but they actually have more variations. So if I want to click onto this tab here, now this is a completely different reshuffling of all that same information where the price and this page is at the top right, if I go to the next tab, it's now on the left hand side. And there's really no reason to reshuffle this information there.

On occasion, it might make sense if you have really good reasons. But by having this like defined hierarchy that you can stick to forces you to not deviate from that hierarchy unless you have a very, very good reason to do so.

So, so that is the intro to OOUX.

Now let's talk about how you would actually apply it in a project.

So the first step of UI UX is that ORCA process, So now we're hopping into that ORCA process that I mentioned earlier. So we're going to start with objects, and talk about defining our objects.

So the very first step is called noun foraging.

I think that's such a great name, which is basically you're going to get scrappy, you're going to do interviews, you're going to look at competing products, you're going to find all the types of nouns that you can possibly add to the system.

Primarily you're going to be doing this through interviews, that's interviews with stakeholders, interviews with users.

And here, I just have two fictional interviews I wrote, I'm not going to go into in depth, because I'm going to switch to a different example soon. But basically, this is an interview with a stakeholder an interview with a student, and you'll read through your transcripts from your interviews, and just highlight all the nouns that appear here.

And then this is part that, you know, that lets you know that this is really a design method is that you'll turn everything into a sticky note.

So you'll end up with a slew of sticky notes, that you can then start to do affinity diagramming. So you can rearrange things, so that related things are closer together. Then you can start to interrogate are these things really related? Or are they actually the same?

So here I have these objects, Professor, teacher and instructor. So one question is, is an instructor and a professor? And they both teachers, or is a professor a slightly different role than instructor? And do they have slightly different needs?

Or maybe it's not slightly, maybe it's a significant difference between these two things.

And so that is a question that you can ask really early on, and then start to plan out questions for your research to make really great informed decisions as you continually build up your product.

So in this case, I'm going to say, yes, these are all teachers and teacher is now going to be like the defined vocabulary that we're going to use for this thing.

As you go through this process, you might also say, Oh, actually, I had this noun, English Department. That's actually an example of a building for this.

This Jane Appleseed. This is actually an example of a student. And earlier I had grades. This actually might be metadata that lives on an object they didn't have already, like an assignment object.

So you, you have this really great way to build a great knowledge of your system, and continually ask questions to make sure that you're doing the right thing.

Another thing I like about this is that because everything is sticky notes, it's very low stakes. If you make a mistake, you can take the sticky note off, you can erase it, you can write over it, you are not making decisions that is going to impact somebody's next two weeks to rework something or anything like that.

It's okay to be wrong. Because you'll you'll go on and continue to test and iterate throughout this process.

So after you have this, you'll go into relationships. And this is where I'm switching to a completely different example.

So in this example I have, say that you're working on a product that is going to host events. So some important objects that that product might be an event, a location, and a user. And after you have these defined, you can start to say, what are the connections between these different things? So an event, how is that related to location? Or, here I'm saying an event is related to location. But the next thing that you can do is say, How many times is it related. So this is your $10 word for the day is cardinality. Which is basically the number of times something is connected. That's a very messy definition. But that's how I'm going to explain it. And you, you basically have four different options here is you can say it has zero or it has one, or it has zero, it has many, or it has one, or it has one, too many.

So any event, in our system, we might say, an event is always going to have one location, that you can't have an event without a location. So I'm going to write that there has one location. But is that true? Is there ever going to be event that might have more than one location? There's things like bar crawls where you have from location to location to location? How are we going to model something like that in our system?

You don't necessarily have to have the right answers, it's more important to be just asking the right questions here. So you can say even though we know that there's events with more than one location, for whatever reason, we're going to define it in our system as it's going to have one location, and then you can start to build up from that.

You can also do the reverse. So you're not just mapping the relationship one way, but you're mapping it in both directions, where a location can have multiple events going on at it.

So on every different day, you you might have the same location hosting different types of events. And as a user, you might want to say, Okay, so at this event, this location seems cool, what other events are going on at this location.

So you can see how this is used in designing navigation as well.

So then we can start thinking about the relationship between an event and the user.

Well, an event might have zero people attending if it's just created, or it might have many people attending if it's been created for a little bit. But then you can also again, like always be pushing back against these assumptions that you can say, like, well, is an event ever really going to have zero people? Because it has to be created by someone. And so wouldn't that person be attending the event anyway? So then do we have to design an empty state? Or would the connection be one to many?

Or is it zero to many? That answer again, it's not super important to get it right here. But it's more important to be asking those questions.

And for anything that has a connection of zero, that means that you know that once you get into the interface design part, you will have to design an empty state for what happens when is zero, are you going to hide that information, or you're going to show it in some type of disabled way like graying out the text in you.

So you're sort of making a to do list of things that you'll have to remember, once you get to the interface design, that's what that's one of the things I really like about this method is, because it's the only framework I've seen, that gets really, really explicit about saying when something will have an empty state and when it will not.

And so we can go back through this process, say, okay, so then the reverse connection is how many was a connection between a user and event? Well, a user might have a new account, and they aren't attending anything, or they might have a ton of events that they're attending.

So you know, that you'll have to that you'll have a page that has all of their events on it. And then that will link to the event. So it can give you like full information about about it and stuff.

So this process is called system mapping. This is great for getting a high level view of the core objects in a system and the most important relationships. It's not very scalable. So it works great with about three objects, the next thing that we want to do is be the connection between the user and location.

And once you start to add more and more objects of this, it'll turn into just a whole bunch of spaghetti noodles and won't be intelligible at all.

So I'm going to switch to a different thing that you can do, which is, you'll want to map out the full relationship of all the different objects in your system. And you can do that using what Sophia, Peter calls the nested object matrix.

So I'm going to bring in those connections that we already made. And then basically, you go column by column to build out all the connector to find other connections in your system.

So a user and a user, is there any connection there? Well, there might be, we might want to say, we have some sort of social network going on in our system and that users can follow other users users location, is there any connections that we can there? Well, maybe maybe we want a way for users to favorite locations, because that that location hosts a whole bunch of great events. Any event, an event? Is there any time that maybe that might be related to another event? Well, maybe there aren't events that have our biannual or weekly or monthly, and so you might want events have a way to link to previous versions of itself. So this starts to replace or is a different way of creating a sitemap.

So like a Sitemap has the problem of it is very difficult to create the full list of all the connections in the system.

So when you have cross links going on in the sitemap, usually you'll have one representative cross linked. Because if you add cross links for every single connection, the diagram just becomes unintelligible anymore, there's too many noodles going on.

So this lets you have a really scalable way of building a full list of all the connections that are going out in your system.

So from here, we finally get to the call to action, the verbs part of this process.

So here, we want to answer the question of what affordances do our objects require? So I'm going to go through this pretty quickly because I'm running low on time. But basically, you'll go through a similar process that we did for the noun foraging, where are you doing Call to Action foraging to find out what are all the verbs that users will need to take, or what are all the actions that users will need to take on these different objects.

So on a user object, either we'll be able to like follow and share events with them in this example, for any event, they'll be able to register for the event.

And you can, this is another part that I really love about oh, UX is because it's so it pairs so well with many different types of research methods. So here, if you have that jobs to be styled, or jobs to be done style interview library built up, you can easily bring in that information and start to map out all the different tasks that are going on in your system and what objects those tasks are related to.

And so this model works great if you are designing for one user role, if you are designing for more user roles. So if you've ever had a question like oh, okay, so this seems cool, but how are the administrators going to work with it? That is a question that I have been asked and had not thought of, did not realize that would be something that I was supposed to think of.

What what this ORCA process has is a matrix just like we had for the for the object matrix. But now this top row is going to be all the different roles that we have in our system.

And then beneath that we can say, we can look at the role, the object, and what actions we'll have to attach to that object for this role. So an attendee might have actions like following and sharing events. But an admin might have actions that are more moderator heavy, where they can suspend an account or delete an event.

And then a host will have stuff like creating event and adding locations and things like that.

left off at about 27:32

So what is the purpose of doing this?

Again, I really love that this object oriented UX, this ORCA process, it builds you this definitional information about what everything is.

So this, some of this seems obvious, but this is something that you will find throughout different products is not happening.

So one example is New York Times they have these really, really, really great articles, they have a great design team, great data visualization team. And they'll make these articles that are very in depth about very niche topics and just have great explainers for what's going on.

So in this example, they had about a year ago, they had a article about how safe it is to fly during COVID.

So it starts out with this image of a plane, and then it zooms in to this 3D model of a plane and it starts having all these infographics about the airflow of how air flows within an airplane.

And they have great content designed to where they highlight certain words, and then highlight things in the model and that same color so you can see directly like what they're talking about.

I think that these articles are all so cool, but one thing is you can't do to the articles β€” there's no way to save them, the template that they have for these types of articles has no bookmark option or no save button or if they do, I cannot find it is the most frustrating thing.

These are some of the coolest articles that The New York Times publishes, there's so many people that work on them, and there's just no there's just no way to save them.

And so using Oh UX that would be like an article object and would have those actions like saving defined, and you just would not have a variation of this without without those affordances added to it. So going on to our attributes.

So this is what information do our objects hold.

Again, you'll do attribute foraging and find out what types of content metadata you want to add to all your different objects.

And then from there, you can do that page description diagram type thing that ranks the hierarchy of your content and your objects and saying what is most important here.

And gain, it pairs with other methods as well. So you can use things like card sorting, for pretty much all of these steps, and you can also use it here. You can also use surveys and dot voting to get really informed decisions about what is the most important things that we have going on in these objects.

And so you can start to see how these will shift as you as you rank the importance of different things attached to this object, and then from here, you can take all this information, and basically turn it into a Lo Fi interface.

So here that I'm just expanding that information and kind of arranging it on the page.

For every object, you'll end up creating basically three different versions of it, where this is the page, the page details version of an event.

If I go to the next slide, this is what a card might look like, we're now I just have maybe the five most important things on that object that I'm showing.

And then from there, you'll go and make a list, which is basically a whole bunch of cards, and thinking about what you might sort those things by and what you might filter things by.

So that's all I have to say. That is basically the first 90% of OOUX if you want to learn the other 90% go to OOUX.com.

Sophia Prater teaches a course and has a whole bunch of resources that she shares.

She also has a great podcast and videos that she uploads to her YouTube channel. And if you want to get in contact with me, that's my information out there. So thank you so much.

Carissa Merrill

Thank you, Joey. That was amazing. That was so cool. What a fabulous way of thinking around like the construction of things and understanding wayfinding let me just skew through. I think there were some questions. Let me see. rather hear we have more, again, a comment. I can imagine that that object oriented UX helps manage scope creep, because it's easy to compartmentalize with the objects model?

Joey Pearlman

Yes, I would agree. And one thing I meant to mention earlier on is that for those other frameworks, like Jobs to be Done, or like, anytime we are thinking really heavily about the past and the verbs, it's really easy to get focused on these niche features and just forget to link them to other things that are very closely related.

So by using this method, you're you're kind of always thinking about other things in your in your product, and are easily able to build that cohesive thing that can access anything.

Carissa Merrill Totally, that makes sense. And then Sudha mentioned a very interesting method to lead into affinity diagram as well. And diagramming as well.

Joey Pearlman Yes, absolutely. You can definitely use affinity diagramming for for a lot of this stuff.

Carissa Merrill Very nice. All right. Well, thank you again, Joey. That was great. And yeah, definitely was very vibing and appreciated the examples that you showed and and the reference to Free Willy because how can that not be a very positive knew that? Yes, way to know your audience waiting waiting on your audience.

Intro to Object Oriented UXβ€” World IA Day 2022 β€” Twin Cities, Minnesota

Transcription

Carissa Merrill β€” Conference host All right team and I see Joey's on ready and raring to go. I love it. Thank you so much. Welcome back, everyone. We are about to kick off object oriented UX with Joey Perlman.

Thank you again to everyone for coming out today. It's been such a fabulous time, I was just messaging with student one on one about just like how incredibly grateful I am. And we all are that y'all not only are choosing to share such fabulous content, but also that so much so many of the community are available to come in, to come in, share the experience with us and give feedback and learn together. So just over the moon with gratitude.

So thank you all so much for making this day. So fabulous. All right, onward. Here's Joey.

Joey's a designer that is passionate about content systems design and design systems. Joey earned his UX certification from Prime digital Academy, where he now helps guide new students through the program as a UX program coach, when he's not compulsively collecting and sometimes reading books on design. He's fighting the ever present temptation to buy audiophile accessories that make music sound imperceptibly better at frequencies humans almost definitely can't hear. All right, I will turn it over to you.

Thanks, Joey.

Joey Pearlman β€” Presenter Thank you. Alright. So I'm going to start my screen share and just want to double check my audio is coming through on these air pods right. Okay, sweet. All right.

So welcome to an Intro to Object Oriented UX. And also happy World IA Day.

Really excited about this.

So about me, I graduated prime in August 2020. I work at Prime currently as a program UX program coach and I just finished a contract working on agency working on education products.

And on that contract, I had kept on running into issues about basically, we would make new features, I would pass those off to developers and they would ask me questions about Okay, so we have this new feature, how's it going to link to these other pages? And or is it going to show up on this page as a card? Or is it going to show up over here as a list? Or what do we do with this information? We don't have it is empty.

So I started reading a lot about IA stuff. And it was really trying to hone those skills. And I went back into that project thinking that I had a whole bunch of IA information I would do great.

And I kept on getting the same questions of Okay, so what do we do? And this is empty, how will this link to these other things?

I was like, Oh my God, this must be because, you know, I'm still sort of a new newish design. I'm sort of newish to the field, there's probably, this is something that I still just have to build up over time. There's not any silver bullet that's going to instantly solve all those problems for me.

And then I found Oh, UX, I was like, Oh my God, this silver bullet solves all these problems for me.

So let's dive into this a little bit. So object oriented UX is a philosophy or framework of viewing interfaces as a system of objects.

It was created by Sofia Prater, she started this in this 2015 article, object oriented UX published analyst apart and since then, she's continually evolved in and built in iterated upon this framework. She currently has like a very, very great course that goes into so many details about this process, and also has a podcast and YouTube channel and just is continually adding and sharing more information about it.

The very quick summary is that it combines some information from object oriented programming framework that engineers use of saying the things in our system are basically objects and containers of information that will link to other things, and combining that type of thinking with UX methods to create this really powerful and robust and simple framework that you can use to build up the spray information architecture for your products.

So before diving much deeper into Object Oriented UX, let's talk a little bit about objects.

Objects in the physical world help us to do a whole bunch of stuff, they help us to understand, interpret, and move through our environment.

So if you walk into a coffee shop, the first thing that you do is you're looking around, find where the walls where the doors where the tables where the chairs were the people. And then from there, you're able to say, Where's the table, I want to sit up, where's the person I want to talk to where's the door that I want to walk through, and you're able to navigate around this environment because you're recognizing all these objects.

They also help us find related objects. So if you have a spot in your home, where you keep your pocket and your hands, it's probably going to be really close to the spot where you keep your forks and your knives and your plates and your glasses. It would be very odd to have a room where you keep your frying pan and then in the attic, you have your spatula.

You want those to be near each other because those objects are related to each other.

And objects in the physical world, they also help us understand what their design helps us understand what actions and objects fail for. So a handle on a suitcase is an affordance, for lifting it, switch on a light switch is an affordance for turning it on and off.

So let's compare that to the digital world.

In the digital world objects help us to understand, interpret, and move through our environment. So one example is just the iPhone home screen where you open it up and you have all these different objects on your screen that you can go into an explorer and then go back out, walk back out to and kind of walk through your whole library. Another example might be a usability test for a website, a lot of the time, they'll run in this way where unless you explicitly ask your park participant not to do anything, they'll go to this website, the very first thing that they'll do is they'll scroll up and down, because they want to get a sense of what this environment is and what all the objects are, and what information might be available to them.

Digital objects also help us find related objects. So one example is Google. So if this happens to me all the time where I'll be thinking of a film, but don't remember the name, I'll be thinking of an actor, I don't remember their name. But I'll be able to remember, a film The actor was in a decade ago, and from there and able to kind of connect those pieces and say, Oh, Ethan Hawke, or snow falling on cedars bass, sorry, Ethan Hawke, who was then in this other film, The before trilogy, which is the one that I was thinking about, I can never remember the name of.

So objects in the digital space help us with those interconnections between those pieces of information.

And digital objects also help us understand what actions an object is built for.

So if we look at the Netflix card, it has all these affordances to allow us to play it, read it, review it, and add it to our list to watch later.

So if you didn't notice, these features are all identical between the physical and the digital space, there is a huge overlap between the way that we think about objects in the physical world, and the way that we see them in the digital world.

And this overlap isn't immediately obvious. And hearing it for the first time was just conceptually like mind blowing for me.

So objects are foundational, and the human brain really wants to interpret things as a whole bunch of objects that we can interact with.

But most design frameworks don't start with objects.

So let's dive into a little bit about how OOUX is different from other design frameworks.

So there are some common methods, some common design methods.

One is the jobs to be done framework, where it focuses really on the unmet needs of the user.

So basically, you do a whole whole whole ton of research, you'll end up with a very, very long list of tasks and unmet needs. And basically, things that your users want to do, that they aren't currently able to do or don't have a great way of doing now.

And then you're able to kind of reverse engineer it and say, Okay, so this is what people want to do. So this is how the things that we need to design for.

Story mapping is kind of similar, where it's mapping out the required series of actions to complete a task. So you'll end up with a whole bunch of sticky notes that line up and say, basically, to do this one thing, a user will first do this, and then they'll do this, and then they'll do this.

And then we also have job stories, which is this format of writing the stories from a user's perspective of when I blank, I want to blank, so that blank, and you basically get this context, task context sandwich.

And what all of these things have in common is that they're very focused on the tasks, but it's the voice from the user's mental models and the way that they're thinking about the optics on the system and things like that.

So you basically, you're starting at this endpoint of we want the user to be able to do this thing, and then kind of reverse engineering from there to build backward to say what do we have to build in our system to support that?

What OOUX does is it kind of flips the script, where it says, the very first thing that we want to focus on are the things that the users are going to manipulate the objects that they think about their mental model. And from there, we'll go on to build out those other things.

So the object oriented UX way of looking at the world is basically seeing it through the lens of these four different types of components.

So first, there's objects. These are basically the things that you have going on in your system.

Then there's relationships, which is now that you have all the objects in your system, how are they all connected to each other? How are they related?

Then there's calls to actions where now that we've have the objects, we have our things, we have the connection between things, what actions will users want to take on those objects?

And then finally, we get into attributes, which is what these these objects hold. They're just like in the physical world, you would have a box or mason jars or whatever that holds things. These objects are also holding things. But what most objects are holding our information. That information is things like names and images and content, and metadata like date created and things like that.

So let's dive just quickly a little bit deeper into into these four things.

So objects, these are going to be the things in your system, the nouns. And you can find these by primarily by talking to people and doing research, interviewing your stakeholders interviewing your users, you can also find look at how similar products might define there.

You can also use things like competitive competitive analysis, to look at how competitors where objects might exist in those systems. And after you've built out a library of all your all the objects that you're going to have in your system, can start build out relationships and say, how are those objects connected to each other?

And then you can start thinking about what are the affordances those objects are going to offer to our users? So what verbs, what actions do our users need to take? And how can they do that directly on this topic that they're looking at?

And then finally, you'll think about the information that the object contains. So those are going to break down into two attributes are going to think break down into two categories, content, which are things that make up that give an instance of an object, its uniqueness.

So if you're working on a blog, or a news website, articles, and blog posts are going to be really important objects in your system. And the things that make each article and blog posts unique are going to be these content pieces. So things like the name or the headline, the actual text on the article, images and videos.

And then metadata is things that you can sort and filter by. So things like the date that they were posted, or the date that they were edited, and things like that.

So going back again, I'm going to run through this one more time, because it's very important is we have objects, and those are, those are basically the nouns in your system, we have relationships, those are the connections between all your objects, we have calls to action, which is basically your verbs. And then we have attributes, which is content or metadata.

And taking all these four things together, forms this acronym, ORCA. And this orca process is the core process of OOUX.

It's a series of methods to define the mental models and the objects in your system, the relationships that they have to other objects, what calls to action are offered through affordances, and how content and metadata are prioritized.

And if you're looking at this, and thinking, Orca, that reminds me of one of the main characters from the classic 1993 family film Free Willy, the story of troubled orphan youth, and a friendship you could never imagine. totally right. If you can understand Free Willy, you'll understand the process, I don't make the rules. That's just how it goes.

So going back to this, at the end of this process, you will end up with a basically a whole bunch of sticky notes, and a column of sticky notes that looks something like this, where you have the object that you're defining, all the objects that is connected to, the verbs that are connected to that object, and the content and metadata that make up the object.

And from here, you can start to do prioritization. So there was about a decade ago, there was short trend, that… sorry, zoom, zoom message just popped up so participants can now see your screen. And I started panicking that I haven't been sharing my screen this whole time.

About a decade ago, there was a thing called a page description diagram. And it was basically a really kind of short lived design fad of when thinking about a page, you would go through the process of ranking the pieces of content that will go on that page. So we would have like a column for priority one. One or two pieces can be priority one, and then everything below that, that would be priority two and five pieces can be priority two, and then below that is priority three, and priority three is going to go underneath priority one and two.

And that process is done a lot in the back of a lot of designers heads. But this makes it explicit. And you can do that same type of thing here.

So now that you've like really defined things about it, you can start to rank these attributes and kind of reorder them and say, This is the most important thing. So it's going to go on top of this list. This is related or the second most important thing. So it's going to go there at the top as well, I think can take that and turn it into kind of a low fi wireframe that you can use to communicate and get feedback and find out what what pieces Am I missing.

And the the purpose of doing it like this is that you have this really explicitly defined hierarchy of everything on your page, which prevents you from rearranging things for no reason basically.

So Sophia Prater has this great term called shapeshifters, which is objects on the web that will change shape for basically no reason. So one example is Amazon, you probably know them as an organization that continually overworks and underpays workers and uses devious tactics to prevent labor from organizing and forming a union. But they're also known for selling books.

So this is the page I think of when I think of the product page for Amazon.

So on the right hand side, you have the add to cart Buy Now stuff and at the very bottom at the Add to List. They also have other variations of this page.

So this is just this is one of those variations where it's very similar. On the right hand side, you have the Buy Now thing you have other buy actions, like the quantity and buy for others. But what's missing from here is that this Add to List button. This is just not over here on this right hand side.

First time I saw this design, I thought I thought that they removed wishlists for me and was like, Why? And it's actually hiding way over here on this bottom left hand corner.

And so that is very disorienting and very annoying. And it's bad enough that they do this once, but they actually have more variations. So if I want to click onto this tab here, now this is a completely different reshuffling of all that same information where the price and this page is at the top right, if I go to the next tab, it's now on the left hand side. And there's really no reason to reshuffle this information there.

On occasion, it might make sense if you have really good reasons. But by having this like defined hierarchy that you can stick to forces you to not deviate from that hierarchy unless you have a very, very good reason to do so.

So, so that is the intro to OOUX.

Now let's talk about how you would actually apply it in a project.

So the first step of UI UX is that ORCA process, So now we're hopping into that ORCA process that I mentioned earlier. So we're going to start with objects, and talk about defining our objects.

So the very first step is called noun foraging.

I think that's such a great name, which is basically you're going to get scrappy, you're going to do interviews, you're going to look at competing products, you're going to find all the types of nouns that you can possibly add to the system.

Primarily you're going to be doing this through interviews, that's interviews with stakeholders, interviews with users.

And here, I just have two fictional interviews I wrote, I'm not going to go into in depth, because I'm going to switch to a different example soon. But basically, this is an interview with a stakeholder an interview with a student, and you'll read through your transcripts from your interviews, and just highlight all the nouns that appear here.

And then this is part that, you know, that lets you know that this is really a design method is that you'll turn everything into a sticky note.

So you'll end up with a slew of sticky notes, that you can then start to do affinity diagramming. So you can rearrange things, so that related things are closer together. Then you can start to interrogate are these things really related? Or are they actually the same?

So here I have these objects, Professor, teacher and instructor. So one question is, is an instructor and a professor? And they both teachers, or is a professor a slightly different role than instructor? And do they have slightly different needs?

Or maybe it's not slightly, maybe it's a significant difference between these two things.

And so that is a question that you can ask really early on, and then start to plan out questions for your research to make really great informed decisions as you continually build up your product.

So in this case, I'm going to say, yes, these are all teachers and teacher is now going to be like the defined vocabulary that we're going to use for this thing.

As you go through this process, you might also say, Oh, actually, I had this noun, English Department. That's actually an example of a building for this.

This Jane Appleseed. This is actually an example of a student. And earlier I had grades. This actually might be metadata that lives on an object they didn't have already, like an assignment object.

So you, you have this really great way to build a great knowledge of your system, and continually ask questions to make sure that you're doing the right thing.

Another thing I like about this is that because everything is sticky notes, it's very low stakes. If you make a mistake, you can take the sticky note off, you can erase it, you can write over it, you are not making decisions that is going to impact somebody's next two weeks to rework something or anything like that.

It's okay to be wrong. Because you'll you'll go on and continue to test and iterate throughout this process.

So after you have this, you'll go into relationships. And this is where I'm switching to a completely different example.

So in this example I have, say that you're working on a product that is going to host events. So some important objects that that product might be an event, a location, and a user. And after you have these defined, you can start to say, what are the connections between these different things? So an event, how is that related to location? Or, here I'm saying an event is related to location. But the next thing that you can do is say, How many times is it related. So this is your $10 word for the day is cardinality. Which is basically the number of times something is connected. That's a very messy definition. But that's how I'm going to explain it. And you, you basically have four different options here is you can say it has zero or it has one, or it has zero, it has many, or it has one, or it has one, too many.

So any event, in our system, we might say, an event is always going to have one location, that you can't have an event without a location. So I'm going to write that there has one location. But is that true? Is there ever going to be event that might have more than one location? There's things like bar crawls where you have from location to location to location? How are we going to model something like that in our system?

You don't necessarily have to have the right answers, it's more important to be just asking the right questions here. So you can say even though we know that there's events with more than one location, for whatever reason, we're going to define it in our system as it's going to have one location, and then you can start to build up from that.

You can also do the reverse. So you're not just mapping the relationship one way, but you're mapping it in both directions, where a location can have multiple events going on at it.

So on every different day, you you might have the same location hosting different types of events. And as a user, you might want to say, Okay, so at this event, this location seems cool, what other events are going on at this location.

So you can see how this is used in designing navigation as well.

So then we can start thinking about the relationship between an event and the user.

Well, an event might have zero people attending if it's just created, or it might have many people attending if it's been created for a little bit. But then you can also again, like always be pushing back against these assumptions that you can say, like, well, is an event ever really going to have zero people? Because it has to be created by someone. And so wouldn't that person be attending the event anyway? So then do we have to design an empty state? Or would the connection be one to many?

Or is it zero to many? That answer again, it's not super important to get it right here. But it's more important to be asking those questions.

And for anything that has a connection of zero, that means that you know that once you get into the interface design part, you will have to design an empty state for what happens when is zero, are you going to hide that information, or you're going to show it in some type of disabled way like graying out the text in you.

So you're sort of making a to do list of things that you'll have to remember, once you get to the interface design, that's what that's one of the things I really like about this method is, because it's the only framework I've seen, that gets really, really explicit about saying when something will have an empty state and when it will not.

And so we can go back through this process, say, okay, so then the reverse connection is how many was a connection between a user and event? Well, a user might have a new account, and they aren't attending anything, or they might have a ton of events that they're attending.

So you know, that you'll have to that you'll have a page that has all of their events on it. And then that will link to the event. So it can give you like full information about about it and stuff.

So this process is called system mapping. This is great for getting a high level view of the core objects in a system and the most important relationships. It's not very scalable. So it works great with about three objects, the next thing that we want to do is be the connection between the user and location.

And once you start to add more and more objects of this, it'll turn into just a whole bunch of spaghetti noodles and won't be intelligible at all.

So I'm going to switch to a different thing that you can do, which is, you'll want to map out the full relationship of all the different objects in your system. And you can do that using what Sophia, Peter calls the nested object matrix.

So I'm going to bring in those connections that we already made. And then basically, you go column by column to build out all the connector to find other connections in your system.

So a user and a user, is there any connection there? Well, there might be, we might want to say, we have some sort of social network going on in our system and that users can follow other users users location, is there any connections that we can there? Well, maybe maybe we want a way for users to favorite locations, because that that location hosts a whole bunch of great events. Any event, an event? Is there any time that maybe that might be related to another event? Well, maybe there aren't events that have our biannual or weekly or monthly, and so you might want events have a way to link to previous versions of itself. So this starts to replace or is a different way of creating a sitemap.

So like a Sitemap has the problem of it is very difficult to create the full list of all the connections in the system.

So when you have cross links going on in the sitemap, usually you'll have one representative cross linked. Because if you add cross links for every single connection, the diagram just becomes unintelligible anymore, there's too many noodles going on.

So this lets you have a really scalable way of building a full list of all the connections that are going out in your system.

So from here, we finally get to the call to action, the verbs part of this process.

So here, we want to answer the question of what affordances do our objects require? So I'm going to go through this pretty quickly because I'm running low on time. But basically, you'll go through a similar process that we did for the noun foraging, where are you doing Call to Action foraging to find out what are all the verbs that users will need to take, or what are all the actions that users will need to take on these different objects.

So on a user object, either we'll be able to like follow and share events with them in this example, for any event, they'll be able to register for the event.

And you can, this is another part that I really love about oh, UX is because it's so it pairs so well with many different types of research methods. So here, if you have that jobs to be styled, or jobs to be done style interview library built up, you can easily bring in that information and start to map out all the different tasks that are going on in your system and what objects those tasks are related to.

And so this model works great if you are designing for one user role, if you are designing for more user roles. So if you've ever had a question like oh, okay, so this seems cool, but how are the administrators going to work with it? That is a question that I have been asked and had not thought of, did not realize that would be something that I was supposed to think of.

What what this ORCA process has is a matrix just like we had for the for the object matrix. But now this top row is going to be all the different roles that we have in our system.

And then beneath that we can say, we can look at the role, the object, and what actions we'll have to attach to that object for this role. So an attendee might have actions like following and sharing events. But an admin might have actions that are more moderator heavy, where they can suspend an account or delete an event.

And then a host will have stuff like creating event and adding locations and things like that.

left off at about 27:32

So what is the purpose of doing this?

Again, I really love that this object oriented UX, this ORCA process, it builds you this definitional information about what everything is.

So this, some of this seems obvious, but this is something that you will find throughout different products is not happening.

So one example is New York Times they have these really, really, really great articles, they have a great design team, great data visualization team. And they'll make these articles that are very in depth about very niche topics and just have great explainers for what's going on.

So in this example, they had about a year ago, they had a article about how safe it is to fly during COVID.

So it starts out with this image of a plane, and then it zooms in to this 3D model of a plane and it starts having all these infographics about the airflow of how air flows within an airplane.

And they have great content designed to where they highlight certain words, and then highlight things in the model and that same color so you can see directly like what they're talking about.

I think that these articles are all so cool, but one thing is you can't do to the articles β€” there's no way to save them, the template that they have for these types of articles has no bookmark option or no save button or if they do, I cannot find it is the most frustrating thing.

These are some of the coolest articles that The New York Times publishes, there's so many people that work on them, and there's just no there's just no way to save them.

And so using Oh UX that would be like an article object and would have those actions like saving defined, and you just would not have a variation of this without without those affordances added to it. So going on to our attributes.

So this is what information do our objects hold.

Again, you'll do attribute foraging and find out what types of content metadata you want to add to all your different objects.

And then from there, you can do that page description diagram type thing that ranks the hierarchy of your content and your objects and saying what is most important here.

And gain, it pairs with other methods as well. So you can use things like card sorting, for pretty much all of these steps, and you can also use it here. You can also use surveys and dot voting to get really informed decisions about what is the most important things that we have going on in these objects.

And so you can start to see how these will shift as you as you rank the importance of different things attached to this object, and then from here, you can take all this information, and basically turn it into a Lo Fi interface.

So here that I'm just expanding that information and kind of arranging it on the page.

For every object, you'll end up creating basically three different versions of it, where this is the page, the page details version of an event.

If I go to the next slide, this is what a card might look like, we're now I just have maybe the five most important things on that object that I'm showing.

And then from there, you'll go and make a list, which is basically a whole bunch of cards, and thinking about what you might sort those things by and what you might filter things by.

So that's all I have to say. That is basically the first 90% of OOUX if you want to learn the other 90% go to OOUX.com.

Sophia Prater teaches a course and has a whole bunch of resources that she shares.

She also has a great podcast and videos that she uploads to her YouTube channel. And if you want to get in contact with me, that's my information out there. So thank you so much.

Carissa Merrill

Thank you, Joey. That was amazing. That was so cool. What a fabulous way of thinking around like the construction of things and understanding wayfinding let me just skew through. I think there were some questions. Let me see. rather hear we have more, again, a comment. I can imagine that that object oriented UX helps manage scope creep, because it's easy to compartmentalize with the objects model?

Joey Pearlman

Yes, I would agree. And one thing I meant to mention earlier on is that for those other frameworks, like Jobs to be Done, or like, anytime we are thinking really heavily about the past and the verbs, it's really easy to get focused on these niche features and just forget to link them to other things that are very closely related.

So by using this method, you're you're kind of always thinking about other things in your in your product, and are easily able to build that cohesive thing that can access anything.

Carissa Merrill Totally, that makes sense. And then Sudha mentioned a very interesting method to lead into affinity diagram as well. And diagramming as well.

Joey Pearlman Yes, absolutely. You can definitely use affinity diagramming for for a lot of this stuff.

Carissa Merrill Very nice. All right. Well, thank you again, Joey. That was great. And yeah, definitely was very vibing and appreciated the examples that you showed and and the reference to Free Willy because how can that not be a very positive knew that? Yes, way to know your audience waiting waiting on your audience.

Intro to Object Oriented UXβ€” World IA Day 2022 β€” Twin Cities, Minnesota

Transcription

Carissa Merrill β€” Conference host All right team and I see Joey's on ready and raring to go. I love it. Thank you so much. Welcome back, everyone. We are about to kick off object oriented UX with Joey Perlman.

Thank you again to everyone for coming out today. It's been such a fabulous time, I was just messaging with student one on one about just like how incredibly grateful I am. And we all are that y'all not only are choosing to share such fabulous content, but also that so much so many of the community are available to come in, to come in, share the experience with us and give feedback and learn together. So just over the moon with gratitude.

So thank you all so much for making this day. So fabulous. All right, onward. Here's Joey.

Joey's a designer that is passionate about content systems design and design systems. Joey earned his UX certification from Prime digital Academy, where he now helps guide new students through the program as a UX program coach, when he's not compulsively collecting and sometimes reading books on design. He's fighting the ever present temptation to buy audiophile accessories that make music sound imperceptibly better at frequencies humans almost definitely can't hear. All right, I will turn it over to you.

Thanks, Joey.

Joey Pearlman β€” Presenter Thank you. Alright. So I'm going to start my screen share and just want to double check my audio is coming through on these air pods right. Okay, sweet. All right.

So welcome to an Intro to Object Oriented UX. And also happy World IA Day.

Really excited about this.

So about me, I graduated prime in August 2020. I work at Prime currently as a program UX program coach and I just finished a contract working on agency working on education products.

And on that contract, I had kept on running into issues about basically, we would make new features, I would pass those off to developers and they would ask me questions about Okay, so we have this new feature, how's it going to link to these other pages? And or is it going to show up on this page as a card? Or is it going to show up over here as a list? Or what do we do with this information? We don't have it is empty.

So I started reading a lot about IA stuff. And it was really trying to hone those skills. And I went back into that project thinking that I had a whole bunch of IA information I would do great.

And I kept on getting the same questions of Okay, so what do we do? And this is empty, how will this link to these other things?

I was like, Oh my God, this must be because, you know, I'm still sort of a new newish design. I'm sort of newish to the field, there's probably, this is something that I still just have to build up over time. There's not any silver bullet that's going to instantly solve all those problems for me.

And then I found Oh, UX, I was like, Oh my God, this silver bullet solves all these problems for me.

So let's dive into this a little bit. So object oriented UX is a philosophy or framework of viewing interfaces as a system of objects.

It was created by Sofia Prater, she started this in this 2015 article, object oriented UX published analyst apart and since then, she's continually evolved in and built in iterated upon this framework. She currently has like a very, very great course that goes into so many details about this process, and also has a podcast and YouTube channel and just is continually adding and sharing more information about it.

The very quick summary is that it combines some information from object oriented programming framework that engineers use of saying the things in our system are basically objects and containers of information that will link to other things, and combining that type of thinking with UX methods to create this really powerful and robust and simple framework that you can use to build up the spray information architecture for your products.

So before diving much deeper into Object Oriented UX, let's talk a little bit about objects.

Objects in the physical world help us to do a whole bunch of stuff, they help us to understand, interpret, and move through our environment.

So if you walk into a coffee shop, the first thing that you do is you're looking around, find where the walls where the doors where the tables where the chairs were the people. And then from there, you're able to say, Where's the table, I want to sit up, where's the person I want to talk to where's the door that I want to walk through, and you're able to navigate around this environment because you're recognizing all these objects.

They also help us find related objects. So if you have a spot in your home, where you keep your pocket and your hands, it's probably going to be really close to the spot where you keep your forks and your knives and your plates and your glasses. It would be very odd to have a room where you keep your frying pan and then in the attic, you have your spatula.

You want those to be near each other because those objects are related to each other.

And objects in the physical world, they also help us understand what their design helps us understand what actions and objects fail for. So a handle on a suitcase is an affordance, for lifting it, switch on a light switch is an affordance for turning it on and off.

So let's compare that to the digital world.

In the digital world objects help us to understand, interpret, and move through our environment. So one example is just the iPhone home screen where you open it up and you have all these different objects on your screen that you can go into an explorer and then go back out, walk back out to and kind of walk through your whole library. Another example might be a usability test for a website, a lot of the time, they'll run in this way where unless you explicitly ask your park participant not to do anything, they'll go to this website, the very first thing that they'll do is they'll scroll up and down, because they want to get a sense of what this environment is and what all the objects are, and what information might be available to them.

Digital objects also help us find related objects. So one example is Google. So if this happens to me all the time where I'll be thinking of a film, but don't remember the name, I'll be thinking of an actor, I don't remember their name. But I'll be able to remember, a film The actor was in a decade ago, and from there and able to kind of connect those pieces and say, Oh, Ethan Hawke, or snow falling on cedars bass, sorry, Ethan Hawke, who was then in this other film, The before trilogy, which is the one that I was thinking about, I can never remember the name of.

So objects in the digital space help us with those interconnections between those pieces of information.

And digital objects also help us understand what actions an object is built for.

So if we look at the Netflix card, it has all these affordances to allow us to play it, read it, review it, and add it to our list to watch later.

So if you didn't notice, these features are all identical between the physical and the digital space, there is a huge overlap between the way that we think about objects in the physical world, and the way that we see them in the digital world.

And this overlap isn't immediately obvious. And hearing it for the first time was just conceptually like mind blowing for me.

So objects are foundational, and the human brain really wants to interpret things as a whole bunch of objects that we can interact with.

But most design frameworks don't start with objects.

So let's dive into a little bit about how OOUX is different from other design frameworks.

So there are some common methods, some common design methods.

One is the jobs to be done framework, where it focuses really on the unmet needs of the user.

So basically, you do a whole whole whole ton of research, you'll end up with a very, very long list of tasks and unmet needs. And basically, things that your users want to do, that they aren't currently able to do or don't have a great way of doing now.

And then you're able to kind of reverse engineer it and say, Okay, so this is what people want to do. So this is how the things that we need to design for.

Story mapping is kind of similar, where it's mapping out the required series of actions to complete a task. So you'll end up with a whole bunch of sticky notes that line up and say, basically, to do this one thing, a user will first do this, and then they'll do this, and then they'll do this.

And then we also have job stories, which is this format of writing the stories from a user's perspective of when I blank, I want to blank, so that blank, and you basically get this context, task context sandwich.

And what all of these things have in common is that they're very focused on the tasks, but it's the voice from the user's mental models and the way that they're thinking about the optics on the system and things like that.

So you basically, you're starting at this endpoint of we want the user to be able to do this thing, and then kind of reverse engineering from there to build backward to say what do we have to build in our system to support that?

What OOUX does is it kind of flips the script, where it says, the very first thing that we want to focus on are the things that the users are going to manipulate the objects that they think about their mental model. And from there, we'll go on to build out those other things.

So the object oriented UX way of looking at the world is basically seeing it through the lens of these four different types of components.

So first, there's objects. These are basically the things that you have going on in your system.

Then there's relationships, which is now that you have all the objects in your system, how are they all connected to each other? How are they related?

Then there's calls to actions where now that we've have the objects, we have our things, we have the connection between things, what actions will users want to take on those objects?

And then finally, we get into attributes, which is what these these objects hold. They're just like in the physical world, you would have a box or mason jars or whatever that holds things. These objects are also holding things. But what most objects are holding our information. That information is things like names and images and content, and metadata like date created and things like that.

So let's dive just quickly a little bit deeper into into these four things.

So objects, these are going to be the things in your system, the nouns. And you can find these by primarily by talking to people and doing research, interviewing your stakeholders interviewing your users, you can also find look at how similar products might define there.

You can also use things like competitive competitive analysis, to look at how competitors where objects might exist in those systems. And after you've built out a library of all your all the objects that you're going to have in your system, can start build out relationships and say, how are those objects connected to each other?

And then you can start thinking about what are the affordances those objects are going to offer to our users? So what verbs, what actions do our users need to take? And how can they do that directly on this topic that they're looking at?

And then finally, you'll think about the information that the object contains. So those are going to break down into two attributes are going to think break down into two categories, content, which are things that make up that give an instance of an object, its uniqueness.

So if you're working on a blog, or a news website, articles, and blog posts are going to be really important objects in your system. And the things that make each article and blog posts unique are going to be these content pieces. So things like the name or the headline, the actual text on the article, images and videos.

And then metadata is things that you can sort and filter by. So things like the date that they were posted, or the date that they were edited, and things like that.

So going back again, I'm going to run through this one more time, because it's very important is we have objects, and those are, those are basically the nouns in your system, we have relationships, those are the connections between all your objects, we have calls to action, which is basically your verbs. And then we have attributes, which is content or metadata.

And taking all these four things together, forms this acronym, ORCA. And this orca process is the core process of OOUX.

It's a series of methods to define the mental models and the objects in your system, the relationships that they have to other objects, what calls to action are offered through affordances, and how content and metadata are prioritized.

And if you're looking at this, and thinking, Orca, that reminds me of one of the main characters from the classic 1993 family film Free Willy, the story of troubled orphan youth, and a friendship you could never imagine. totally right. If you can understand Free Willy, you'll understand the process, I don't make the rules. That's just how it goes.

So going back to this, at the end of this process, you will end up with a basically a whole bunch of sticky notes, and a column of sticky notes that looks something like this, where you have the object that you're defining, all the objects that is connected to, the verbs that are connected to that object, and the content and metadata that make up the object.

And from here, you can start to do prioritization. So there was about a decade ago, there was short trend, that… sorry, zoom, zoom message just popped up so participants can now see your screen. And I started panicking that I haven't been sharing my screen this whole time.

About a decade ago, there was a thing called a page description diagram. And it was basically a really kind of short lived design fad of when thinking about a page, you would go through the process of ranking the pieces of content that will go on that page. So we would have like a column for priority one. One or two pieces can be priority one, and then everything below that, that would be priority two and five pieces can be priority two, and then below that is priority three, and priority three is going to go underneath priority one and two.

And that process is done a lot in the back of a lot of designers heads. But this makes it explicit. And you can do that same type of thing here.

So now that you've like really defined things about it, you can start to rank these attributes and kind of reorder them and say, This is the most important thing. So it's going to go on top of this list. This is related or the second most important thing. So it's going to go there at the top as well, I think can take that and turn it into kind of a low fi wireframe that you can use to communicate and get feedback and find out what what pieces Am I missing.

And the the purpose of doing it like this is that you have this really explicitly defined hierarchy of everything on your page, which prevents you from rearranging things for no reason basically.

So Sophia Prater has this great term called shapeshifters, which is objects on the web that will change shape for basically no reason. So one example is Amazon, you probably know them as an organization that continually overworks and underpays workers and uses devious tactics to prevent labor from organizing and forming a union. But they're also known for selling books.

So this is the page I think of when I think of the product page for Amazon.

So on the right hand side, you have the add to cart Buy Now stuff and at the very bottom at the Add to List. They also have other variations of this page.

So this is just this is one of those variations where it's very similar. On the right hand side, you have the Buy Now thing you have other buy actions, like the quantity and buy for others. But what's missing from here is that this Add to List button. This is just not over here on this right hand side.

First time I saw this design, I thought I thought that they removed wishlists for me and was like, Why? And it's actually hiding way over here on this bottom left hand corner.

And so that is very disorienting and very annoying. And it's bad enough that they do this once, but they actually have more variations. So if I want to click onto this tab here, now this is a completely different reshuffling of all that same information where the price and this page is at the top right, if I go to the next tab, it's now on the left hand side. And there's really no reason to reshuffle this information there.

On occasion, it might make sense if you have really good reasons. But by having this like defined hierarchy that you can stick to forces you to not deviate from that hierarchy unless you have a very, very good reason to do so.

So, so that is the intro to OOUX.

Now let's talk about how you would actually apply it in a project.

So the first step of UI UX is that ORCA process, So now we're hopping into that ORCA process that I mentioned earlier. So we're going to start with objects, and talk about defining our objects.

So the very first step is called noun foraging.

I think that's such a great name, which is basically you're going to get scrappy, you're going to do interviews, you're going to look at competing products, you're going to find all the types of nouns that you can possibly add to the system.

Primarily you're going to be doing this through interviews, that's interviews with stakeholders, interviews with users.

And here, I just have two fictional interviews I wrote, I'm not going to go into in depth, because I'm going to switch to a different example soon. But basically, this is an interview with a stakeholder an interview with a student, and you'll read through your transcripts from your interviews, and just highlight all the nouns that appear here.

And then this is part that, you know, that lets you know that this is really a design method is that you'll turn everything into a sticky note.

So you'll end up with a slew of sticky notes, that you can then start to do affinity diagramming. So you can rearrange things, so that related things are closer together. Then you can start to interrogate are these things really related? Or are they actually the same?

So here I have these objects, Professor, teacher and instructor. So one question is, is an instructor and a professor? And they both teachers, or is a professor a slightly different role than instructor? And do they have slightly different needs?

Or maybe it's not slightly, maybe it's a significant difference between these two things.

And so that is a question that you can ask really early on, and then start to plan out questions for your research to make really great informed decisions as you continually build up your product.

So in this case, I'm going to say, yes, these are all teachers and teacher is now going to be like the defined vocabulary that we're going to use for this thing.

As you go through this process, you might also say, Oh, actually, I had this noun, English Department. That's actually an example of a building for this.

This Jane Appleseed. This is actually an example of a student. And earlier I had grades. This actually might be metadata that lives on an object they didn't have already, like an assignment object.

So you, you have this really great way to build a great knowledge of your system, and continually ask questions to make sure that you're doing the right thing.

Another thing I like about this is that because everything is sticky notes, it's very low stakes. If you make a mistake, you can take the sticky note off, you can erase it, you can write over it, you are not making decisions that is going to impact somebody's next two weeks to rework something or anything like that.

It's okay to be wrong. Because you'll you'll go on and continue to test and iterate throughout this process.

So after you have this, you'll go into relationships. And this is where I'm switching to a completely different example.

So in this example I have, say that you're working on a product that is going to host events. So some important objects that that product might be an event, a location, and a user. And after you have these defined, you can start to say, what are the connections between these different things? So an event, how is that related to location? Or, here I'm saying an event is related to location. But the next thing that you can do is say, How many times is it related. So this is your $10 word for the day is cardinality. Which is basically the number of times something is connected. That's a very messy definition. But that's how I'm going to explain it. And you, you basically have four different options here is you can say it has zero or it has one, or it has zero, it has many, or it has one, or it has one, too many.

So any event, in our system, we might say, an event is always going to have one location, that you can't have an event without a location. So I'm going to write that there has one location. But is that true? Is there ever going to be event that might have more than one location? There's things like bar crawls where you have from location to location to location? How are we going to model something like that in our system?

You don't necessarily have to have the right answers, it's more important to be just asking the right questions here. So you can say even though we know that there's events with more than one location, for whatever reason, we're going to define it in our system as it's going to have one location, and then you can start to build up from that.

You can also do the reverse. So you're not just mapping the relationship one way, but you're mapping it in both directions, where a location can have multiple events going on at it.

So on every different day, you you might have the same location hosting different types of events. And as a user, you might want to say, Okay, so at this event, this location seems cool, what other events are going on at this location.

So you can see how this is used in designing navigation as well.

So then we can start thinking about the relationship between an event and the user.

Well, an event might have zero people attending if it's just created, or it might have many people attending if it's been created for a little bit. But then you can also again, like always be pushing back against these assumptions that you can say, like, well, is an event ever really going to have zero people? Because it has to be created by someone. And so wouldn't that person be attending the event anyway? So then do we have to design an empty state? Or would the connection be one to many?

Or is it zero to many? That answer again, it's not super important to get it right here. But it's more important to be asking those questions.

And for anything that has a connection of zero, that means that you know that once you get into the interface design part, you will have to design an empty state for what happens when is zero, are you going to hide that information, or you're going to show it in some type of disabled way like graying out the text in you.

So you're sort of making a to do list of things that you'll have to remember, once you get to the interface design, that's what that's one of the things I really like about this method is, because it's the only framework I've seen, that gets really, really explicit about saying when something will have an empty state and when it will not.

And so we can go back through this process, say, okay, so then the reverse connection is how many was a connection between a user and event? Well, a user might have a new account, and they aren't attending anything, or they might have a ton of events that they're attending.

So you know, that you'll have to that you'll have a page that has all of their events on it. And then that will link to the event. So it can give you like full information about about it and stuff.

So this process is called system mapping. This is great for getting a high level view of the core objects in a system and the most important relationships. It's not very scalable. So it works great with about three objects, the next thing that we want to do is be the connection between the user and location.

And once you start to add more and more objects of this, it'll turn into just a whole bunch of spaghetti noodles and won't be intelligible at all.

So I'm going to switch to a different thing that you can do, which is, you'll want to map out the full relationship of all the different objects in your system. And you can do that using what Sophia, Peter calls the nested object matrix.

So I'm going to bring in those connections that we already made. And then basically, you go column by column to build out all the connector to find other connections in your system.

So a user and a user, is there any connection there? Well, there might be, we might want to say, we have some sort of social network going on in our system and that users can follow other users users location, is there any connections that we can there? Well, maybe maybe we want a way for users to favorite locations, because that that location hosts a whole bunch of great events. Any event, an event? Is there any time that maybe that might be related to another event? Well, maybe there aren't events that have our biannual or weekly or monthly, and so you might want events have a way to link to previous versions of itself. So this starts to replace or is a different way of creating a sitemap.

So like a Sitemap has the problem of it is very difficult to create the full list of all the connections in the system.

So when you have cross links going on in the sitemap, usually you'll have one representative cross linked. Because if you add cross links for every single connection, the diagram just becomes unintelligible anymore, there's too many noodles going on.

So this lets you have a really scalable way of building a full list of all the connections that are going out in your system.

So from here, we finally get to the call to action, the verbs part of this process.

So here, we want to answer the question of what affordances do our objects require? So I'm going to go through this pretty quickly because I'm running low on time. But basically, you'll go through a similar process that we did for the noun foraging, where are you doing Call to Action foraging to find out what are all the verbs that users will need to take, or what are all the actions that users will need to take on these different objects.

So on a user object, either we'll be able to like follow and share events with them in this example, for any event, they'll be able to register for the event.

And you can, this is another part that I really love about oh, UX is because it's so it pairs so well with many different types of research methods. So here, if you have that jobs to be styled, or jobs to be done style interview library built up, you can easily bring in that information and start to map out all the different tasks that are going on in your system and what objects those tasks are related to.

And so this model works great if you are designing for one user role, if you are designing for more user roles. So if you've ever had a question like oh, okay, so this seems cool, but how are the administrators going to work with it? That is a question that I have been asked and had not thought of, did not realize that would be something that I was supposed to think of.

What what this ORCA process has is a matrix just like we had for the for the object matrix. But now this top row is going to be all the different roles that we have in our system.

And then beneath that we can say, we can look at the role, the object, and what actions we'll have to attach to that object for this role. So an attendee might have actions like following and sharing events. But an admin might have actions that are more moderator heavy, where they can suspend an account or delete an event.

And then a host will have stuff like creating event and adding locations and things like that.

left off at about 27:32

So what is the purpose of doing this?

Again, I really love that this object oriented UX, this ORCA process, it builds you this definitional information about what everything is.

So this, some of this seems obvious, but this is something that you will find throughout different products is not happening.

So one example is New York Times they have these really, really, really great articles, they have a great design team, great data visualization team. And they'll make these articles that are very in depth about very niche topics and just have great explainers for what's going on.

So in this example, they had about a year ago, they had a article about how safe it is to fly during COVID.

So it starts out with this image of a plane, and then it zooms in to this 3D model of a plane and it starts having all these infographics about the airflow of how air flows within an airplane.

And they have great content designed to where they highlight certain words, and then highlight things in the model and that same color so you can see directly like what they're talking about.

I think that these articles are all so cool, but one thing is you can't do to the articles β€” there's no way to save them, the template that they have for these types of articles has no bookmark option or no save button or if they do, I cannot find it is the most frustrating thing.

These are some of the coolest articles that The New York Times publishes, there's so many people that work on them, and there's just no there's just no way to save them.

And so using Oh UX that would be like an article object and would have those actions like saving defined, and you just would not have a variation of this without without those affordances added to it. So going on to our attributes.

So this is what information do our objects hold.

Again, you'll do attribute foraging and find out what types of content metadata you want to add to all your different objects.

And then from there, you can do that page description diagram type thing that ranks the hierarchy of your content and your objects and saying what is most important here.

And gain, it pairs with other methods as well. So you can use things like card sorting, for pretty much all of these steps, and you can also use it here. You can also use surveys and dot voting to get really informed decisions about what is the most important things that we have going on in these objects.

And so you can start to see how these will shift as you as you rank the importance of different things attached to this object, and then from here, you can take all this information, and basically turn it into a Lo Fi interface.

So here that I'm just expanding that information and kind of arranging it on the page.

For every object, you'll end up creating basically three different versions of it, where this is the page, the page details version of an event.

If I go to the next slide, this is what a card might look like, we're now I just have maybe the five most important things on that object that I'm showing.

And then from there, you'll go and make a list, which is basically a whole bunch of cards, and thinking about what you might sort those things by and what you might filter things by.

So that's all I have to say. That is basically the first 90% of OOUX if you want to learn the other 90% go to OOUX.com.

Sophia Prater teaches a course and has a whole bunch of resources that she shares.

She also has a great podcast and videos that she uploads to her YouTube channel. And if you want to get in contact with me, that's my information out there. So thank you so much.

Carissa Merrill

Thank you, Joey. That was amazing. That was so cool. What a fabulous way of thinking around like the construction of things and understanding wayfinding let me just skew through. I think there were some questions. Let me see. rather hear we have more, again, a comment. I can imagine that that object oriented UX helps manage scope creep, because it's easy to compartmentalize with the objects model?

Joey Pearlman

Yes, I would agree. And one thing I meant to mention earlier on is that for those other frameworks, like Jobs to be Done, or like, anytime we are thinking really heavily about the past and the verbs, it's really easy to get focused on these niche features and just forget to link them to other things that are very closely related.

So by using this method, you're you're kind of always thinking about other things in your in your product, and are easily able to build that cohesive thing that can access anything.

Carissa Merrill Totally, that makes sense. And then Sudha mentioned a very interesting method to lead into affinity diagram as well. And diagramming as well.

Joey Pearlman Yes, absolutely. You can definitely use affinity diagramming for for a lot of this stuff.

Carissa Merrill Very nice. All right. Well, thank you again, Joey. That was great. And yeah, definitely was very vibing and appreciated the examples that you showed and and the reference to Free Willy because how can that not be a very positive knew that? Yes, way to know your audience waiting waiting on your audience.