Understanding information architecture (podcast)


Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on June 12, 2021 04:18 (5d ago)

What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.

Manage episode 283876352 series 2320086
Player FM과 저희 커뮤니티의 Scriptorium - The Content Strategy Experts 콘텐츠는 모두 원 저작자에게 속하며 Player FM이 아닌 작가가 저작권을 갖습니다. 오디오는 해당 서버에서 직접 스트리밍 됩니다. 구독 버튼을 눌러 Player FM에서 업데이트 현황을 확인하세요. 혹은 다른 팟캐스트 앱에서 URL을 불러오세요.

In episode 88 of The Content Strategy Experts podcast, Alan Pringle and special guest Amber Swope of DITA Strategies talk about information architecture.

“Information architecture is a role, not necessarily a position, but by ignoring it, you end up without the discipline and the consistency that really enables great customer experiences.”

– Amber Swope

Related links:

Twitter handles:


Alan Pringle: Welcome to the Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode we talk about information architecture with special guest, Amber Swope, of DITA Strategies. Hey everybody, I’m Alan Pringle, and today we have a guest on the podcast, Amber Swope, of DITA Strategies. Hey there, Amber?

Amber Swope: Hi there, Alan.

AP: So, let’s start with the basics here. Give me your definition of information architecture.

AS: Well, as you know there is no common definition of information architecture-

AP: No.

AS: … So rather than getting frustrated by that I chose that as an opportunity to own the version of it I want to have. So, I go with the Samantha Bailey definition that starts with information architecture is the art and science of organizing information so that it is find-able, manageable and useful. I really like that definition because it acknowledges that there’s art and science to this practice.

AP: Also, there’s not a whole lot of jargon in that definition, I appreciate that a lot too.

AS: Yeah. And particularly the science part is obvious to see. So for instance if you’re using an open standard DITA, then you could have five IAs, give them the same challenge, tell them which version of DITA they’re going to use, and they would probably come up with solutions that are 80% consistent. But that 20%, that art is where different information architects will bring to bear their experience and potentially give you something slightly different which is why it’s always great to have more than one information architect on a project.

AP: Sure. And there is absolutely an element of judgment call to it as you have said, it is not just a straightforward everybody’s going to do the same exact thing. There is no book basically that tells everyone how to do it exactly the same.

AS: And I also take this a step further and make a delineation between management information architecture and delivery information architecture. And I found that most information that is available for information architects is dedicated to delivery information architecture. That is the architecture, the structure, the metadata, et cetera, that is required to deliver information on a specific platform. So a mobile app, or a website, a portal, a working environment.

AS: And then there’s what I tend to do which is management information architecture. And the difference is that I’m tasked with creating an information architecture that can support omni-channel publishing to any of those platforms. I tend to work with companies that are trying to have a single source of truth that they manage in DITA but that serves different platforms, and each one of those platforms will have its own architecture because that architecture supports the display, usability, findability, et cetera, of that information.

AP: I think that is a very important distinction to make and it hearkens back to something that started in the late 1990s, the idea of single-sourcing, where you basically you have a source that is then output into a bunch of different formats and you’re not writing specifically for one format type.

AS: And that’s particularly powerful. And when you think about content that is to support learning, if you have content and you want to send it out to an LMS, you’re not going to structure it just for the LMS in the management architecture but the LMS, that experience is so important to learners that that architecture needs to be fully developed. And when you work in these larger projects the biggest challenge is first getting folks to acknowledge that they actually need information architecture as a separate discipline, and then next understanding that they need more than one. And understanding what those roles are and communicating which direction the requirements are going. And the reality is they’re both going both ways, and that leaves a lot of opportunity for some great collaboration but also an opportunity for some miscommunication.

AP: Sure. And I think this makes me want to ask the question, when should a group of content creators, a company, a department, whoever, when should they be thinking about information architecture? What’s kind of an inflection point where you say, “We really need to buckle down and think about this seriously?”

AS: Well, when I speak to a group of information developers or tech writers or whatever label you want to use for people who are creating content, I asked them, “How many of you are information architects?” And very rarely does anyone raise their hand. Then I ask, “Do you control the table of contents? Do you put in keywords or index words?” And everyone raises their hands. So, everyone’s doing information architecture as they create content in these organizations. I think the question really is when do you need to acknowledge it as a separate discipline? And I would say as soon as you have more than one deliverable. Because if you look at high-tech companies, one of the classic questions is, well, where does the troubleshooting information go? Does it go in the user guide? Does it go in a surfs guide? Where does that go?

