Bob Royce Good day to you, wherever and whenever you may be bad boys, and I'm glad you're here. I wish I was there with you. But that's not possible. This gathering has been one of my favorite times of the year and I hope it will continue eat despite the disruption the virus has caused this year. Let's talk about how things will go with this talk barring from the framework I'm introducing, I've structured the talk to follow the pattern that we follow in the first phase of the past process the program phase. So the program for the talk will begin with a short discussion of why we need a framework for information architecture projects, what we mean by a sensible framework for information architecture, who is behind the framework and who the framework was for. And then the majority of the talk will be spent stepping through each of the phases of the process part of the framework in sequence. And then we'll conclude with a brief discussion on how to measure success when using the framework and some trade offs on how it's used. So, let's begin. Why do we need a framework for information architecture projects? A world of uncertainty, it's more important than ever for people to communicate meaningfully. We've been telling ourselves stories about the power of language for thousands of years, language is the most powerful tool humans possess. And yet it was just over 70 years ago with the work of Claude Shannon and the invention of the transistor, that we learned to use mathematics and physics to dissolve information into bits and bytes to take language and digitize it. This was the birth of information science, but it was information divorced of meaning, disembodied bits and bytes, masterfully distributed throughout the world. And so we find ourselves today connected to each other 24 seven anytime, anyplace anywhere, anyone practically drowning in information. And while the mastery of science and physics has brought us thus far they actually get in the way is we try to reconstruct the meaning that was dissolved into the bits and bytes to get to this point. So who's responsible for how to construct meaning out of all that information? It's mostly data for honest, who will help us build that information into useful constructs to provide the knowledge that we so desperately need to act and the meaning we so desperately hunger for. This is the call of information architects, we bring a recognition that humans are not computers with a body able to reconstruct an encoded signal like a microphone and a speaker combination. Rather, we're complex beings. Our brains evolved over millions of years to function in time and space, making sense of the world through placemaking. And by constructing systems of language, we label and categorize around us as surely As we breathe, we're all information architects, we construct systems of language to communicate and bring order to the world, a letter, a book, a spreadsheet, all of them have an information architecture that the recipient has come to understand as they navigate the structure that's given to them. We're so good at it, that we naturally evolve language over time to accommodate the changes we encounter. It takes no time for a group to fall into the familiar pitter patter of insider speak. And so our mastery over physics has enabled us to multiply our communication by many, many orders of magnitude. The need to understand how to tap into that leverage, the power of language and all its form is growing. And so there's never been a better time to be able to have the skill and have a framework for helping organizations make the complex clear, as they employ their digital places. Bob Royce What do we mean by a sensible framework for information architecture. In this section, we'll talk about the context of practice that pass evolved and operates within and what we're trying to accomplish with pass. We'll also talk briefly about some core methodologies or maybe patterns is a better word that infuse our practice as we move through the process. To understand the understanding group and anything we do, it helps to begin with Mr. Wurman. He and I have never met but it's friendship with Dan, my business partner, Dan and my mutual love for his way of seeing his lenses for our practice shows up in every warp and weft of what we do. Information Architecture looks at things that operate below the surface. We so swim in language, we're hardly aware of its influence and how we think but when it's confused, somehow our lacks coherence, we feel anxious to get below the surface and help people build scaffolding the need to move through our places requires a way of thinking that goes beyond making something look good, and works to make it be good. how we approach that challenge is also framed by the model of information architecture introduced 10 years ago by tech co founder Dan Klein, and then updated last year, from with help from Andrea Resmini. Behind every digital place is some piece of the world that is operating within some context. It's a complex world that defies our ability to pin it down exhaustively in detail. So I should make it clear that our use of the word ontology is not referring explicitly to a formal model, as that term is commonly used. Rather, it's a recognition that behind every digital place is a world of meaning. And as intertangled as it is, if we listen to the people that operate within that world, we can begin to understand what they mean when they say what they say. And start being Building a shared conceptual model of the world they operate in. As we put labels to these concepts, and then relate these concepts to each other using various models, we are building the elements of a shared ontology. The ontology then gets expressed in a myriad of ways throughout our digital places. Originally, the term here was taxonomy because the most common expression of ontology was through various menus and lists and hierarchies and that helped people orient and navigate and move throughout the site. It was changed to typology, in recognition of how digital places are evolving beyond stacks of pages that fit neatly within a hierarchy to pervasive places, intertwined and complex and multi dimensional ways. And ultimate aim of information architecture is to help people find their way through these digital places to find what they're looking for, do what they came to do while still feeling in control. This requires careful choreography so your digital plays can lead People where they need to go without constraining them from dancing to their own tune if they want to explore. All three of these layers work together and inner Twingo in complex ways. They operate beneath the surface so to speak, we don't have a deliverable called choreography. And although there's some sequentiality to the layers, we're working to understand all three throughout the process. I refer to this as a sensible framework for a number of reasons, sensible in the way that Abby covert speaks of information architecture is a practice of making sense. Addie was an important part of target our first year so in the tools and practice he initiated still run through our projects. It's also sensible in the way that Andrew Hinton taught us to see I will ever associate Andrew with the colic fields of the Derbyshire landscape that he used to illustrate the way language helps us bridge the world we have physically inhabited for millennia and the digital world. We've recently come to inhabit with increasing frequency. Andrew introduced a deep appreciation for how the way we experience the world as physical beings affects the practice of architecture and digital places. How the place making we do as we go about our lives is an integral way of how we make sense of things, and how language serves as a kind of infrastructure as signposts and scaffolding that helps us bridge between our embodied way of thinking and the fast moving world of digital. Our practice has also been influenced by our friend Jorge Iran. A few years ago, he elegantly put into words what we are, we're increasingly seeing in our projects that in a world where we are living in information, moving from place to place channel to channel, always connected with one advice or another. Information Architecture can help us maintain our sense of place our sense of where we are, as we move across contexts. it accomplishes this by working to maintain the structural integrity Meaning across all those contexts. Bob Royce So, bringing things down to 10,000 feet, I've asked Peter Morville to talk about a three layer model that he uses to talk about the practice of information architecture that we've also found useful in structuring and explaining how it is that that we are applying this framework. Peter Morville Partly I fleshed out these three layers of information architecture, because ever since the earliest days of IAA, back in the mid to late 90s, it was always a challenge around defining information architecture, making sure that we're talking about the same thing. And, and over time, what we saw with the success of it early on, was that people fixated on what I think of as the middle layer of classic information architecture, which really was the original definition in the polar bear book. focused on the design of structure, organization, navigation, labeling and search systems. Right. So these are the most tangible elements of information architecture. They're the sorts of things that you work on when you're, when you're creating wireframes, or sketches, parts of the information architecture you can point to and talk about. And so often when, when you're talking with executives, and you mentioned the term information architecture, that's what they think about what they can sort of see. And so already there, you're, you're in a good position where people know what information architecture is, but I think it's really important for them to see that, first of all in the broader context of of what I call strategic information architecture, to recognize it before you start working on those wireframes. You need to make sure you understand and align with business strategy. And, you know, other areas that sort of overlap with and need to be aligned with and from strategic IA are things like user experience strategy and digital strategy. So there's this broader framework of understanding what are the goals of the business? What's the strategy of the business? How can information architecture help to advance those goals and strategies? And sometimes, I would say increasingly so the the deep understanding of information architecture can help enable changes in the business strategy, recognition, recognition that what we're doing online or in software, maybe there's a better way to achieve our goals. So developing maps conceptual diagrams are ways to help people think about and understand this broader digital place that you're designing, thinking about the experiences that we want to enable, and really building towards shared understanding among all the shape all the stakeholders so that we really understand what it is we're about to do. What are what we Want to achieve? And then thinking ahead about governance, right. So strategic IA includes thinking about how are we going to manage the software or websites or systems that we that we design. So that's what I think of as the top layer. And people can get very excited about that. And you can get a lot of energy around articulating strategic I am doing the classic I am. And then the part that that that as a library science person, someone who comes from a library science background I, I don't want people to forget about but it's easy to miss is the Deep IA. So, you know, if you're developing a fairly simple website, you may not need to do deep IA at all. And that's why a lot of folks don't think about it so much. But when you're developing any sophisticated piece of software or a large website with a large volume of content and features, you need to be thinking about taxonomy. metadata, vocabularies, the sore eye, and the standards that go along with all of those. So again, that's kind of that's a side of information architecture or layer that kind of the underlying foundation that's invisible to a lot of folks, people don't think about it and yet it drast it has a dramatic impact on your ability to have an effective, classic IAand and to actually execute on your goals around strategic IA Bob Royce This is a framework because it's the combination of a process and the collection of methods and tools that we apply across that process. It's not a prescription, but more of a kind of scaffolding for planning IA projects. The process itself is based upon one commonly used in the world of physical architecture, beginning with a program phase that focuses on what needs to be accomplished. What a good outcome looks like, What does good mean, and then moves through a fairly typical sequence of steps to solve a problem. You'll learn about the current state then solve for the desired future state, and then conclude with plans detailed enough to equip the people that need to build what it is we're designing. As we have adapted this set of steps to the world of information architecture, we've developed two or three depending on how you count them, methodology, your patterns that overlay the process. The first is working in terms of architecture, we're in terms of what versus how the legacy of technology driven projects still pervades the DNA of many organizations. So while designers are naturally asked for solutions, information, architects need to push a step back and start with a search for truth. Every good process begins with what before how in some way, but more typical transition is from design sliding into build. Architecture happens in this case, but to subset within design, and there's a constant pressure to slide ever more quickly to finding a buildable solution. We bring architecture forward as a distinct activity, further separating us from the siren call to look for a solution instead of truth. Understanding technology constraints will emerge as a natural part of our initial work. But in the beginning, we're working hard to get the organization to step back from considering how this is all going to work. We want to start by working through some fundamental decisions about the shape of our system decisions not about the technology architecture, but about the information architecture. Are there different kinds of places in this digital building, so to speak? How many places do we need? Are some more important than others? Why do they all speak as one or as individual places? The specific decisions are always unique to the business of context. So part of what it means to work in terms of information architecture, is to examine the forces at play that shape our place. here in Michigan, where I'm sequestered are loser pointy, close Grow mountain chalet than the flat ruse of a place with little rain. Or in Seattle where one of our favorite clients is riding out the storm of that cursive little strand of nucleic acid. The rules are designed to funnel massive amounts of rain away from the foundation. Throughout the past process, there's a focus on what are the forces that work in this particular place. So that the form the information architecture takes is a good fit. When successful, this will result in something that not just looks good but is good down to its bones, as you might say, about a well designed old house that's been updated throughout the decades without needing to tear down any of the walls. The three most common forces that typically shaped the rest of the forces at play, have to do with how we do business today. where we want to go tomorrow. And what to the people that we that will work in the digital place. What do they want? So, like the master architect Denise scott brown helped her clients realize complex projects. The Press framework is designed to allow an Information Architect to help organizations make better decisions and incur less risk by understanding the interplay between what the organization's mean, what they say what people do. The last methodology focuses on modeling. There's a lot one can say about modeling and I'll later talk to my colleague Joe Elmendorf about the ways models can build on each other on their way to a testable prototype. So I won't go into a lot of detail here, except to observe the basic pattern that underlines all the modeling that we're doing. Like all design disciplines, information, architects will use models generatively to sketch out and explore new ideas. But the posture of information architecture is just as often one of observing. This can be uncomfortable for many designers because it begs one to take the posture of not understanding As Mr. Wurman likes to say, many people sell their expertise and they have a limited repertoire. I sell my ignorance, my repertoire is unlimited. Bob Royce So coming to that situation with a beginner's mind, will often lead to models that are typically quite simple, even dumb, but they're sufficient to provoke the discussion required to align around a shared understanding of whatever it is we're observing. This aligned part of the pattern is particularly important because any form of observation and research results in gaps of understanding between what we hear from someone and what we capture. And we also face the problem that there's always a gap between the picture people have in their mind as they're talking to us, and what they actually then communicate to us in terms of what they're thinking. So as this illustration from Jeff Patton's book, story mapping so aptly illustrates, we can use this pattern of observe model align to untangle some of the complexity That forms. In complex projects, all the little misunderstandings and miscommunication that happens as groups work together and build up over time, can be untangled and clarified through observing what's happening, modeling what you see, noting the disconnects, they'll see. It's like, Well, no, no, it's not like that, Oh, I thought it was and then they'll work it out, and then help resolve and bring alignment that you need to move forward with a complex project. Bob Royce Who is used this for what kinds of organizations and what kinds of projects the framework has been developed over the past nine years or so by the team at the understanding group, we mostly have backgrounds and Information Science, with some industrial design, education, anthropology, and user experience thrown into the mix. So as a consulting firm, our context for applying this differs from inside team and that may give us advantage in some instances, when people are paying outsiders for a solution, they may be more inclined to go along with a new way of doing something. But otherwise, there's no reason an internal team couldn't adopt this for their use. As I'll discuss in more detail soon, the most important ingredients to successfully applying this is engagement from the business leaders who need this place to work. This is not always easy, especially in a world where these projects are primarily viewed as technology driven exercises. But we generally find that when we tell a business leader that we can help them architect a digital place that's easy to use, delightful to visit won't break the first time they try to change it. And if they'd like, they can defer the discussion about technology until we've worked through and tested and validated in detail how people will engage with this place. They're generally quite agreeable to go along. One of my favorite testimonials is from an executive at Quickand Loans, the largest and fastest growing mortgage lender in the country. They have an aggressive, get it done culture. So the time we took to work through the initial program phase with them was precious. We recently had a chance to pitch a sister company of theirs amrok. And I was told by my contact at amrok that we were highly regarded, but that our contact at Quick andLoans made a point of telling him to make sure to let tug work through our whole process. That just made me quite happy to see that they'd seen the value in that. So bring this all together. We can summarize by saying that the framework we're talking about will support architecting a wide variety of places that are made of information from an internal digital workplace supporting the global operations of a foundation. To the human resource portal, serving 100,000 constituents of one university to the gateway to the whole university of another, or the taxonomy of a disruptive new consumer product or place to enjoy more of your favorite game show. All of these are places made of information and all of them are easily or were developed in architected using this process. So, now, let's walk through each phase in a little bit more detail. Bob Royce The program phase, every digital place serves a purpose, a purpose that comes from within a particular organizational context. And these contexts are often complex, involving multiple stakeholders each with differing overlapping and sometimes conflicting goals. Understanding this context Helping stakeholders align on a shared model of the context is an important first step in laying the foundation for a clear program for the digital place. The program clarifies why the place exists, what happens there, who it's for, and how to measure success. This is without a doubt the most important of the phases. If you don't start out with a clear sense of what good means, a basis for gauging your success, it's very difficult to succeed. There are lots of ways of solving a problem, lots of tactics for implementing a digital place. Lots of how. So if we don't start with a clear sense of what it is we're setting out about to do, it's very easy to implement a digital place that works perfectly but fails miserably. The program for the digital place answers five questions. Why are we doing this? What's the business context? What are we doing and what are we not doing? The operational context gets at the operational context. To the organization, who are we serving? What's the context in which this is all being used? And how will we measure success with these KPIs or okrs? Or goals or what have you? And then how will we balance trade offs and tensions. We'll talk a little bit about some models that we use do to help establish this important way of getting more nuanced in detail about what we're doing. So these kinds of questions are often answered during a discovery workshop of some sort. I've been in a lot of discovery workshops over the decades, and they're certainly better than nothing. But it's the rare group of stakeholders that can work through even the first three of these questions in a healthy way. It's not impossible, and with sufficient prep ahead of time, a mature digital team will certainly be able to do this. For a small project. Even a young team with good leadership can work through these adequately in a meeting or two But if the digital plays being designed is complex, serving a variety of constituencies within a large organization, then it's important to give voice to all the various perspectives for why we're doing this, how this will affect and help different parts of the organization differently, and just who it is that needs to be served. This generally means conducting interviews with every stakeholder, ideally, one for 45 minutes to an hour, one on one, for 45 minutes to an hour. There's often pressure to combine people into interviews, but generally it's better to have a short period of time with one person, then a longer period with multiple people. Our goal in these interviews is to try and get to the heart of things. It's important for people in that context to be able to work out their thoughts, and that makes it hard to include lots of different voices unless they're all used to working together closely in partnership with each other. So the next obvious question that is who is a stakeholder? And it's a good question. And important to get right. In the simplest sense, a stakeholder is someone who has a significant stake in the outcome. The digital place being built plays a meaningful role helping them achieve their organizational goals. If the places in support of a particular product, then the stakeholder team might be small, maybe five or six people from the product team and business leaders matrix in somehow, if we're redesigning the central place for a division or company, the stakeholders will generally be maybe all of the members key or maybe all of the members of the executive team. One project for a nonprofit who invest heavily in digital to serve at 16 million members around the world call for 25 interviews to get sufficient stakeholder coverage. It's important also to remember the purpose of these interviews. We're not asking people what they want their website or app to look like. We start by asking them to describe what do they do? How does They fit into the organization, then we move on to discussing will, why do they think why does this digital place even exist? How does it intersect what they do? What needs to happen in this place for them to be successful? And who is their most important customer served by this place? to have heavy emphasis on what not how. Bob Royce Our goal is to understand from amidst all the things that are going on in their world, what are the primary levers and connections between what they need to accomplish and the digital place we're helping to design. We're also listening for how they talk about their part of the world and how it relates to other parts. When we're done with these interviews, we'll take them and distill them down into maps and simple you might even call them dumb models of the current state of the world. The simplicity of their models is intentionally provocative since our goal is as much to identify where we fail to understand Stan is where we succeeded. It's a good thing when stakeholders point out important things that we missed or left off a model because we didn't think it was important. We also prepare for what we call an intention model exercise, where we'll help stakeholders work through how they want to balance between these issues. To do that, we'll pull out a set of continues that represent things the site needs to do good things, but their intention with him other function. Typical examples might include, we need to close the sale versus cross sell and sell more, expose more of the assortment. A consistent experience everywhere but a differentiated experience in a particular part of the site. Serving existing customers or gaining new customers. There's no right or wrong right or wrong way to balance these. These are not information architecture, design or user experience decisions. These are business decisions. Both sides are good things But the chances are pretty good that the way people think and talk about those issues in one part of the company differs from another part. And so that will make it difficult for them to talk about and resolve some of these isolated these issues in isolated conversations. So our goal of the exercise is to bring them all together and talk through these issues into better alignment, how to balance them. I won't go into all the details here. But in a nutshell, we facilitate a discussion around each of the continuum we've selected, almost always with input and guidance from our project sponsor. And we asked participants to mark how they think the organization balances those continuance today. We tally up the votes and talk about the results. There's almost always results in some people changing their perspective or gaining new understanding about what was meant by the different ends of the of the continuum. So Then with a better sense of alignment about what these mean, we then ask everybody to vote on where to strike the balance tomorrow. Now, the goal of all this is not consensus. You can see from these examples that the votes are spread out sometimes radically So, and consensus sounds good, but it's ephemeral. I'm not sure I've ever been in a situation where there was truly achieved consensus for decision of any complexity, faked sure, but achieved? No. The goal rather, is to facilitate consent among the participants aligning around an agreeable balance of preferences. Everybody's vote is represented in the model. But the focus is on aligning the group on a general point of reference that no one objects to. We find this results in a durable agreement that provides us better footing later than other ways. We've tried to get it similar outcomes. This is a wiffle bat, not a rifle. And the real prize is our collective ability. Take a step back later, and look at the set of decisions about how to balance between and among good things. things we've been and will continue to do. But tomorrow we want to change our emphasis our sense of direction. So as we look back, the things that stand out from the collection of continuous will be the general direction of movement. And how big of a change it called for some continuous will change little, but some subset will call for big moves often enough to consider starting now to line up change management resources. And the group can decide to adjust the dial. This is particularly common with discussing, you know, how big of a change we want to make. Sometimes the change this kind of change is made by the decider. The person with the final say and at all. We once had a CEO who knew she was taking another position, dial back how aggressively her team wanted to move the needle. Bob Royce intention modeling workshops typically happen near the end of the program phase, often as part of the program alignment meeting where we meet with stakeholders to review our models, finalize the details of the program in terms of why, what and the who of the project. The intention models provide a rich model for bracketing much of how we'll know if we're doing it, right. But we also want to establish concrete metrics for measuring future success. This is often challenging, since organizations are generally still governing the digital world poorly. But it's always helpful and often quite a line in lightning to push a business to figure out just what concrete measures there are for measuring success. Not what would you like to measure but what can you measure? Or if you can't today, what are you willing to put the energy into start measuring? Of course, some organizations are strong in this way. Then this will be very straightforward and an invigorating exercise as it challenges and inspires the team to create a place that delivers on the goals. So by the end of the program, we'll have a clear understanding of why we're doing this. What needs to happen in this place, who needs to serve, and a multi dimensional model of business intent for how to balance the inevitable trade offs that have to happen to bring the program to life. Bob Royce With a clear picture of what good looks like, we now move to the analysis phase where we work to understand the current state. We're still primarily focused on what versus how we'll work to understand any constraints inherent to the project that may affect our design. But primarily, we're working to understand three things that need to work together for the place to succeed, the operational model that serves the place The content and information that currently exists and the people who the place will serve. Let's look at each of these in turn. Digital places are dynamic systems that interact with numerous other systems, and rely on those systems whether they're physical or digital to operate. At a minimum, there's usually some type of content management system that is used to govern the text and graphics, but there's typically other systems that will integrate with the place to serve it. And sometimes complex operations are working behind the scenes to serve up relative information and inputs. These operational systems play important roles in the success of any digital place, so it's important to understand how they operate and what they can and can't do. For software applications a full blown business analysis process might be in order to map out how value is created throughout the systems. When working to update a legacy system. It may be desirable to take a step back, look past the existence Architecture, the legacy system and instead look at the processes through the lens of people working on it today. This kind of contextual inquiry can identify all the ways that people were hacking the system to get it to do what they needed to do, even though it wasn't designed to do that. And that sets us up then to design a more efficient process in the future state. We're often than not, though, the operational models can be depicted with simple logic models that capture the important actors and systems that our place relies on to operate. If we look at this layer, through the lens of paste layers, the program phase focuses on the core slow moving strategic intent. While the analysis phase looks at the operational model that's moving slightly faster, and puts that intent into action. And then together feed heavily into the ontology and how we think about the core functions and the isness of the world. The next area of analysis corresponds more to the topology of the information architecture, and looks at what kind of information and content exists today. This is at the heart of our digital place. And it's important to get a handle on the nature of what's there. The scope and scale of this effort for AI varies widely, depending on the nature of the place. But generally, you're trying to get a handle on a few things at this point. What's the basis for the current organization? Why is it the way it is now? What are the dynamics of the content in terms of the volume of the content, the variety of content types, the velocity of creation and change within it? And you also it's good to assess the maturity of how the organization deals with content and taxonomy governance, which will help set up realistic expectations as you move on toward a solution. So the most important aspect of analysis involves the people using the site In particular their behavior on the site and their intent for coming to the site. The two most basic ways of doing this are with quantitative research, where we look for evidence of what people have done through analytics, and qualitative, which involves more freeform discussions. Now examining analytics can be helpful. But the reality is most organizations do a poor job of collecting this kind of data. Maybe they did. But then something changed. And now things are disconnected or they did on part of the site part of the time. There are a myriad of reasons. But suffice it to say that even when companies think they have good analytics, they are rarely as good as they think. Now when you can get them usage stats provide important signals about where there are problems, but they're never going to be sufficient in and of themselves anyway, because at best, they point us to signals of the existing problem, right? It's like smoke but you don't really know the nature of the fire because they fail to tell us why the problem is happening. Bob Royce Qualitative research is more important tool at this place because of that nothing replaces talking to actual people who do or might go to your digital place. Ideally, we're talking to them in the context of using the site and maybe even there with them to get the full picture of what's going on. This kind of research is often perceived as expensive and it's is to some extent, but when organizations try to shortcut this step it invariably shortchanges the results. They may think they know their customers, and maybe they do know them as well as they think they do. But that's almost never the case. unless they've gone through a formal process to capture their hypothesis of their users. Their ability to communicate anything of real value to the project is limited. Even mature organizations with establish personas and journey maps will benefit from updated research specifically in the context of the project. Though these existing materials often serve as proxies instead Further research. So another common shortcut people try to propose is sending out some survey of sort. And surveys are good for gathering a little bit of information from a lot of people. And they have their place. But like analytics, they provide us more smoke, then signal analysts are very focused and tailored to learning very specific things. And so in general, they only occasionally make sense as input for architecting a digital place except it is a follow on baseline activity that can be quite good. When we're doing our qualitative research with people, our focus is not so much on their attitudes or other psychographic kinds of things that our marketing person might be looking for. Rather, we want to understand the situation that leads them to the digital place, the needs they're trying to fill, and then the tasks for how they'd like to go about meeting that need, which too often is kind of the only thing we're looking at. It's getting at that situation and the needs that give us the most holistic view of what's going on. As we're conducting our observations, we're starting to draft models that we'll use to help align our understanding among ourselves and among our stakeholders. These can take many forms, we used to try ahead of time to specify what we would do in some detail. But what's ultimately call for is usually not just one kind of model. And it's often maybe some combination or or some variation of the kinds of models that people are used to doing. And until we get through the program phase and get the inputs for what it is, how to balance priorities and balance among the different kinds of people that we're talking about. We don't really settle in on the kinds of models that would make sense. So given the nature of our inquiry, we know that the models will usually want to include some combination of characteristics of the people coming. Why are they coming? What do they want to do when they get there? What does good life look like for their site visit? And we'd also like to understand some of the context for how their engagement with our digital place fits into the bigger picture. Where else are they going before after? is this? Are they going to complete what they're doing? is it part of a process, all of that is helpful to capture and render in some type of model that we can then align around. So it may be some form of a persona or a mind map, some type of journey map and experience map or some combination of those. The key is as we consider how to structure the New World, these models will serve as our hypothesis and the shared hypothesis among us and the stakeholders among this that, this is what people are like this is what they want when they are coming to our place. That we're designing. And here's where our place fits into their, their world. And it's a hypothesis. And hopefully we'll have a chance to test that. But we need to have some stake in the ground that's not in our head about what people are like to talk in a little bit more depth about the framework for guiding how we develop models. I asked my colleague, Joel Elmendorf to talk about a tool that he's been developing for this purpose. We're looking at a template that you have here, why don't you unpack this for us a little bit? Joel Elmendorf Yeah. So models are extremely broad. We can model anything and everything to say we're going to make a model is no more specific than saying we're going to describe something with words. And so we need we need some sort of framing around how do we describe what a model is before we actually start to make it so that we can collaborate on something as consultants, we need to describe what we're going to make so that we can sell it and oftentimes, we don't know what we're gonna make until we're actually in the throes of it and so similar to the way We practice information architecture, the way that we practice creating models is we like to establish a program for, what is this model going to be? And how will I know as the model maker that I've made what I intended to make at the end. And so I like to think about models less as I need to make a sitemap or I need to make the journey map or some wireframes and instead focus really on the intent. What is what is this model going to be used for? What is why am I taking the time to make it? I have a hunch that this process of modeling is gonna help me do something. What is that? And that's really the way that modeling for me starts that that intent. And then from there we can focus on there's any number of things that somebody can model about the system systems are vast and complex will make you look at it from this angle or that angle or from up here or down here and all of them useful for different kinds of things, but given your intent, What aspect of something Do you need to look at? If you're trying to document the strategic business tensions of business stakeholders, you're going to be focusing on the business aspect of something, which means you don't focus on any of this other stuff. That really helps us. Not just be efficient, but really nail what we're trying to hit and make a model that's clear model that doesn't do too much as a model. That's clear. And then the other part of it is, what level of abstraction are we dealing with? And the level of abstraction helps us tune the kinds of conversations that we want to have? Are we trying to have high level conversations where a lot of detail and fidelity will just kind of lead us down rabbit trails? Or have we figured out the high level stuff and we really need to nail down this one specific detail and that will let us decide whether or not we need something at a high level of abstraction. low level of abstraction are somewhere in between. Bob Royce Excellent, thank you. Now in some cases, particularly with sites that serve high volumes of different kinds of people, it may not make sense to invest heavily in new qualitative research during this phase, places operating at this scale likely have mature marketing oriented customer models. And the functionality and capabilities of the place are not the problem. What is often the problem is the way the organization of the place has grown over the years with one new section glommed on to the other to the point that they operate something like the Winchester Mystery house. Now in these cases, we have found good success employing a version of the jobs to be done analysis that Jim combat talks about, and combine that with a method we've developed that groups those jobs into clusters representing common postures or intent visitors as they're coming for a particular visit. If you'd like to learn more about this particular technique, my colleague Grant Carmichael has a poster about jobs we done an hour types in the poster session. So by the end of the analysis phase, you should have a good understanding of the current state at a few different levels. The operational model that is feeding into the digital place the information and content that needs to be structured, and the faster moving and evolving intent and behavior of the people that will use the site. And with all of that, you're now ready to start solving for the future in synthesis. In the synthesis phase, we work to develop models of the future state. In analysis, we work to understand the situational context that brought people to the site, what needs they had when they were there, and how different tasks they need to accomplish satisfied those needs. So now at this point, we update those current state models to reflect changes we want to see in the future. Now, these are fairly common activities but pass also introduces a step here that distinguishes it. When we started tugg the most common way information architecture was practiced was to operate within another design process probably roughly followed the basic sequence that we've discussed so far. But by the time the information architects would get actively involved, much of the design work was pretty far along, IA's were brought in to straighten things up. genitive ideation, had focused on this ambiguous thing called look and feel. And the development team by now was locked and loaded and ready to start coding as soon as possible. But believing as we do that you cannot get to a good look and feel without a good underlying conceptual and semantic structure of the digital place that makes sense to people. We built into our project plans, a way to express and align with stakeholders around that underlying structure before moving and doing all the work involved with detailed wireframes. Much as the way a balsa wood and loofa sponge model might do for a physical building. These models are rhetorical versus pictorial. They make a statement about how the pieces and parts relate together in the place being designed. There are more than sketches, but they're nothing like a wireframe, and we weren't sure what to call them. Dan Klein and I were discussing this one day driving back from a meeting, when we passed by an iconic building near Grand Rapids that has a large cantilevered floor extending out from the building. It's a provocative statement, in this case, promoting the skills of the architectural engineering firm that built that as their headquarters. Dan was friends with someone who worked there noted that they call themselves structural engineers. We'd like that term. So we adopted it and now call these intermediate models, structural design models. Our view on the need for these kinds of things were heavily influenced by Dan's experience as an IA for any commerce focused website design firm back in the.com. Boom era. Per the common practice at the time, the team would do all kinds of discovery and research all duly captured or reams of slides packed with narrative that some shareholders stakeholders might read once, but most probably skimmed at best. And then the team would jump from that all the way to wireframes also packaged up nicely in a beautiful deck full of detailed wireframes that the client was then asked to approve. It was an entirely unreasonable expectation to ask them to approve something so abstract, and yet so detailed all at once. It was designed theater at best. Now, some organizations go to the opposite extreme, they insist that all mock ups have to be pixel perfect representations of what will look like in the end. We really recommend working a bounce and this and working through these kinds of intermediate models as a way to build alignment. As I'll explain in a minute, we can even test and validate the design before committing to any detailed design, work or coding, Bob Royce It's important for stakeholders to understand that we are not showing them web pages. If we need to express some aspect of a structural design as something that looks like a web page, then they're sketched really a large poster sized pieces of paper so that people looking at them will be less likely to think of them as actual webpages instead of the conceptual models that they're intended to represent. Structural models serve a couple purposes. The models represent the essence of the proposed new structure. They need to be detailed enough to capture the complexity of the world. But remain crude enough that stakeholders still have no problem making changes to them. If something doesn't look right, this is erasing it on the drawing board as opposed to tearing it down once you start to build it. So for example, in this model for a chain of multiplex theaters, we can see the primary high hierarchy of major content areas with movies in the center of that And then a variety of inter twinkle kinds of areas, each with a different focus kind of overlaid on top of those content areas. So there's a big emphasis on content and time, and on places, as you might expect from a business showing movies in multiple locations. But they're also places where people want to connect with others, a place to shop, a place to partner, and a place for membership. These are all different contexts of use, that should be accounted for in this structure somehow. At first, we would work off the structural models and move right into wireframing. But we realized over time that when certainly when planning a redesign of any scale, it made sense to use the structured models to create lightweight prototypes that we can then test. In this way. They serve as intermediate models before moving to a full blown sitemap card sort can be a helpful and testing out the basic labeling and combination of concepts but they fall Short enabling us to observe how the choreography might play out over a session. So to walk through a quick example of how this could work, we see here a structural model for a digital ecosystem designed to bring you together numerous separate places into one more coherent digital world, even possibly only one site that combines maybe 10 other sites. This was a very big move for the organization. And it will take them years to bring it to realization. So to test ahead of time, how well this new way of structuring would make sense to members. We took a representative of user tasks jobs to be done, and selected from each of the job clusters that we call archetypes to test with them, and created a skeleton of a sitemap that was developed that would contain all the major nodes that people would need to traverse to complete the tasks that we selected to test. Then, a lightweight prototype is built, maybe even hand sketched and users are then asked To select from a collection of tasks, some that they typically do, and then use the prototype to navigate where they would go to do that task. This talk a lot of exercises, then scored somehow and used to revise and refine the prototype prototype. And then we update it and do this again, we recommend at least two rounds of testing. But for complex places that have to be right, say for a high volume ecommerce site where the wrong chains can cost you big time, you might combine these prototypes with reject testing to refine both the conceptual structure and the labeling, and iterate until you have sufficient confidence that you got it right. So by the time you're done with synthesis, you'll have good maps and models of your anticipated user journeys and a clear structural model for a digital place that will support those journeys. And all that implies. You're now ready to move into sustained phase where the detail plans and blueprints are worked out to enable the builders of the places To build that while maintaining the integrity of meaning that was intended throughout the site. So as we conclude this section on the synthesis phase, I'll note that all the other maps and models that we've developed up to this point in the program and analysis phase are still valuable on their own. And they work together to inform what we're doing in this phase. The conclusion of this talk, look for a conversation I had with my colleague, Joe Elmendorf, where he will talk through a model that he drafted that depicts how the different combination of different models and earlier phases work together as inputs into the prototype in the synthesis phase, that to help us understand how people respond to something that draws from all that we've done up to until now. Bob Royce Now, with a clear understanding of what good means, both from the perspective of the business and from the perspective of the people that come and work in this place, and a clear validated structure for the overall All digital place, we move to the last phase of the process the sustain phase, where plans and blueprints are developed to equip the builders. The activities in this phase are all fairly straightforward tasks, but are highly dependent on the context of the situation. Typically, the plans needed to carry things forward consists of some combination of updated object models to reflect important operational assumptions taxonomies and metadata and content models, the kind of deep IA that Peter Morville spoke of earlier, that's often overlooked, but helps set the place up for successful search implementation. Some kind of site map that shows how the pieces and parts get connected, and the choreography intended between them. And page level wireframes with varying degrees of notation, depending on relationships between the design team and development team, those might be very light or they might be very detailed. This is all pretty straightforward. I would never have guessed when I start Tuk a little over nine years ago, that we would often phase out as the project transitions from synthesis to sustain. This is the part of the process we're most that most aligns with what people think of when they think information architecture, which is the whole focus of our firm. But for this reason, the skills required to execute this work are typically present in organizations that otherwise struggle to bring clarity to the complexity of their digital world. In these cases, the product problem is not the ability of the UX team to develop good site plans and wireframes. But rather, the problem is an ingrained process that pushes to skip or rushed through much of the work that we've described up to this point that sets that process up for success. Hopefully, the descriptions that we've gone through today, and the rationale behind it can help you change that in your organization. Bob Royce A common question I get is how to fit information architecture into organizations that practice agile, Although I first worked on it agile projects in the late 1990s took me some years to come up with a good answer. The answer that evolved began with a recognition by a good friend of mine, Tom melosh, that the work we do in the program analysis and synthesis phase makes for a great agile backlog. And that's an area in his experience where most large organizations using agile struggle, they had to abandon the old waterfall ways with all of its heavy duty discovery and documentation, only to find that they missed the context of the big picture that those processes delivered over poorly. Tom and I both knew from experience that early agile teams coming often as they did from backgrounds in object oriented software development, would work through the kinds of sketches and models that we do in early iterations of their projects. They weren't in a rush to write code the way agile tends to be practiced today. Now, in theory, good agile practices cause for an extensive engagement with business stakeholders, who bring that big picture to the team and an ongoing basis. keep it fresh with input from what's happening within the organization, and how they're interacting with customers. And that can work, usually for about a year in my experience, but after that, it's all too common for the business, the voice of the customer to essentially go native and become a member of the IT department with business somewhere in their title. There's nothing wrong with this except that now the person that was bringing the big picture context has lost their place at the table in the business side of the world. This is okay if the project is focused on incremental improvements to an existing product, but it's shows its weakness when it comes to new product development. Where recently we've had a chance to work with several organizations that employ safe, the scaled agile framework for enterprise. I'm not going to take a position on where se falls within the Agile orthodoxy. But I'll note that I appreciate how it builds into the framework, the concept of a solution train, which is working to develop the solution. attempt for the project. This aligns very well with what we've discussed today that passes well suited for that solution intent activity. So in a safe environment, the work we've conducted up through synthesis can happen in parallel to other development trains. And then as the solution is well defined and validated through prototype testing, it can start to move into the p&i planning process, and the development team can start to observe or even participate in the finalizing the plans for the sustain phase. Here's an example of how a sustained phase might play out in this context, as shown in the top workstream. The taxonomy works such as finalizing a control vocabulary and governance process is happening throughout the phase as his work to update the object models to reflect the future state. In parallel, jobs to be done or expanded into story cards, and a skeleton of a journey map workout and synthesis is used as the spine for a story mapping exercise with business stakeholders to work out the details of the final design. These are then turned into Sitemaps and wireframes, which are then evaluated through prototyping and testing. This is very similar to what we did in synthesis, but at an increasing level of detail. In this way the entire digital plays can be designed and prototyped before ever moving to a formal development environment, or spinning up to an agile work stream. And it gives an opportunity for the agile team to work and observe what is happening well in advance of them of it being moved into their world and then having to develop it. Bob Royce I hope you found this to be a useful practical introduction to a process you can use to leverage the lens of information architecture more fully in your context. As we've discussed, the information architecture undergirding your digital experience can provide a foundation for a useful, scalable, even delightful user experience. If you take the time or your organization gives you the time to work through what good means to all the relevant parties. Learn to Gather about the current state, particularly in terms of the people coming to your site, and then move through some intermediate conceptual models of your solution before moving to detailed blueprints, blueprints, and plans for building. based on our experience, here's some examples of what success looks like when you're done. your stakeholders will feel like their goals for digital were taken into account. And they'll appreciate the challenge that every digital place faces balancing those different goals and desired outcomes. Your organization will have a clear high level map and model of the operational context for the place that facilitates good conversations. You'll have agreed upon hypotheses around the people that come to your digital place. your stakeholders will have a clear conceptual understanding of how the digital place is structured. And the builders will feel at ease as they go to build knowing they have a better picture of why, what who and how for this digital place than they've ever had before. Thanks for your time. Don't forget the addendum with my conversation with Joe, and I hope to see you again next year in person. Bob Royce So, Joe, thanks again for talking with me. We've been talking about how variety models work together across the process that we use. And I was really intrigued when you shared this with me because I think this diagram really does a good job of showing how the different models that we use flow together into setting up a prototype, a way of validating and testing what it is that we do with people that really makes sense and leverages many of the models that we've done in the past. So can you kind of talk us through this a little bit? Joe Elmendorf Yeah, so understanding this model. Joe Elmendorf going to start with the framework that Dan Klein And Andrea Resmini have around ontology topology, choreography, the idea that information architectures have these sort of nested levels. So ontology, the meaning is at the core level, and then building on that is the topology, how things are arranged. And then sort of the last most surface level is the choreography, how, how things and people interact with those things. So given that, as we create information architectures, there's sort of two, there's two areas, there's the information of the system itself, what are the things that we are making sense of what are the things that we are arranging? And then there's the jobs the things that people want to do? Why are we arranging this information? Why does this information even exist? People want to use it for something. And so in the analysis and synthesis phases, we work to create these models and ask these questions. What is the meaning behind The parts of our information, we create object models that get at what are these core relationships at the the what level, not the how level. And we can test and make sure that we kind of get that right by talking to stakeholders and doing card sports with users. Similarly, on the on the job side, we can do audits of the jobs that people can do the things that the system lets and helps people do today. We call that a jobs analysis. That helps us align the information and the jobs at that core meaning level. Do we understand what these parts are? And then, when we get into the topological level, how things are arranged. We can ask how do we make sense of the parts of the information? We do that through Structural models, models that show what the parts are and how they relate to each other to make a whole. And we can align and test that through card sorts and tree tests. I'm sure many people have have done those kinds of models. They're very common for information architectures. And then on the job side, that arrangement, how do we make sense of how all these jobs work together as a whole. We make what are called archetype models, which are collections of jobs that are commonly situated. And we can use those jobs to frame conversations with, with users and with stakeholders to make sure that the kinds of things that a business's system is doing or the kinds of jobs that they want to support the kinds of people they want to have in their system. But it's only once you have these two. These two sides understood that Get at the choreographic level. Because the choreography isn't just about the information. It's about how people use the information to do a particular task or job. And so we need to have a core understanding leech. This the structural prototype is where we, we asked the question, how do we facilitate the movement and the interaction with the parts of information in order to fulfill that intent that is driving these jobs. We create these structural prototypes, because real people are not very good at using an understanding structural models. We use these prototypes to help us understand whether or not we are accomplishing that. That challenges of making this useful for people. Bob Royce Yeah. They're roughly equivalent to the balsa wood models that architects used to do. You know, if you could imagine kind of walking through and taking them to top off and seeing today, of course, they've got all kinds of computer rendering. But this is a way that we can help ensure that people are able to move through the core structures that are in place. I've described it to clients as when you get to the structural prototype, you'll be able to move around and find all of the things that you want to be able to do when you come to this place. And you'll see them there where it is that you would interact with them. They won't work, the levers won't work. The dials won't work. It's not a real thing. But you'll be able to see Oh, yeah, if I wanted to do this, I would be able to get there. And this is what I do. And then when I want to do the next thing, I'd be able to figure out can I get from there to the next thing? Oh, yeah, yep, that's where I would do that. And if you can do that, in a model that's being produced with very little code, right, these models are generally very stripped down HTML or InVision diagrams that are sketched and stitched together with links. They're very lightweight. So we're risking little of development in order to kind of iterate and work through and prove that we've got a underlying model there. Transcribed by https://otter.ai