Bob Royce Good afternoon. I'm Bob Royce, president of The Understanding Group. Daniel O'Neil And I'm Daniel O'Neil an Information Architect at TUG. Bob Royce Today we're going to talk about the why and how of object models as they relate to taxonomies. Daniel O'Neil We're grateful you're here, virtually, at least. Bob Royce Yeah, it's quite a different format this year, isn't it? We should start with a big shout out to all the people working behind the scenes who are staging this despite the crap that's going on around us. Daniel O'Neil Yeah, thank you. Bob Royce Thank you. So let's begin with a short discussion on the nature of taxonomies. Patrick Lamb uses the metaphor of a taxonomy being a lens that we use to perceive and talk about the world we live in. I love that idea of language being a lens into the world. Daniel O'Neil Yeah, it's tricky because some people would think of taxonomy as the as the final picture, but really, they give us pictures to learn about what is actually true, right? They bring us bring attention to details that otherwise we get lost in the complexity. So the assumption is that the truth is already there, we're just trying to sharpen and bring into focus, right? Bob Royce And so they can help us document and understand the system. They help us align our, our understanding with others, because is one of the I was trying to explain what we did to somebody and they're like, Oh, you would give us a structured way to talk about our world, right? When you give somebody that taxonomy, those key labels and how they relate. It's a structured way so that people can talk to each other in a shared language as opposed to talking past each other, like we so often do. And so taxonomies can be thought of as a lens is one metaphor and others are kind of map. Daniel O'Neil Right? And, you know, a good map doesn't try to capture all the detail, but it has to have a similar structure to the world. being mapped. It has to be a way of understanding Where you're trying to go with some agreed upon common reference? Bob Royce Yeah. And, you know, you'd never mistake this picture from Korzybski for Grey's Anatomy, but there's enough detail there to understand what it is, is being trying to communicate it that the way you position your body allows force to be applied in a particular way. And so, it's suffices, it works as a map of what needs to happen. Now taxonomies then are maps that are made of language, Daniel O'Neil Right. A linguistic map. And, you know, it's funny, we talked about the word linguistic here, and people think immediately of collections, whereas like paragraphs and things like that linguistic just means that you ultimately can express the understanding using language, but you might still use a visual model. It's just what's really important that helps us understand the domain by highlighting how important structures in the domain relate to each other and ultimately languages way to describe that in any model, you're gonna have to turn into language in order to really map it to make sure it's accurate. Bob Royce Yeah, yeah. And so the value then of the map is how well do those abstractions correspond to the structures of the territory? That's actually covered? Daniel O'Neil Yeah. all languages in itself and obstruction always is, right. Yeah. Yeah. So so you always have to start from some assumption that you're you're not getting to the essential, fundamental reality to get to an understanding of that reality. So everyone can work on it together. Bob Royce Yep. So then if taxonomies and linguistic map of some part of the world the question becomes, well, what makes a good abstraction of that world? How do we get at the right things? Daniel O'Neil Yeah. What do we emphasize? Which things in which relationships really matter and will help us perceive and talk about the world in question? Bob Royce Yeah. And if the world that has Hands well ordered, well, then there's usually standards, various relationships that exists in that world. And those could provide a scaffolding for good abstractions. Daniel O'Neil It's funny you say if here because I almost without exception, the world is well, well ordered. It's just not well described, right? What we've discovered, even after all these years is that usually when we go in and talk to a company, there are some really good understandings, internal structures that people have about the world in a very orderly, they're just not a good way of describing to each other. So, you know, many, if not most of the taxonomies, we need to create a focus on systems with some well ordered parts, and some standard relationships and more than you'd expect, these are the challenges describing the back. Bob Royce Yeah, and and for simple systems, that might even be enough. But you know, the world tends to be complex. And most of the systems of interest are a mix of stability, which is has the order that you talk about, but there's also a lot of instability in those places. Daniel O'Neil Yeah, that's a really good point. Because what I said before people, I mean, there's there's structure and form. And what people are talking about it exists out there, but it exists maybe in a very local way. And the complex adaptive systems are systems of systems. So each one of them might make a lot of sense to the individuals running them. And they they have some order within themselves, but they interact with each other and really chaotic ways that people don't always understand. Okay. All right. Bob Royce So, yeah, complex systems can be daunting to analyze. But we found that Stewart brands concept of pace layers can provide a really valuable lens for understanding complex systems. Daniel O'Neil Yeah, I really, I really like pacemakers. For anybody who doesn't know what this is. The idea behind this is any any system or or ecosystem or structure is going to have different layers that operate at different speeds and influence. So you might have these really slow, profound and fundamental things. Like nature and culture, that change very slowly but carry a great deal of weight. And you move higher up in the pace layers, things happen a lot more, a lot more quickly. And so you have a chance to get feedback and innovation. But and and the effects of those things can go back down, but they interact with each other in a really specific way. And you have to consider both the slow speed and the profound nature, the profound qualities of the of the lower layers, and also take into account in value, the chaotic and interactive things that are happening at the higher layers. Bob Royce Most organizations that are building taxonomies are themselves complex adaptive systems. And so they have their core strategy that's not changing very fast. And then they have operational models that evolve but they're not moving as quickly as their customers are. Part of the challenge is always to try to be more adaptable, but the reality is, you have an operational world, and it has complexity and quite often the role of a taxonomy is to To help people in that fast moving world that perhaps you're using colloquial language and, and making up their own language or words about things. How do they understand the world that they're trying to interface with through these digital systems or through taxonomies. And so the taxonomy needs to help conceptualize or structure, not the fast moving world, but the slow moving world, because we pay attention to the fast but it's the slow that has all the power. So the taxonomy is from an inside out, it's expressing that slower moving world on behalf of the people that are trying to understand from different perspectives. Daniel O'Neil Yeah. Would you say that user centered design systems are no about the moving layers of our power systems? Bob Royce Yeah, yeah. I mean, you know, and that's one of the things why I think object models can be really powerful because user centered design, personas, journey maps and the like are great for helping us understand the faster moving pace of the world. But they're not as good for understanding and helping teams align on what's going on within the slower moving world. And often, that people think, Well, we know what's happening within our world, but we, you know, you've seen it, it's implicit, there's lots of lots of implicit knowledge. And so a key thing that we have to do is make that world explicit through object models. Because that's their the bridge that connects between the fast moving and the slow moving. Daniel O'Neil Right. And, and I guess, for me that the, you know, and it's actually interesting challenge this is going to come up in our case study when we talk about it later on the talk. But the question is, how do we figure out what's fundamental and fairly stable and what is transient and faster moving? Right? Um, you know, and how do we how do we map those things? Bob Royce Well, And nothing replaces primary research with people who are working in and with the world we're mapping. But the fungibility of language makes that quite challenging. Daniel O'Neil Yeah, yeah. Yeah, we develop new and different ways of talking about things. And, you know, it takes some time for a group of works together to develop their own form of insight or speaker. In the case of the case, a village which I referred to, we got people who are in their 20s doing the work, and then we got people in their 50s in their 60s to on the work and they're approaching it, and they're all over the country. And so they talked about it a lot of different ways. And so they're fascinating challenges there. Bob Royce Yeah. And, and the same strength of the ability for us to develop, you know, that language also works against communication, because as they come to talk about core ideas, things that live on those slower moving pace layers. People even within the same organization will use very terminology for describing the world. Daniel O'Neil Yeah, yeah. And you know, and that's the thing is like you use user research methodologies, but you're approaching it at a different page paste layer, right? Because what you're doing is you're doing the user research at a lower paste layer to help identify the common concepts being talked about, and then understanding how they relate to each other. But and that's more difficult because of this fungibility, but if you are talking to people and getting them to talk to each other, it gets easier. Bob Royce Yeah, you know, and even with the best qualitative methods, we're still faced with two big challenges. And we've all experienced the gap between what someone needs to say, and and what we understand when we hear them. Right. So you know, if I ask you a question, you give me an answer. And I'm recording and taking good notes, because in the moment, I'm very unlikely to get all the import of what you're trying to say there's always a gap between that. But there's another less appreciated gap that I first heard articulated by Adele Goldberg and an oops law back in the 90s. And that's the gap between what someone wants to convey What they actually articulate with words, because we all have a complex understanding of the world and our ability to then articulate that some people are better at it than others. But it's definitely a barrier in terms of what we do. Daniel O'Neil Yeah, well, you might be better with words, but they, they actually just, they're more eloquent or more convincing, but they need something where they can all look at it and agree together. This is why models are so important. Bob Royce Yeah, exactly. And, you know, this picture from Jeff Patton. So books user story mapping so aptly describes it that I use it quite a lot. You know, we often get into these situations where we, we think we agree with somebody and it's not until we create a model of it or write it down that we realize the the disconnect, and so what we do with researches is we work to create models of what we hear from the research and then show us Back to people to say, you know, did we achieve mutual understanding? Are we able to disambiguate the language? Daniel O'Neil Yeah, Tony's got tons of miles that are designed to do this. I mean, tons and tons and tons of models. But I think my personal favorite, and maybe this is just a bias, but we're giving a talk on it. Our object models Yeah, that's, that's, there's so so good. Yep. Yeah, I think that like, like, when I compare the say to some of the other models we use, I like I like some of the other models we use, because they get everybody to basically say, Oh, that's not what you meant. But then they don't get to the next stage to say, this is what we did me, right. And I think optic miles are a great way to get it the important components and relationships in a complex system. So not just to surface the tensions, but also to help resolve them, right. Form a bridge to creating taxonomies to support the system. Yeah, they give us a formal but simple way to describe a complex world. Bob Royce Yeah, we taxonomies tend to flatten relationships and object models. combine multiple kinds of relationships, both stable static, as well as dynamic. And so they make a nice intermediate between the world and a taxonomy. We're going to have to flatten that complex world. But if we can go from so complex that there's too much detail to the core essence of things, then we can figure out often object models might be the basis of multiple taxonomies. Daniel O'Neil Yeah, yeah. So Bob Royce let's dive deeper into just what is an object model? Daniel O'Neil Right. And, and what Bob just said, is really important because object models are an interesting beast. You could basically argue that they take on components of a lot of other information and logic systems, but they are based on a pretty rigorous underlying philosophical structure that based on classification theory, which was introduced by Georg Cantor in the late 19th century, right and when you when you look at what what classification theory does, is it basically as well way of expressing distinctions between holes and parts, and also distinctions between classes of things and distinctions between relationships of things. So, a distinction between a hole and part would be a tree is made up of branches. a distinction between classes of things would be all trees, and all stones as well as differences between them. And actually, another example of that would be a robin is a kind of a bird, right? And how things relate to each other would be how a tree and the ground from which it grows like that relationship between the tree and the ground that is explicitly identified. So classification theory allowed us to start giving a methodology for understanding and really object models has been around for a while. Bob, you've worked with him for a long time Bob Royce I did. I first worked with object models in the early 1990s leading a team building small talk software for a car company in a bank and Adele Goldberg and Alan Kay built Smalltalk because they saw object oriented programming as a way to build software optimized for people instead of hardware. They recognized that at the time, hardware was very expensive, and people more expensive than the people. But they saw that that was changing hardware was getting cheaper and cheaper and cheaper and cheaper. And people were going to get more and more valuable. And so can we create software that's optimized for how people think. And so if the structure of the software is mapped to the way that people actually operate the business, then the people using it will have an easier time understanding it. And when the business changes, then it's easy to know where to update the software. If the software is modeling the business right if we get that decoupled, it can be very difficult to figure out where to change your software. So object models, then are used to create and get the important actors in the system in the business world. those tend to be stable, and they capture the relationships, the operational relationships, which tend to be more dynamic and fast moving and so they they form a nice bridge in that way. Right. And James Rumbaugh introduced object modeling in 1990. That later evolved into the Unified Modeling Language UML. That rational developed in the 1990 edition of Rumbaugh's book is still a reasonable primer for the notation that you're about to introduce. Daniel O'Neil Yeah. And and as an aside, I mean, it's very interesting because UML went on to evolve into much more specific, like models, which really emphasized a particular kind of dynamic really should be there a static relationship, an action relationship, a transitional relationship, or, or an inheritance relationship. And they didn't necessarily do them all the same way. Object Model A to do all three. So that earlier version of object models was the one that we actually like more than what UML is become a UML is still a very fine Modeling Language system. So before I dive into the details of kind of the mechanics of object miles, I really wanted to talk a little bit about what What they do for us, right, and it kind of gets back to, you know, aside from the theory of base layers from from a practical business point of view. What's cool about object models is they provide a simple common language for mapping organizations and processes to facilitate alignment. Object models assume that the stuff out there is out there for us to find, as long as we just listen well enough and hear the words and people talk to each other. It also allows us to serve as the key things in a system because our goal is to have object models that are relatively simple, but profound. And it allows organizations to plan to share the future because once you build an object model, you can look at its limitations and say, What can we do to make this better or to plan for the next thing? Bob Royce Yeah, right. Well, and that aspect of alignment is is so important. I mean, the picture that we're showing here comes from our project we did, where we did some object models of a fairly complex world. And we then print it out the world is these big posts. Right in a conference room, put the posters up on a wall, and then brought in the president, the chief technology officer and the VP of sales, and looked over them. And, you know, you see the marks on there where they were like, well, it's not quite like that. It's like this, and they mark it up. And so they were close enough to their business that they could actually engage with them, and give feedback as to where we got the model wrong. And it was a very powerful way to go back and forth fairly quickly, with some high powered people could quickly understand and correct what was happening, and our understanding of the world that then went to undergird the software. Daniel O'Neil Yeah, and what's really key about that this is actually the most important thing I always try to convince people to about what's so powerful about this is there might have been one guy in that room who had even the faintest idea what UML was, but we were able to explain the visual language of the system and just a couple of minutes and then we spent the next two hours talking about what all of these things meant. And so it was true endlessly profound, tremendously powerful way of doing it. I remember that really vividly that they had lots of cool changes. And that ceremony of just putting those pieces of paper on the wall, just simple black and white images was so so valuable. Um, so the the, the surfacing of the key things in the system, as Bob pointed out, I mean, if you look at all the arrows were in this model, they we missed things in our research, and you have to understand our research involved this talking to, like 20 or 25. Yeah, over the course of the week. Absolutely. And so we got we captured a lot of the key elements, but the nuances of those were not always exactly right, because they had their particular understanding in their particular moment, right. So when we talk to these folks with the big picture, they're able to describe to us some of the dynamic qualities of the of the complex system. Yep. And yeah, okay, so The The last thing I wanted to talk about is that the is about planning for the future, right? Because the baseline model can be modified and extended to reflect the organization's plans for a project or a process. So here on slide 20, you can see, it looks like a pretty subtle modification. But this turned out to be a deeply profound modification of this organization's thinking about what a user was and what a user account was, from the initial model, which was really a reflection of their technology to the future state model, which was really a reflection of their deeper values, their deeper Paisley or needs. And when the technology guys were all about this, because once they realized what was happening is that they had kind of asserted their understanding of accounts because of the technologists were involved when they understood what the company organization actually wanted to do. They said yes, we can design for that. And others we can adapt the higher speed paced layers of technology to reflect these deeper cultural and commerce values. Bob Royce Yeah Keep going. Daniel O'Neil All right. So, um, I want to just talk really briefly about a fundamental thing, which is object models. And this is the last I want. I want to give this concept before we dive into this because it's really important to understand this. Object models ultimately reflect a propositional statement that usually comes across as a sentence made up of nouns and verbs. Right? And there and but and that's, and that's really, really key. But the other thing that's really important remember about object models is that they're not specific examples but exemplars, right? So the closest parallel and taxonomy structures that they represent a cluster of Texans whose combination creates an object that can be used to describe a core concept in the system, right? So mammal would be the object, right? But and then you might have you might have a A weasel as as the as the child of that object, but the individual weasel was born today, in in this part of the Midwest, United States is not the object that we use as the object, the mammal is the object. They're exemplars that they reflect a broader reality. What's important about that is that allows you to then spin off all these specific examples, and go back to these fundamental truths to check in and make sure you're doing the right thing. All right, that that'll make a little more sense as we go into that as we dive in. But understand that that's important to teach. We're just grabbing the example of the thing, not the thing itself. But the more important thing is that the propositional language allows you to check and design those relationships and describe them as needed, right. You can take any object model that you build, write down a sentence for every single relationship and then read that paragraph and you will get the Reach out the truth. In one way of looking at it that entire object model Now, the reason it doesn't work as well the reason we don't just write up paragraphs, instead of writing building these giant Relationship diagrams is that when you read a paragraph, you're remembering that moment in time, that little string of information, and you have to keep it in your head, as you read the rest of the paragraph that turns out to be very hard. When you're looking at the entire diagram in front of you, you're actually seeing the linguistic truth represented in the model. And you can take it in all at once. And that turns out in our experience to have been extremely powerful, which is why we use these models instead of just writing things out. Um, the last thing and this is actually just a test as you think about this, the relationships are designed to be necessary and sufficient, they should stand on their own, but there may be moments where you need to include an annotation particularly when the relationship is an interacts with types interactions are often very complex. The major guideline annotations is less is more but sometimes when you describe a concept, the relationship you hopefully the line itself and the type of line does the work but every now and then you do have to do an annotation and an interesting test of how much clarity you have is how many adaptations are actually living on your diagram. Now, from what we've talked about, you would think this would be a really complex system, but actually what you're looking at right here, that's the, that's the entire nomenclature set for object models, these basic concepts, these three types of relationships, these two types of entities, cardinality and basically the description of the of the way they hook together. And really when you think about it, most of the work with object models once you'd get the nouns right is built on these relationships. So there are three types of relationships right. interactions are one object communicates with or changes another object right a real verb. sets are one object contains another right a bag contains groceries. inheritance, we're an object is a variation or an extension of another. Robin is a kind of bird. Bird gives you a lot of Information about birding is right the feathers that can wing they can fly. But Robins add qualities that are unique and special, that in addition to that particular definition of an object, so inheritance is really important. In simple terms we call these interacts with has a is a kind of, that's really all you need to know about the relationships. But I'll go a little deeper, just just so we can dive in. The simplest relationship is the interaction with relationship with one object affects another. Usually this results in a state change or an implicit sequence. So it's the only way the model escapes being entirely static. And remember when I said that object miles is sort of a combination of a lot of different nomenclature disciplines that we see now, the closest modeling metaphor for these relationships would be a use case. Right? So the key thing about interactions is that the two entities don't have an explicit set relationship, right? gasoline is critical to the function of an internal combustion engine, but isn't contained with an extent within it explicitly. So from a technology perspective, very often these interacts with events or API's, right because two different elements that are completely distinct from each other still need to have some communication way of talking to each other. Daniel O'Neil On the other hand has a relationships are sets, they describe explicit relationships are one thing as part of another thing, or contains that thing. The closest modeling metaphor for these relationships is the entity relationship diagram seen a database design sets set theory all the way through. And the difference between contains or hazard becomes really clear when you visualize them next to each other. Otherwise, people can struggle with it. So it's good to put these next to each other. gas tanks contain gasoline, which fuels the engine. So the gas tank doesn't feel the engine the gas tank contains the gasoline. The gasoline fuels the engine, right. And it's that's a really important distinction because you have to design a gas tank to hold the gasoline. But when the guests can actually goes to the engine that can happen in a variety of different ways. Has it relationships can be maintained to a really high level of detail. to what's really kind of cool about them is usually this concept of cardinality. You can define how many of a thing is that relates to another thing. And a lot of times that's very important systems knowing that you must have this relationship, there must be something in that bag of groceries in order for it to be interesting. Or you can have something that is a grocery that isn't always in a bag. Sometimes the grocery exists in the shopping cart. But it's not in a bag yet, so a bag doesn't always have groceries in it. The other thing that's really powerful is that they can be shared. So you can actually start to collect shared objects with hazard relationships, which is a really cool way of kind of figuring out what relates to each other and what it's what they're, what they're what they're associated with. Now, this can make them look like trees, right, which map pretty well the hierarchy nodes and there's a lot of overlap between set theory and tree taxonomy structures. So this is a useful metaphor for considering some system and the vast majority of objects Other relationships in your object models probably going to be of this type, you're gonna have static, well defined relationships of known of known nouns in your world, where you're trying to figure out how they connect to each other, what things you might be missing. If you find yourself struggling to create these relationships in your object model, you may be working at the wrong level, the relationships between objects should be relatively self explanatory without a need to include long descriptions. If you're doing a lot of action descriptions, it may not necessarily the object might not be the best way to go, you might want to have something that's a little more focused on the interactions of your system. But generally speaking, when you get to the heart of what your organization is about, has a relationships are going to play a major part. But that's really stupid inheritance, or one object is a variation or extension of another. And the closest modeling metaphor for these would be object model inheritance. These are used less and they can confuse people. So you want to be judicious in their use, but they're really really helpful as you start planning for the future because you can talk about how to These objects really end up being kind of common common descendants of this one thing. And it allows you to design with this one thing in mind when you start building towards the future. It also allows you to figure out hidden assumptions. And this is actually extremely powerful. So this is an example of the kind of relationship right? The iMac is a kind of computer, right? I mean, has baseline components that are similar across all computers. It's got CPU, RAM, disk architecture, power source, io connections, an operating system, but it does more than that, right? It's got a laptop, it's a laptop with a screen. It's got native keyboard and speakers. It's got a battery. It's got a wireless network radio transmitter that allows you to connect to the universe without hooking up to a wall. It's pretty crazy, right? But it's computery. Right? And by that reasoning, and the problem is by that reasoning, a lot of things are computers. So look at this relationship all of these devices As I define them before computers, is it helpful? Do iPhone users think of their devices? A computer? I do. But I'm not a very typical iPhone user. What about iPad users? Who does a serve beyond the system designers and logistics team so I have to figure out the architecture of the system. And and this is where the kind of relationship the the is a kind of relationship really shines. It's really easy to find a specific truth of any given object, like the fact that MacBooks iPads and phones are technically computers. But is it the essential or the most important truth about these products? What other ways might we organize these ideas? That's the power of optic models, help stakeholders, you know, help you decide which of these is really true, right, getting to the core truth. In another way we might describe these relationships would be in terms of mobile devices versus office or seated although that makes an iPad a tricky option to define and it still remains one, right. Apple has been struck. It's ironic Apple invented the iPad but they've been struggling Figure out what the iPad is for almost 10 years. And Microsoft thinks they figured it out. And that Microsoft basically said that the iPad is a computer with a touchscreen. Daniel O'Neil Apple was in total denial about that for a long time. There are two models very different. So remains to be seen exactly what this turns out to be Bob Royce I think. They're coming around to that though. Daniel O'Neil Yeah, they are. It's really interesting. So taxonomies can help us object models to define the key business decisions about these things. Is it how they're made, where they're used, how they are used, is a is a kind of relationships can be used, okay, clarity. And so differences that are implicit in systems, but a very positive outcome of presenting this model would be resolved contradictions. Don't use them too much. Don't use them too much. But there's something that you really need to figure out. This is a fun way to do it. The last piece of the puzzle is users, right? And I put this in here just because it's important to remember that object models ultimately have to With a user in some way systems help people do things. It's key part of any object model. So at some point a system is going to need to show how those people interact with it. The the users in the way that objects are exemplars, users should be a role. So you don't have to have an individual name, but you'd have the national manager, right. Here's an example of how roles interact with objects. So in a use case, world, the regional manager would probably have use cases that interacted with a system for building a staff plan. And he's still they still can, right, she still can. But this allows you to basically propose that relationship and also highlight the major factors that might be involved in the design of that use case. So when the developers and the business analysts get ahold of this, they have a really good starting point for figuring out some of the conditions, constraints. And the last major consideration of object models are their frames. So the frame is a way of thinking about what the object model Does either in defining a place or a space, or as a conceptual set of concepts for a particular user's point of view. You know, one of the things is interesting is we always talk about object models as being a real world thing. And they are but but to me, when I think about users, the users needs are a real world thing to the difference between a place your spaces that literally describes something physical in the world of physical place in the world, whereas the concepts very often refer to the needs and wants of the user as described through the through the things they want to accomplish. So Baba, this is a this is actually a medical consultation place. taxon Bob Royce Yeah, so I mean, you know, example of a frame might be software that's designed to support something in a medical environment. And so you can see here an office and as some of the key things that would be necessary in a consultation chairs, computer for managing the consultation, large screens, all the participants could see the information printer for printing out documents for the meeting, etc. Daniel O'Neil Right. And it's interesting, you know that the diagram that you showed where, you know that executives were writing all over it. And it had this really complicated combination of these physical places that were really important to their business, and then a very complicated scheduling and finance system that had to basically support and manage it. So it was a really interesting combination of a place frame, and also a user rated point of view that was associated with tasks and needs. Bob Royce Yeah, and you can't, you can't see it here, but they had multiple kinds of rooms. And so one of the things that came out from the research says, like, oh, some rooms had some equipment other rooms didn't and that mattered in this case. Right? Daniel O'Neil Right. And they only had one scheduling system, but they had to serve all the different rooms, but it was extremely complex in terms of how it operated. Yeah. So that use great point of view is usually associated with tasks and needs. So for example, a mechanic has a very complex and varied set of needs, depending on their tasks. Can it's kind of ironic given that mechanics are like some of the most physically oriented using stuff in parts people that you probably will ever meet. But from their point of view, it's important to understand the way they solve problems and do work, right. And in fact, the term that's used in the industry for these folks as technicians. So, I'm going to talk a little bit about the point of view frame from based on a case study that we did, where we were tasked to create a taxonomy for a specialty tools group that will outgrowth, content, quality and publication of both online and print journals. Um, the just to remember, I mean, when we came in, we were basically asked to create a taxonomy and when they talk to us, they probably thought we were just going to build a database, or a spreadsheet with a bunch of information in it, and eventually we did. But when we first started, we realized that we needed to basically figure out a simple common language for mapping in an organization. We needed to surface the key things in a system When you'd allow the organization to Planet share the future, because it turned out this organization had deep needs for all three of those. Daniel O'Neil The the, basically the, the space that we were looking at is a especially tools for automotive parts, right? huge space, incredibly complex, rich and varied right, thousands of parts, hundreds of thousands of parts, almost thousands of different types of making models of cars when you figure out how they work. And those make some models very often will have different parts within them that are extremely varied. The people that are actually looking at this stuff can be 20 years old and just starting their their career or they can be 60 years old, they had been working on cars for 40 years, they can be really good at their job and they can be really bad at their job. And they want people who are bad the job often are just inexperienced. So the and the the the challenges involved were really enormous. The the things thing that was most notable for us was that the specialty tool in this world is a tool designed to solve a problem, as opposed to a tool that's thought of as doing something. So a wrench is designed to loosen and unloosen, a bolt, or a screw, but especially tools designed to solve a particular problem for an application application being part of a specific kind of car. And so it's hard to find them and think about them in the way that you would if you were looking for pliers or wrenches, right. Additionally, and this was a really interesting problem is that these folks from their business perspective basically had two ways of getting their story out. They had online stuff and they had print stuff. And they both use the same catalog but the way they use it is very different right print catalogs are way to browse for new offerings and ideas. Whereas online catalogs are usually for specific needs. And we didn't know this was the result of the of it being a print media versus the unlimited. We didn't know if the specific need versus browse had to do With the nature of the technology, but what was clear from our user research was both needs were real and part of the users search for products. Daniel O'Neil So this was our primary taxonomy problem. How do we manage catalog creation in multiple media's for a complex, diverse product space with multiple needs, skill levels, and uses? Right? So we basically were starting from scratch, and I'll show you why. From from an organizational perspective, right? The current state textile for the client was dead simple, because it was basically a system for distributing stuff to suppliers, right? They're their primary customer where people will drop by giant pallets of their specialty tools and then would go distribute them over to stores, right. So they had a really good system for doing that. But our analysis showed that when it came to the catalog, it was the shop owners and the mechanics that needed help finding things. And they were not served by this model, which was a problem because they're the ones buying the stuff right? So our suggested recommendation was to create a point of view frame for the taxonomy that address the mechanics needs. And this is a really good example of where the structure was right in front of us. We just had to hear the words of the people who were talking about it. So the people who sold these products and talk to the technicians understood at a fundamental level, what they were looking for and what they needed. But they had never been able to explain it to their own organization in a way that allowed them to build a database to do it, right. So we surface the key things in the system. From that mechanic point of view mechanics worry about making model, they worry about the component they're working on, they worry about the problem that brought to people the principal in the first place, the particular part or tool they're going to do, and the nature of the task they're trying to solve. All those five things can be ways and mechanics commanded. And five different mechanics can actually come at the same solution five different ways, right? It's a pretty open, complicated story. And so what we did was we were able to plan for the future. And we created an open complicated object model that was driven by this particular problem solving approach. And the upper right hand corner, you'll see the green arrow, which is the way the current system worked online. The print catalog was more diverse and organized was basically I'm tool type. But it was, it was the result of a dedicated bespoke process from a single catalog designer, we kept the entire structure in design pages, and he was about to retire. So they really needed to find a way to pull all this stuff out and put it into a system where everybody could use it. Right. Um, so this really got a lot of traction in the organization. We we actually evangelize this across folks in Ann Arbor, Wisconsin, and Detroit. And we were able to do it for a bunch of different supply side supply parts. And it worked really, really well. When we did the implementation. This was a very interesting outcome of this is when you have object models like this, you don't necessarily know Need the object models to be rigidly implemented, right, because they're designed part of that cultural base layer. Once we got to the technology level, we were able to take advantage of another truth of that culture, which is that everybody already understood all this once, you would actually surface it for them. So we didn't actually build a highly restrictive object moment database, we built the objects as facets, because the organization felt like the management of the relationships between the concepts could be handled through process and inherent knowledge. So we didn't spend much time managing the relationship between the object models explicitly instead just worked really hard on making good control vocabularies per facet to facilitate classification, then assumed they were going to take it from there, which was pretty cool. But we would never figure that out if we hadn't first surface these relationships explicitly and seeing what they do. So that that was a really fun case study because it gave us it got us through all the way through the discovery allows to plan for the future and also show that the object model doesn't have to be a rigid way of mapping once you get the map. It doesn't mean that you have that it's going to be the territory. So to review, object models will provide a common language for mapping an organization. They'll surface the key things in that in that system organization that allow organizations to plan and share the future. Bob Royce That's it. Well, yeah, thank you that kind of got excited. Transcribed by https://otter.ai