AS: Well, that’s an architecture question. And if you have guidelines that indicate that user guides have this information, getting started guides have this information, administration guides have this other information, and it’s okay to have the same information in more than one deliverable or it’s not, that’s architecture. And I feel that it’s a disservice to not acknowledge that everyone’s doing it already. It’s a role, not necessarily a position, but by ignoring it you then end up not having the discipline and the consistency that really enables great customer experiences.

AP: I think that’s a very great point you just made. As people are creating content they are adding intelligence to it. They are categorizing that information oftentimes without even realizing that they’re doing it.

AS: And if you have more than one author then you have different people’s ideas and opinions and judgment calls. And I would argue that many of the style guides that teams have that allow folks to be more consistent, actually, most of the time incorporate a lot of the architecture. And that it might be helpful for teams to look at that information with a critical eye and say, if it’s about what information goes where, and what’s the structure of a specific deliverable, maybe it’s worth calling out into a separate section of the guide and acknowledging that this really is different than the words that you choose or how you format something.

AP: With IA, is it generally a project by itself or is there some trigger, some bigger corporate initiative that may make that happen or put attention toward it?

AS: I would love there to be projects where someone calls me up and says, “We just really want them have a great IA.” That never happens. Folks call up and say, “We are having this type of a business challenge. We understand that baking the structure of the content into the DTDs or baking it into the CMS structure, or completely ignoring the structures, the metadata that we need is causing us pain.” And then because IA is around the structure of the content and the metadata, and particularly if you’re working in XML, you don’t give people the raw XML, you always process it or render it with a transform. So it’s always going to be bound to additional work, you’re not going to go and change the IA and then not be able to generate the content. The simple answer is it’s always been part of a bigger project.

AS: When I look at projects like this I see the business question, what are we trying to achieve? And then I think of three dials or areas where we can control and make accommodations and improvements, architecture, technology, and process. And most challenges require some work in all three areas. What can the architecture do to give you more consistent, well-structured, more powerful content? What’s the technology that’s required to perhaps present that information in a better way to meet the user need? And then process, well, what processes need to change in order for us to produce the right content in a timely fashion?

AP: Those are really good ways to break it down. But if I’m talking to a C-level person, an executive, the person who has the money in their hand, how do you communicate to them about the importance of IA because I’m pretty sure telling them we’re going to get spiffy new tools is not the way to win that argument?

AS: Well, and it’s a challenge because everybody wants a simple answer, particularly in the U.S. where we get judged quarterly by our success or our failures. Most of these projects to make significant change or improvement take longer than a quarter, so the whole budget question is always difficult. The first challenge I think is for them to take a business challenge and understand when content is involved at all.

AP: Yes.

AS: Because once we say, “Oh, content is part of the solution,” then it immediately is, well, it’s not just the words but it’s also the structure, and at that point we can introduce the discussion around architecture, the role of architecture. And I’m actually working on a book with a coauthor about this exact challenge, is how should management understand when a business challenge involves content and when simply buying new software won’t be the answer because there’s always going to be some sales person out there offering them some sexy new software and telling them that it’ll fix everything.

AP: Indeed. And it usually doesn’t, says the narrator.

AS: Well, I would say it always doesn’t because the idea of buying software without understanding the inputs and outputs of it and the role of the people using it, that process, that’s how you end up with shelf-ware.

AP: Exactly. And I’ve seen that happen so many times I can’t even tell you, I’m sure you have too.

AS: Oh, yeah.

AP: Yeah. So there’s got to be some process here, some way to consider to map this out, especially to get that buy-in for the vision and then to implement it. Is there a loose process? Now, I realize this is a huge, huge leading question that we could talk about for hour upon hour. But is there’s some kind of a loose outline about how these projects go?

AS: Definitely. As with any challenge we want to start off with what the definition of success really is. Because we don’t want to make change, we want to make improvement and how will we know when we’re done if we don’t know what the goal is? And if you’re in a larger project, in larger organizations, a lot of times they’ll have a content strategist and the content strategist is usually the person who defines what success is. They work with the management team, understand what the challenge is and say, “Oh, okay, let’s talk about what success looks like from the contents point of view.”

