Sophia Prater is a UX design consultant and chief evangelist of object oriented UX, a methodology that helps teams tackle complex design challenges. In this conversation, we discuss OOUX and how it differs from other methodologies.
- @sophiaux on Twitter
- Rewired (Sophia's consultancy)
- The Object Oriented UX Podcast
- Object-Oriented UX, by Sophia Prater (A List Apart article)
- Double Diamond
- Object Oriented UX Podcast, episode 10: Information Archaeology with Ren Pope
- Entity Relationship Diagram (ERD)
- The Elements of User Experience, by Jesse James Garrett (pdf)
- Conceptual Models: Core to Good Design, by Austin Henderson and Jeff Johnson\
Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.
If you're enjoying the show, please rate or review us in Apple's podcast directory:
This episode's transcript was produced by an AI. If you notice any errors, please get in touch.
Read the transcript
Jorge: Sophia, welcome to the show.
Sophia: Well, thank you for having me. I'm excited to be here!
Jorge: Well, I'm excited that you're joining us as well. For folks who might not know you, would you mind please introducing yourself?
Sophia: Yeah, sure. I'm a user experience designer. I was based out of Atlanta, Georgia, but I recently did a COVID move up to the north Georgia mountains. I am here in the beautiful... the bottom of the Appalachian Mountains. Kind of where the Appalachian trail starts. I'm very close to that.
I got into UX in 2009, which was a great time to be entering the field and really kind of what I'm known for is Object-Oriented UX. I wrote an article back in 2015 in "A List Apart." I had about, I guess, 15 minutes of fame on the internet where that article was one of the top articles for "A List Apart" for the year. It got retweeted and tweeted thousands of times.
I was very nervous to publish that article, because I did feel like I was turning the UX process — at least, what I considered the traditional UX process — I was sort of turning it on its head or turning it inside out. And I was really worried that people were going to throw tomatoes at me. But it really resonated with people, which was very encouraging to me.
I continued, pounding on this process that I had just started to use in my work and slowly over the years, it came to be that people would come to me as a consultant. I started my own... I finally left the corporate world. I had been at cnn.com as a UX designer. That was my only internal role, but I've been at a whole lot of agencies. And I started my own consultancy in 2014 and within a few years, that became what I was known for. So, companies would come to me to specifically get this type of UX design, Object-Oriented UX. And then I started teaching it, and I started teaching it at workshops. First at conferences, and then I started teaching workshops within companies. So, companies would bring me in. I recently had Facebook bring me in. I've had MasterCard, Credit Karma... a lot of big, exciting companies bring me in to train their team on Object-Oriented UX.
So, really that's 100% of my world now, is Object-Oriented UX. It is teaching it, delivering it to my clients, teaching it within the context of teams. Coming into a company... doing that online now. Used to do that in person; doing that all online. Spending a lot of time in Mural, moving sticky notes around there. And now I also teach individuals through a certification program that I was just getting off the ground right before COVID hit in March of last year. So now we're about a little over a year and we're in the middle of the fourth cohort of the OOUX certification program.
Jorge: Well, that's great. And we'll get into what Object-Oriented UX is in a moment, but I'm wondering why you think that the idea resonated so much with folks.
Sophia: Well, I think it resonated so much, the same reason it still resonates today. Is because this is a way to break down complexity. And I think traditionally, we break down complexity by verb, traditionally. By the actions we think about. What are all the things that a user needs to do in the system? And we can get into more of the why around this, but it's a much cleaner way to break down complexity by the noun as opposed to the verb. And I think a lot of user experience designers are thrown in — especially new user experience designers — are thrown into incredibly complex situations, domains.
My first project is a user experience designer, I still remember. It was with Blue Cross Blue Shield. And I was going to be designing a system for people that would design insurance packages. It was within insurance. It was a business tool within insurance, and I knew nothing about insurance. And I came on and I was expected to have wireframes by Friday. And I think that that is such a common struggle for user experience designers: they come in and wireframes are immediately expected of them. If they're working in an Agile environment, they're kind of like a wireframe factory or a feature factory. Just churn out those wireframes without a whole lot of time to gain understanding of the structure of the system. Really get an idea of the business rules and get into those business rules in a way that is collaborative and visual.
I think that that's what resonated so hard for people is they saw a way out of that. They saw a way out of that rat race or that struggle of constantly having to deliver wireframes and then having these conversations around the structure. You have stakeholders and engineers. You have the engineer reverse engineering, the wireframe to get the data model out of it, and then you have your stakeholders reverse engineering, the wireframe to try to get the business rules out of it. And then what you end up with is you end up with a whole lot of re-work because the wireframe is usually going to be wrong. And so, then you do the, what I call the "Bring me a rock game," where you're like, "Oh, okay, that rock is too big or too bumpy." Like, "Let me go get you a smaller, smoother rock!" And you go and say like, "Oh, is this the type of rock you're looking for?"
So, a lot of times information architecture, which is so important, but as you know, often in our industry and the user experience design industry, we don't do enough of that information architecture. And I think that this is a way to do information architecture in a visual way and in a collaborative way. So, you can bring your engineers and you can bring your stakeholders in and you can all sort of explore the complexity together and break down the complexity together and get out of that surface-level design work, where you're just moving wireframes around. And if you don't have that deep understanding of the system, you're just going to be moving the deck chairs around. You're going to be moving UI around. You're not going to be making systemic change.
And at the end of the day, UX designers are incredibly idealistic people. We want to make big change. We want to solve big problems, but if we can't figure out how to get out of that moving the deck chairs around on the sinking Titanic, then work isn't very much fun and we don't have a lot of meaning from it either; you can't draw a lot of meaning from it.
Jorge: I'm going to try and articulate it back to you to see if I'm getting it correctly, but the idea that there is a way for designers to work at a higher level of abstraction than how these things manifest in more tangible ways. How then does Object-Oriented UX fill that gap? Or asked another way, how do you introduce folks to what Object-Oriented UX is?
Sophia: Yeah, okay. So, what Object-Oriented UX is — And I want to differentiate Object-Oriented UX versus what I call the ORCA process — so, Object-Oriented UX is a philosophy; a philosophy that is based in the fact that people think in objects. And there is a lot of interesting research on that, that we can get into, if you want to ask about that, on cognition and how people think and how people understand the world. And a lot of that is based in objects.
So, for the philosophy part of it for Object-Oriented UX, if we say, "this is a philosophy that respects and acknowledges the fact that people think in objects. And to gain an understanding of an environment, you really need to understand what that environment is made up of. What are the objects that make up that environment? And thus, we need to make that clear in our digital environments, just like they're clear in our physical environments." So, Object-Oriented UX is all about defining what your objects are, figuring out what those are, what are the objects in the user's mental model, in the business model, those really valuable things.
And I need to kind of take a step back, I think, and define what is an object. I'm very specific when I talk about what an object is. An object is a thing that has value to the user. So, when I say objects, I'm not talking about your navbar or your calendar picker or your dropdown. All those things are valuable, but they are a means to an end. And I often say no user is coming to your site for your calendar picker. It could be the best calendar picker in the whole world, but that's not what they're coming for. They're coming for the event, or they're coming for the people that they can invite to the event.
So, an object is going to have... I use the acronym SIP. It's going to have structure, it's going to have instances, and it's going to have purpose. So OOUX is all about saying, "okay. If we know that our users think in objects and just human beings think in objects — not just our developers — human beings think in objects, and to be able to gain understanding, you need to understand what the objects are in that system. And to understand what the objects are we need a certain level of consistency and recognizability to our objects."
As the designers of these environments, if we don't get super clear on what our objects are, there's no way — there's just absolutely no way in hell that we're going to be able to translate that to our end users. We're just not! If we can't get it straight on our team and we can't get it straight among ourselves, then that's going to create a lot of communication problems internally, which is a problem that I hear all the time. We've got everybody on the team coming together. And some people, depending on what department you're in or what your role is, you've got the same object, the same thing being called two or three different things and different objects being called the same thing. And you're trying to design complex software. So just getting on the same page internally is going to be absolutely intrinsic to making sure that it's clear to your end users.
So, one kind of, I guess... not metaphor, but like journey that I could take you on, Jorge, and the listeners, is: imagine going into a coffee shop. And it's a coffee shop you've never been to. You walk into this coffee shop, but this is like, this is a funky coffee shop. Maybe it's a coffee shop in Amsterdam or something. And you walk into this coffee shop, and you can't tell the difference between the tables and the chairs, and the people. Like you know that there are tables and chairs and people there, you can see the things, but you can't tell the difference between them. And you can't actually tell the relationships between them either. You can maybe like, with intense concentration, you identify a chair, but you can't tell what table goes with what chair, right? Or you can identify a chair, but you can't understand the status of that chair. Is that chair occupied or unoccupied?
That would be a very difficult environment to navigate and to function in, yet we create digital environments like that all the time where it's difficult for users to understand, what are the valuable things to me here? What can I do to these things? How do these things relate? What are these things in context of this place? And what is the structure of these things? What is the status of these things? What are the attributes of these things? And that kind of gets into the ORCA process, which stands for: objects, relationships, CTA's, which is calls-to-action, and attributes. And that's the process that I use in my work, and I teach to design really awesome object-oriented user experiences.
Jorge: This analogy of the coffee shop is an interesting one, because I can contemplate it in the abstract, but in my real world experience, I've never been in a coffee shop where I can't tell the chairs from the tables or what have you. So, it does feel like a discussion that can get abstract quickly. And I'm wondering how do you draw the bounds around an object? Like how do you determine that something is a table in your systems so to speak.
Sophia: Right. and that is actually, I mean, saying, "Oh, we need to figure out what the things are." That's so much easier said than done. And that is a huge part of the ORCA process. We actually iterate on it, to say, "all right, how do we figure out what these things are?" And that is all going to come from research. So, the ORCA process is definitely a "garbage in, garbage out" process. You've got to have good research coming into it.
I often say that this is a good process for synthesizing your research before you get into design. If you think about the double diamond, you can literally see the weak link between the double diamond, right? Like, what happens after you get through research and then you just start sketching stuff — you just start designing. There needs to be something that happens between research and design, where you are synthesizing that research into structure and into information architecture.
And the ORCA process is just this really kind of like... it's like a meat grinder. Like you just throw the research in and... so when I was interviewing Ren Pope, he used the term "information archeology." And I love that. I feel like that's a lot of what this process helps you do is that information archeology, where you're taking all that research and you're analyzing that research to figure out what are your objects, what are the relationships between the objects, what can users do to the objects, and what are their attributes? And specifically with objects, like knowing, is a table a thing in this particular system that we're designing and in this environment that we're designing?
One of the first activities that we do is called "noun foraging." It's really fun. You take all that research, user interviews, interviews with your stakeholders, competitive analysis, analytics as well, of course current site audit, content audit as well is great to have if you have access to that. So, you're taking in all this research and you're looking for the nouns, and you're looking for the nouns that get used over and over and over again. And you're looking for synonyms like, "Oh! Are these the same thing or are these not the same things?" And then that turns into conversations to have with your stakeholders.
For example, I was working with a company called Blood Relay and basically what they do is they take blood samples... they're software, but they help facilitate blood samples being taken from the hospital to the lab and then getting the analysis back to the hospital. So, it's pretty complex business software with all the complexity that you get in healthcare and the healthcare industry. And when I was doing my noun foraging, I kept hearing the words "sample" and "product." Sample and product. Sample — product. And they were being used interchangeably. They were being used interchangeably by the business. They were being used interchangeably on the marketing site. They were being used interchangeably on the actual software in places.
And one of my big jobs in the beginning was to figure out, are these actually the same thing or are these two different things? Is there actually a relationship between these things and that came with conversations with the experts, right? So how do you define a product? How do you define a sample? Are these... and it turns out they are two separate things, and many products can be taken from a sample. So, you have that one-to-many relationship there. And that's so important to define. If I'm going to be designing software for this, I need to understand the difference between those and reinforce the truth of the world through that user interface.
Jorge: What I'm getting from your description of Object-Oriented UX is that it's not just articulating the domain as a series of nouns and relationships between them, but also expressing it in a sort of visual way, right? That allows people to get a shared understanding of that domain. Is that right?
Sophia: Right. Yeah, and that gets into some of the artifacts that we produce in the ORCA process. So, you know, Object-Oriented UX, you could use any methodology to say that eah, we need to define what the objects are, and we need to make them super clear within the interface. So, we don't get into that coffee shop scenario." Where, you know, if I'm designing software for a teacher, which, I did a lot of work in EdTech. If I'm designing software for a teacher and the important things for that particular problem domain that we're trying to solve for, are students' lessons, standards and parents, let's say. I want that teacher to open up that application and to immediately recognize those things. To immediately recognize the relationships and say like, "oh, okay. Yeah, this is just... this is how my world is." And then be able to do really amazing things. Have x-ray vision into those things. Have connections in a way that's super meaningful, and then to be able to do things to those objects that are more difficult in the real world without that tool, or that you know, it's just absolutely impossible to do without that tool.
Jorge: That step of articulating the understanding of the domain visually is not to be underestimated. It's a huge part of it. I'm certainly always on the lookout for new ways of doing it because it's so hard to do. I find that a lot of folks have a hard time thinking at that more abstract level.
Sophia: Yeah. And when you get into something like a system model or domain model, conceptual model. Basically, when you have lots of bubbles and arrows going? Entity relationship diagram, right? Which we do that work. That's part of the process. We build... I call it a system model, but it's basically an ERD. It often turns into a bowl of spaghetti, and it gets a little bit difficult to track, especially when there's multiple types of relationships between two objects. Then what do you do? Do you have multiple arrows, or do you have multiple labels on the same arrow?
I mean, God forbid your system has 17 objects in it, which if you're working in electronic healthcare records, if you're working in insurance... I have worked with tools before, or these, you know, these digital systems that we've had double digits of objects and that entity relationship diagram kind of breaks down. What also breaks down is if you try to start putting attributes in there. Which I've seen done before, where you actually blow out that ERD so it's not just your objects. You actually put your operations and your attributes into that document. That gets really crazy.
If you have an object that has 60 attributes, again, just the visualization of being able to show: what are the things, what are the relationships, what are the things made of. I don't necessarily think that diagram is the best way to visualize that and to do it in a collaborative way where everybody can be involved, your engineers can be involved, and especially your business folks. Getting those people involved early is gold. It's magic. Because that's when they're going to be the most useful.
So, I hear this all the time: One of my main problems... this is just a recurring theme when I've asked people, like, "What is the most annoying thing about practicing UX design?" Managing stakeholders. I hear that over and over again, and even that word, "managing" stakeholders. We should be leveraging our stakeholders. Our stakeholders and our subject matter experts... usually our stakeholders hopefully are some sort of breed of subject matter expert, at least from the business side. We want to be extracting all that knowledge from their minds, and we need to be doing that early on.
But what happens is we try to show them wireframes, or we present diagrams to them instead of getting them to co-create diagrams with us and to really feel heard early on in the process. And the thing is, is, your stakeholders are not trained and they're not good at giving you feedback on your wireframe. And it's very easy. You're conflating presentation and content basically, which we know not to do. We've known that for a long time, not to do that. And yet we still do that, and we still expect quality feedback from our stakeholders when they're looking at structure and design all at once.
Jorge: I'm glad you dropped the word co-create in there because as you were talking, I was thinking that the way that I approach the relationship with stakeholders is — or I try to at least — is as a collaboration, right? Where you engage their mind, expertise, their drivers, in the process of designing the thing. And to your point, for a complex system, that needs to start way before you're ready to put things down at the screen level. But there's this dilemma that it's hard to understand the implications of decisions until you see them reflected in something more tangible.
Sophia: Yeah, and I think that it's an uphill battle. Let's just say, I mean, they want, often, "they," stakeholders, business folks... they want to see the pictures. They want to see what does it actually going to look like? And I think we've trained them to want to see that. Just because we haven't figured out a really good way to involve stakeholders early doesn't mean it's not possible. I've seen success across so many of my students in bringing stakeholders in early by using the object mapping methodology and going through this process of figuring out... it's just it's color-coded sticky notes! That's really all it is. So, in really nicely organized columns. And it's scalable too. If you have 20 objects, that's okay. If you have 60 attributes on an object, that's okay, too. It really does scale nicely and gives you that sort of bird's eye view of the system.
I mean, the other thing that's just so important and not just for feedback, but it's so important to get your stakeholders involved early and your product owners — whoever those people, those decision makers are — on determining scope and timeline and budget. Because when you have a subject matter expert/stakeholder — I'll use those terms interchangeably, even though they're not always — I know they're not always, but if they're this close, if they've been working in the industry for 15 years or something and they say, "Oh, we're gonna create this new feature, we're gonna redesign this part of the product," it's difficult for them to really see the complexity and to understand the complexity. And if we can bring them on board with the complexity and also help elucidate assumptions, help them realize where are we making assumptions about our users…
So, I was mentioning before that the input of this process is research, right? And we start with the noun foraging and going through all that research, figuring out the nouns, and we're also looking for attributes at the same time. The ORCA process is a really great gauntlet too, to realize, you need to get kicked back to research. You're not ready to start designing yet because you're designing on too many assumptions. It pulls all those questions from the future where you might be figuring them out when you're in high-fidelity wireframes or something like that. Or God forbid, you're in production where you're figuring out some of these really sticky pieces of business rules.
So, this is a tool to help bring all those questions from the future, and make sure that your stakeholders potentially are coming up with those questions too through the process. They're right there with you. They're in the weeds, hands dirty, figuring out some of those questions, and this is going to be able to help you sell more research. Because selling research by saying, "We need to find out more about the user" — that is a really hard sell right there. That's super vague. "Oh, we need to get to know our user." "Great. Okay. Can we just design this product?" But if your stakeholder herself or himself says, "Oh, we don't really understand if... does a doctor work at multiple locations or does a doctor only work at one location? What's the relationship between a doctor and a location? We're assuming that the doctor only has one location, but we're actually not sure how much our doctors are moving around from location to location. Put that in a parking lot." That goes in your user interview transcript, okay?
And so, it's the actual stakeholder or the businessperson that has gotten invested in those questions. This is how you sell additional research by getting really specific about what are those questions that need to be asked.
OOUX and information architecture
Jorge: What you're describing seems very familiar to me, as an information architect, and I'm wondering... I revisited the A List Apart article in preparation for our conversation today, and I got the sense from that article that one of the distinctions between this methodology and something like information architecture is perhaps that... I'm going to use air quotes now, like "traditional information architecture" is more oriented towards content-heavy systems. And I'm thinking of like Jesse James Garrett's elements diagram, right? That is split into what he called information-oriented systems versus task-oriented systems. Would it be fair to say that this is more applicable to the task-oriented systems in that duality?
Sophia: So, yeah. I see where you're coming from. The naming around this is coming from… my background is in industrial design. I actually started as a product designer, designing refrigerators for Electrolux. Didn't last long in that career, but that's my background. And then I, again, like going back to the timing, so my very first job as a UX designer was in 2009. This is where Jesse James Garrett would have been like, "We're all UX designers." Right? So, that had already happened. I didn't find out about information architecture until years later. Okay, because just thinking about the timing of when I'm coming into this, I'm coming into it from a user experience perspective and also working on, yes, task-heavy products.
So, if you think about, you could even — and I often tell people — you can think about an object... The way I define an object, you can think about it as a content type. Now, I don't like the word "content type." I know this is going to be like controversial, but I prefer the term object, because if I'm working on a system — let's say for used car salesmen to manage their sales and their inventory — a vehicle is not a content type. A vehicle is a thing in a parking lot that is connected to customers, that is connected to sales events, that is potentially connected to other salespeople. Which salesperson sold this car? A salesperson isn't a content type. These are all actual things manifested in the real world and that we are using metaphor to reflect in our user interface.
That said, I have used Object-Oriented UX for 100% content sites. So, if we think back to the elections in 2012, when... that's how this all started, I was doing my very first responsive design for CNN election results. That was a lot of data viz, but that was all content. There was no user interaction there; it was all content. And that is actually... I guess the crucible for how I started thinking this way.
OOUX and conceptual models
Jorge: I'm familiar with another approach to this that I think is similar in at least in intent not in the form it takes, which is the one that I often refer to folks when talking about this stuff and it comes from Jeff Johnson and Austin Henderson's book, Conceptual Models. There you go; you've got it! Not fit for radio, but you're holding up the book cover to the camera. And I'm just wondering if you could speak to the differences between those approaches.
Sophia: Yeah, I think they kind of feed each other. I looked back over my notes on Conceptual Models, and most of it I'm underlining and I'm happy faces and check marks in the margins here. There were a couple of places where I like vehemently scribbled question marks. And like, "No, no, no!" But it's little things. I mean, if you think about a concept, the difference between a concept and an object. So, a concept can be... it just feels too... I don't know, the work that we do can often feel very ephemeral, very like it's… You just don't have something good and solid to hold onto. And the objects are these like anchors of understanding and getting super clear on what those objects are and making sure that you have really good lines around them. And actually, like one of the best things that we do in the process is make a glossary, like actually define these things.
Concepts though can like be a little squishy. Like financial literacy could be a concept, not an object though, right? The object might be like financial literacy quiz or something like that, you know? Or privacy can be a concept. Also, how Johnson and Henderson described building a conceptual model and what a conceptual model is versus the information that is captured in an object map. The conceptual model they describe it... it's kind of this chicken and egg thing. So, they look at task analysis first and build a conceptual model from the task analysis. I'm kind of the opposite: I tend to like to figure out what are the objects in this environment, in this domain, and hone in on the problem domain, sure. Get those big picture goals on what we are actually trying to do here.
But then figure out, "Okay, what are the things in this environment?" And then think about the tasks. What is it? What does a user need to do to those things? And we that's the "C" of ORCA: the calls-to-action. So, what actions — what are the affordances? — what actions does that object offer users? And that's how you get into the task. It's splitting hairs a little bit, but Johnson and Henderson do start off with that task analysis. Sometimes from research, if there's already user stories, we are analyzing user stories coming in. But if those aren't there, there's actually a point in the process that you can get user stories out of the ORCA process. So really just how concept is defined. Also, do you start with a task and then get the objects? I prefer to get the objects and then get the tasks. Start with the nouns. Start with those things and get really solid and clear on those and then figure out what the users want to do with them.
Jorge: I'm hearing two things there. One is that the idea of an object is easier to relate to then the idea of a concept, because concepts can be much more vague and more abstract. And the other, which — and by the way, I find both of these ideas really intriguing — the other is that, in some ways, starting with the objects might be a bit more open-ended than starting with the tasks. Because with a collection of objects, you're not necessarily enabling any one particular task; you could enable a myriad tasks, right? There's a collection of objects, and people can do things when they have several objects at their disposal — as opposed to thinking, "What do people want to do?" and then, "What objects do we need, or concepts do we need to enable that?"
Sophia: There's just so many fewer assumptions on figuring out what the objects are. Because you can go... I mean, if you can do ethnographic research, great. But going and doing your research again, going back to the teacher example, it doesn't matter what software I'm designing. Like, a teacher's world is made up of students, lessons, classes, standards, parents, other teachers — that's just the truth. And that's another thing Johnson and Henderson talk about the conceptual model being how the user thinks about the system and the task. And I am kind of a broken record when I'm talking about... I'm trying to find the truth of the system. I am trying to find — no pun intended — but like, the objective truth.
If I go back to the CNN elections example, if I'm going to build a conceptual model of how people think about elections that's going to be very different than what I would call a system model, which is going to be just the truth of the system. I went in in 2012, I built a system model and I use the exact same system model in 2016 because our electoral college had not changed. We still had candidates. We had states. We had races. And we had results. And we had ballot measures. Those things did not change. And the relationships between those things actually wasn't even up to the user. That's just the truth of the world. It's just our job to communicate what are these things and how do these things relate — versus, I think that the conceptual model is a valid thing to do, and that it would've behooved us to make a conceptual model of how people think about elections. But that's going to be different than what I would call the system model.
Jorge: I'm hating the fact that we're running out of time here, because this conversation is getting really meaty. When you brought up the phrase "objective truth," again, you can see this on the podcast, but I think my eyebrows shot up. Well, what you're describing there as a conceptual model is what I usually understand as a mental model. And we might have mental models that map to greater or lesser degree to what I understand of as the conceptual model, which is this set of relationships that you're describing, that I understand as standing together — regardless of what different people might think of them or how different people might understand them.
Sophia: In some systems... I mean, there's not just that objective truth, you have to go and figure out, like, what are the users actually want. So, if I had to think about a doctor, is a doctor related to one location in this particular context, or is a doctor related to zero to many locations. Maybe some doctors don't have a location at all associated with them. Some doctors are going to have three locations associated with them. So that's going to come from the users and like, what is the truth of the user? You know, again, it comes back to that objective truth and sort of balancing the objective truth of the business and the objective truth of what is happening with those users and what those users actually want and need. And then there's also the back and forth of like how much do we need to create an idea in the user's head? If this is a completely new thing, how do we reinforce that business model and how the business works so it's very, very clear to the users how these things work together. And then do we kind of go back the other way and really understand then the user's mental model of these things and reflecting it back in the system. So it is that kind of... it's a balancing act, for sure.
Jorge: Well, thank you. That helps clarify it quite a bit. And I still feel like we have more to talk about and I'm hoping that we'll be able to do so again at some point. For now, where can folks follow up with you?
Sophia: Probably the best, easiest place is ooux.com. So, if you go to ooux.com, and there's a green button, says something like, "Join the fam," or "Get involved," or something like that. I forgot what it says. All the good stuff is there. There's an Object-Oriented UX happy hour, so that would be a meetup — an online meetup. There is a podcast, the Object-Oriented UX podcast, newsletter, and of course the certification course as well. But just go to ooux.com and you'll find it. Also, @sophiavux is my Twitter.
Jorge: Well, fantastic. I'll link all those from the show notes. Thank you so much, Sophia, for being on the show.
Sophia: Thank you so much for having me.