AS: Then of course we want to understand the current status so we do some assessment to understand why is the current content, whether it’s its structure, its delivery, the actual words, it’s in the wrong language, where is the content falling short and what are we currently working with? For a lot of teams one of the biggest challenges is that they have multiple instances of the same content. And so it’s easy enough to write, but then when you go to update it’s like Pokemon, you have to go catch them all and you never do because you might be new, you might be busy or you might not even have access to the repository that has that fifth instance of that content. And that is why we really want to get to a single source of content in a management architecture so that when people need to update the content they simply do it once.

AS: After we know what we have, we want to look at the future state, what should the future state look like and understand taking the idea of success and making it concrete in a way that we can then start building toward. And then once we have this from the architectural point of view, I’m going to start looking at the deliverables, really looking at them and saying, “Okay, what’s this deliverable type? What’s its purpose? How should it be delivered? Is it for one or more audiences?” And when I mean deliverable, I mean a manual, an article, a course. If you’re a mobile app that has glossary quizzes, what is that thing that the end user consumes.

AS: And based upon the purpose and who it’s for then we can start looking at, well, what kind of content needs to be here to meet that purpose? And once we have the idea of what success looks like for the deliverable then we can look at the content types. In some organizations the content types are super basic. They have concept task, reference glossary, maybe some troubleshooting. If you’re in education you’re going to have learning objectives, you’re going to have questions, you’re going to have overviews, you’re going to have summaries. And the more specific your industry is, I have found the more content types you potentially have.

AP: Yeah. We’ve had that experience as well, I agree with that.

AS: When I say content type I’m not necessarily referring to an official topic type. For instance, you don’t have to specialize to get a content type. If the content structure is the same but you really want to identify the purpose of the content so that you can empower a more nuanced delivery. So for instance, if you have glossary terms, the glossary structure, for instance in DITA, but maybe you want to include that this is a vocabulary word versus this… And it’s for a specific industry or you want to say, “Oh no, this is a chemistry formula.” That’s a very specific purpose. And you don’t have to specialize, you can use the base topic, but then you are identifying for downstream systems what the content type really is.

AS: And when we know that then we can look at its structure. And what our goal is is for us to be super clear for the people creating the content what purpose is that they’re writing it, because creating smaller, modular, structured content is still a new concept to a lot of content authors. And even though it started way back with information mapping and has been used through multiple systems including DITA, the idea that you would write and store pieces of content for different purposes is still a big change for lots of authors.

AP: It is and if it were not we wouldn’t be employed, quite frankly.

AS: Indeed. And so once we have some idea about what the structure should be then we’re going to do some proof of concepts and try out some lightweight mock-ups and understand how things come together. And what I typically do is I start with what they do now and replicate it and then we start thinking about the art of the possible. Because, we’re not being brought in to ask them to recreate what they have now, because they have a business challenge that what they now doesn’t meet. Understanding what that change is, what’s that delta is really important from a structural point of view because we can’t help the authors make that journey to the new format and the new structure unless we fully understand it. So I’m a big fan of recreating doing a proof of concept, understanding with the stakeholders why what they have doesn’t work because me telling them that usually is not enough.

AP: No, but it does help that you’re a third party voice coming in there. And I’m actually very glad that you brought up proofs of concept because there is always on these kinds of projects a chicken and egg challenge with the tools and technologies. If you’re doing the information architecture and laying that all out, at that point you often don’t have the tools that will do the transformation, or the tools that they’ll be using for authoring. So how do you balance that lack of tools and doing these proofs of concept? How do you handle that chasm, for lack of a better word?

AS: Well, I start with what DITA gives us for free. Because it’s an open standard we have the open toolkit and a lot of the authoring vendors provide multiple transforms. And so I go with what I have available. Because it’s a proof of concept I don’t want to invest development time if I can help it and I see what I can get. So for instance, if I’m trying to show people how they can get different types of associations that can be represented as links in the output, I’ll just use a tripping helper, an HTML5, a transform, just to show them, hey, this is what you get. That’s particularly useful when you’re trying to explain to people why they will no longer have to manually manage and type the link text for all their links particularly if they’re hierarchical.

AP: Yeah. And I know having worked with you on some past projects, you’ve often even not even touched DITA tools to do proof of concept, for example, doing mock-ups of a table as they stand now and then doing a future state table using Excel or Word to show the differences and what’s possible without even actually having to touch DITA. Because you have that DITA knowledge, you can translate it in a way that’s very visual and help people understand without them even, or you really even having to touch the DITA code, I think that’s also very helpful.

AS: Well, that’s the thing and this is the chicken and egg part of it that you mentioned, Alan, which is, I’m trying to help folks understand what they can do with their content and they shouldn’t have to know DITA in order to be able to communicate their needs to me.

AP: Absolutely. Really, it is a situation where they need to bring their expertise and that is with the current state and with how process flow works and how information flow works. And it has to be basically combined with your expertise on DITA and whatever other model that may be, your case it is usually DITA. You’ve got to find a way to bring those two things together and have them sync for these projects to work, at least that’s my point of view.

AS: And I’m a big fan of using diagrams because first of all I’m very graphically-oriented, I love a good picture. And second, it allows me to help folks see past their words to see their structure. And the first version of the diagrams I do has no DITA in it, it literally, for instance if I were doing a diagram of a glossary unit and I wouldn’t even need to say the word topic, I’d say a glossary unit. It’s like, okay, we start off with the obvious, we have a term and a definition. Do we need abbreviations or some other alternate form? Okay, let’s talk about the alternate forms that you want. Do you need usage notes? What is it for instance, for the folks that did an application, a mobile app that tested glossaries, they’re basically digital flashcards.

AS: We had to say, “Oh, we need pronunciation here as well.” And that has nothing to do with the DITA elements I would use to support that, it’s helping the client communicate to me what does success look like, and like I said, I love using diagrams. I usually have two sets. I have a set for the structure and then I have a set that I then create that says, “Oh, here’s the DITA element,” and potentially the attributes I’m going to use to create and structure the information to meet the structure that they told me they needed.

AP: Yeah. And it’s almost baby steps, starting out simple and then adding another layer on top of it and that makes a great deal of sense to me.

AS: And I use the same ones over and over. I actually have a toolkit that I sell, that is the toolkit that I use with my clients. So not everybody has the opportunity to bring in a consultant but if you want the tools that I use you can get them.

AP: Absolutely. And before we wrap up, is there any one stumbling block that you can think of that really stands out based on your past experience where you can give a simple piece of advice to get around that stumbling block when you’re working on an IA project?

AS: I think that the biggest one is recognizing first that architecture is a separate discipline. And the second part of that is that you may have more than one architecture. Most companies I see have multiple ways that they are producing their content now and if we want to get into a management architecture we have to look at the input into that architecture and say, “How do we harmonize?” And I like the word harmonize because it allows me to express that we’re not making everything exactly the same, which when I say something like normalize it would imply massive change.

AS: Oh, no harmonize, I want everything to work together in one repository or repositories that they all have the same structure and then we can look at the downstream implications. So for instance if you’re doing a chatbot and you also have a self-guided troubleshooting and you have basic user manuals, you have FAQs, we should be able to structure the content and the management IA and empower it with the correct metadata so that you can deliver that content in the way that it needs to be delivered because for each of those platforms, which could be radically different if you think about the difference between an FAQ and a chatbot, that delivery IA is radically different.

AS: And most folks they’ve been thinking about it from the idea that, oh, we’re just going to push it out and it’s going to magically work on that platform and understanding that they will need to have two different IAs and take the effort to trace back from the delivery platform, back to the management IA to understand when metadata, specifically metadata gets assigned to which units. Is it one unit, is it a group of units, is it based on a map? Whatever that is, and recognize that there might be times when metadata never makes it back to the source, that it may need to be managed in different places. And so this idea about metadata being used to power the content needs to be discussed in the context of multiple architectures.

AS: And I find that that’s an evolving conversation that once we talk about it that way a light bulb goes on for people, but I wasn’t having that conversation two years ago with people. And I should have been, but it just became clear to me over the last couple of years that that is where I can really help folks understand how they can power their content in new and better ways. And maybe even using their existing content that they have and they just add a new delivery channel, whether or not they have to actually go back and touch their source, or whether there’s an opportunity to power it from a different place.

AP: That’s really good advice, I appreciate that. And I’ll be sure to include your website in the show notes so people can find you and continue this conversation with you. And with that, Amber, I want to thank you for your time, this has been a great conversation.

AS: Well, thank you, Alan. You’ve given me an opportunity to talk about one of my favorite subjects, I love talking about architecture.

AP: Well, we’re glad to do it, thanks again. Thank you for listening to the Content Strategy Experts podcast, brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post Understanding information architecture (podcast) appeared first on Scriptorium.

78 에피소드