Dianna Deeney interviews Scott Abel about information development management, a discipline concerned with best practices for managing and coordinating all activities related to the development, production, and distribution of information. He shares ideas, strategies, and best practices for unifying all product information - technical documentation, product specifications, customer support, training, and on-boarding - in a single online knowledge center.
This is Part 1 of 2 episodes with Scott. In Part 1 (this episode) we talk about information development management. In Part 2 (next episode), we talk about technical communication as part of product design success.
This interview is part of our series, “A Chat with Cross Functional Experts". Our focus is speaking with people that are typically part of a cross-functional team within engineering projects. We discuss their viewpoints and perspectives regarding new products, the values they bring to new product development, and how they're involved and work with product design engineering teammates.
About Scott
Scott Abel serves as Content Strategy Evangelist at Heretto. He also runs a consultancy called The Content Wrangler, which helps companies improve how they author, maintain, manage, and deliver technical product information to those who need it, when, where, and how they prefer it. He writes regularly for content industry publications, produces a series of content strategy-focused books for XML Press, and is a dynamic presenter often featured at content industry events worldwide.
In Part 1, Scott and Dianna talk about:
Visit the podcast blog for links and extra information! www.qualityduringdesign.com
Give us a Rating & Review
**NEW COURSE**
FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here
**FREE RESOURCES**
Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.
About me
Dianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods.
She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.
She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.
Dianna Deeney interviews Scott Abel about information development management, a discipline concerned with best practices for managing and coordinating all activities related to the development, production, and distribution of information. He shares ideas, strategies, and best practices for unifying all product information - technical documentation, product specifications, customer support, training, and on-boarding - in a single online knowledge center.
This is Part 1 of 2 episodes with Scott. In Part 1 (this episode) we talk about information development management. In Part 2 (next episode), we talk about technical communication as part of product design success.
This interview is part of our series, “A Chat with Cross Functional Experts". Our focus is speaking with people that are typically part of a cross-functional team within engineering projects. We discuss their viewpoints and perspectives regarding new products, the values they bring to new product development, and how they're involved and work with product design engineering teammates.
About Scott
Scott Abel serves as Content Strategy Evangelist at Heretto. He also runs a consultancy called The Content Wrangler, which helps companies improve how they author, maintain, manage, and deliver technical product information to those who need it, when, where, and how they prefer it. He writes regularly for content industry publications, produces a series of content strategy-focused books for XML Press, and is a dynamic presenter often featured at content industry events worldwide.
In Part 1, Scott and Dianna talk about:
Visit the podcast blog for links and extra information! www.qualityduringdesign.com
Give us a Rating & Review
**NEW COURSE**
FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here
**FREE RESOURCES**
Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.
About me
Dianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods.
She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.
She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.
Hello, it's Diana Dini. This episode is a special episode. It's part of our series A Chat with Cross-Functional Experts, where we interview and speak with people that are typically part of a cross-functional team within engineering projects. We discuss their viewpoints and perspectives regarding new products, the values they bring to new product development and how they're involved and work with product design engineering teammates. Today, I'm interviewing Scott Abel, who is an expert in the field of technical documentation and product information. He's with us here today to share ideas, strategies and best practices for unifying all product information in a single online knowledge center. This includes technical documentation, product specifications, customer support, training and onboarding. Scott's also here to share his thoughts on why members of the technical documentation team should be brought into product design process earlier rather than later, and to encourage product design teams to incorporate the insights available from technical documentation professionals into their design decisions. I will tell you more about Scott and we'll get into our interview after this brief introduction.
Speaker 1:Hello and welcome to Quality During Design, the place to use quality thinking to create products others love for less. Each week, we talk about ways to use quality during design, engineering and product development. I'm Diana Dini. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join us. Visit qualityduringdesigncom. Welcome back.
Speaker 1:We're going to be talking with Scott Able today. Let me tell you a little bit more about Scott. He has spent the better part of the past two decades advocating for the adoption of advanced information development management practices. Information development management is a discipline concerned with best practices for managing and coordinating all activities related to the development, production and distribution of information. Scott has helped dozens of organizations around the world transform the way they produce product information by adopting a unified content strategy, a repeatable, scalable approach to creating, managing and delivering product information. Organizations that put in place a unified content strategy are capable of delivering the right information to the right people and machines at the right place and time, in the right languages and formats, on demand and at scale.
Speaker 1:While working on cross-functional teams, Scott often serves as a chief content strategist. Typically, organizations involve content strategists for one of two purposes. One is to solve focused problems, such as making a website mobile-friendly or communicating with more brevity and better comprehension, or two, to diagnose business-critical content-related challenges, such as optimizing and improving content production processes, so the organization can efficiently produce and distribute content that helps them achieve their business and customer goals. After listening to this episode, you will come away with a better understanding of what information developers do, how they affect our product design and its success in the field, and the kind of questions and strategies that they employ for information. So let's get into our interview with Scott about information development and product development. Hello Scott, A warm welcome to you for joining the Quality During Design community.
Speaker 2:Hey, thanks for having me today, Diana.
Speaker 1:I'm glad to be talking to a technical communication expert, or you're an expert in the field of technical documentation. We talk about product design, on the Quality During Design, and I think that you're going to be able to provide a lot of different perspectives on product design and product design engineering from your viewpoint. So I'm really looking forward to talking with you today about that.
Speaker 2:Excellent. I am equally as excited, so let's do it.
Speaker 1:You've been talking offline here and you've spent the better part of the past two decades advocating for advanced information development management practices, and from what I've known from our conversations and our emails is that this is a pretty broad and very important aspect of a product design that maybe product design engineers don't get to see or think about very often. Can you describe a little bit about what that is and what it entails?
Speaker 2:Yeah, the documentation has primarily been thought of as a post-sale deliverable, and I'll translate that into content that's provided to consumers after they purchase a product. And oftentimes it is thought of by the people who design products not all but some as a necessary evil. It's something that they have to do and somebody will do it, a writer will do it, and it becomes kind of a task that doesn't have the same level of importance or scrutiny or governance or any of the other important things that we want to do when we try to efficiently and effectively design products. Yet there are also some companies who recognize that the content that they produce that helps people use the product is the product. Sometimes it is the product itself, the information. Other times it is useless to have a product without the information that you need. For example, a computer system. It's nice if you purchase one, but if you don't know how to implement it that's not really going to bring you any value.
Speaker 2:So documentation has been thought of as this extra thing and my argument has been that it's a business asset that has many, many, many ways of bringing a financial return back to the company, either through post-sale loyalty, keeping customers who have purchased our products happy, so they think positively of our brand and they would like to return again to purchase other products.
Speaker 2:Or in the case of prospective customers who are looking for a solution to whatever problem they may have, be it a software solution or a consumer electronics product, a car or something else that you might talk about on your show, those interactions that people have before they buy are often informed by searches that they do on the web, and Google likes to reward the searcher with relevant content about the product, and it turns out that when you publish a bunch of product information, including technical documentation, to the web, it's viewed as authoritative content by Google.
Speaker 2:It's also seen as relevant and loaded with keywords. So it's a great SEO tool to bring new potential prospects into a company, and the company could then have an opportunity to make their products visible so that the prospective customer can be aware, and so without awareness you can't develop an interest in a product and you can't purchase it. So technical documentation has been seen as this not so important thing, but it really is for the success of the existing customer, for the loyalty of the customer to your brand, for attracting new audiences through organic search and for providing confidence that the selection that a prospective customer might make to purchase your product was a good decision, because they can kind of peer into your company and see if you care about them or not. Are you providing content that's useful and helpful to the audience that you're trying to attract?
Speaker 1:Yes, and you listed a lot of business assets there that this technical documentation can provide.
Speaker 1:And I can see myself when I'm searching for a product Maybe it's because of my engineering background, but I look and I dig for that kind of information and that doesn't form whether or not I make purchases. So the market asset I can definitely see and just being consumers of products, that seems more transparent, like you can see yourself looking for that information and thinking that way about things. But also, you mentioned that this type of communication can also be a design asset. So with product design engineers at Quality During Design, we promote early cross-functional teamwork, product design engineers reaching out and getting design inputs from marketing or from sales, from the supplier management people and from quality and reliability, and I think technical documentation falls into that also. So have you been involved with new product development projects? If you can tell us about some of them that you might have been involved with and how you were able to work with a design team, or maybe you have a nightmare project that you have worked on that you really wish best practices had been followed instead.
Speaker 2:Let me tell you about one that comes to mind off the top of my head that might resonate with some of your listeners. I work at the pharmaceutical company. They're in the business of only developing products and selling products. They don't do anything else. Their goal is to have their products approved by regulators and without that approval they cannot sell their products legally anywhere in the world. So the design of a drug is based on a lot of research and it's expensive to do, and when they discover something new, they, being pharmaceutical industry, the company that discovers it files a patent on that product and, assuming that the patent is approved, they have the life of the patent to protect their intellectual property, and that means that they need to get their drug approved and sell it and make as much money as possible before the patent runs out. When the patent runs out, competitors can jump in, grab all their research, make the drug without having to invest in having done any of that research or product development activities, and they can simply clone the product and make it generic, which is great for many reasons. So I'm not complaining about that. The difficulty is that the pharmaceutical company is seeking investment money from people to invest in product development and the investors want to get a return on their development dollars and so they want the company to be as effective and efficient as possible and they want them to be able to submit the content to the regulators and get the drug approved as quickly as possible, because every single day that the drug is not approved and is not available for sale is the day that the patent expires another day sooner. So it's kind of a rush to get the most money value right, most sales value from a product before its patent expires. Content treated like a post sale deliverable, means that they would just make the product and then somebody would write some instructions and stick it in the package and call it a day and then send it off. But with the regulated products, the instructions are also having to be scrutinized by the regulators, which means that all the product packaging and all the instructions for use and all the warnings and all the training and all anything that you have about your product also has to be approved. Not just the fact that you've got a product and you want to sell it, but all the information has to run through a regulatory filter.
Speaker 2:When you have people who think about content as a necessary evil. They don't see the potential like the pharmaceutical company does. The pharmaceutical company knows that if we put this content together and get it to the regulators tomorrow, then the day after tomorrow the regulators can start the process of slating in for review all of that information and eventually the drug will be approved faster. Elinters sometimes have challenges thinking like business people or thinking like product developers, for example, because we're often so attached historically to our grammar that's our superpower is our ability to communicate with words. Yet that's not the goal of the pharmaceutical company. We're not trying to produce lofty pros that people are impressed by. We're trying to produce information that a regulator will approve a drug so they can start immediately selling it. In the pharmaceutical example, the product team is concerned about us getting done fast, so they just want us to shortcut things. They don't think it's important. Then the pharma company they understand that it is important because if you were to submit information, let's say, had an inaccuracy, let's say that in the new drug application you claim that you discovered this product in the rainforest in some remote place and you found this plant that had this magical healing power. You've turned it into a product and you discovered it in 1988. But later in the same document they referenced 1989. The regulator could and has in the past said that's an incongruity or inconsistency that shouldn't be in there. We can't trust the validity of all of your information if you can't even get that right.
Speaker 2:Documentation has a lot of governance and a lot of scrutiny. It's not just writers who are just typing some stuff and then pushing print. There's a large process involved in doing it In order to get it approved efficiently. The regulator has to be able to accommodate all of these submissions made by content people and product development teams at pharmaceutical companies. They had to develop a way to handle the content and to break up these big documents that we would send them they were somewhere around 80,000 pages and route the additional whatever section of the document to each individual employee at the regulator. Who would look at them? Because nobody's going to look at 80,000 pages one person. It breaks them up and it requires us to do it in a very disciplined way, using technology and using standards and things of that nature that a lot of product development people don't even know we do. They, I think, sometimes think that we open a blank page and then we type some stuff. How hard can it be Totally not our job.
Speaker 2:Our job is really a lot of research. We have to write to a structure. We have to have other tools in our arsenal. We have to understand terminology and localization and cognitive neuroscience. We have to understand how planning teams work, how product management works. We have to weasel our way in to a world in which product developers are trying to advance things like agile development methodologies. Then they want to chuck their product ideas over the fence to the writers without having them work in an agile way. So technical communicators are also scrum masters. We hold our own scrums, we participate in agile development and we're on some development teams that are savvy enough to see that part of the product is the content. That's one example.
Speaker 2:The horror story is when a company thinks that all the content that they have is sufficient because their employees read it and on the product development team and they understand it, they go yeah, sounds right to me. Then it really reads it. That's outside of the organization. It can't understand any of the words because we are littering our stuff with jargon that all of us understand but other people don't. And then the argument becomes well, how hard is it for the consumer? They can just Google it, yes, but they can Google it and find many different interpretations of the answer to the question that they want. We want them to have the precise answer that the brand producing the product wants to put out there. So there's a lot of work that goes into structuring our content, making it semantically rich and machine-processable. It not only has to be human-readable, but it has to be understandable by search engines, which is particularly important in a world where we have new tools, like those introduced recently to us, like ChatGPT, which rely on cues hidden in the content in order to deliver value.
Speaker 1:Yes, and your example was from the pharmaceutical industry and my background is a lot of medical device and it sounds very similar. It is very similar.
Speaker 2:The segue is that medical devices is also a specialty area of mine, and medical device is closer to technical writing than pharmaceutical writing. Pharmaceutical writing has so many potential risks involved with miscommunication, right, because some of those products can kill you, so there's a lot of scrutiny. Medical devices also have some risks, but it is probably less risky to have to look up some information about your pacemaker and then call your doctor to get an appointment than it is to kind of tinker with something that's much more likely to hurt you. No one's actually asking you to repair your own pacemaker, right, that's not. There's no DIY site for that, hopefully.
Speaker 2:But the medical devices are governed and regulated in a way that's similar to pharma, with less restrictions, but there are still restrictions nonetheless. And there are compliance fears that the product manufacturers who work to design and build these medical device products are fully aware of. They have a fear of what's called future fear, of non-compliance. I don't know if you've ever experienced this in your work in medical devices, but it's like, hey, we're doing things today the way we always have, and we're the second largest medical device company in the world. If we change and start doing things different, we have to go through compliance again, and what happens if we're found non-compliant. So let's just keep doing it the way we were doing it in 1970.
Speaker 2:And that's pretty much the way it is in many organizations today. There is a less. It's less likely that they will be aware of the information, of management advances that have been made in the last couple of decades and the benefits that it could provide all of their teams, internally and externally, if they just use science to think about the information. That's really my big argument is that we should be evidence informed about our decisions. We shouldn't have the think and feel decision making that occurs on a lot of product teams.
Speaker 1:Now I want to. You kind of ended there with product teams and you mentioned risk and I want to loop back to that. But before we get there, what's the official title or the umbrella title of someone in your field? Is it technical communicator? Technical writer is common, but I think it's not as common anymore.
Speaker 2:I don't think that there is one. My research has shown that people call themselves whatever they want to call themselves, and that companies actually don't really care. A lot of times, it is a replacement for a raise. So some technical communicators, for example, the discipline of content strategy which I'm content strategist as well has made its way into the business world, and so it would make sense that people who hear those two words, who are writers, think I know what the word content means and I know what the word strategy means. I create content and, of course, I do it strategically, so therefore I am a content strategist. Yes, ok, your question is they call themselves anything. I call them information developers as a generic topic, in order to accommodate marketing writers, technical writers, medical writers and people who help with writing editors, proofreaders, localizers, translators, information architects. They all kind of fit into that mold.
Speaker 1:I like that term the information developers You've mentioned in projects that sometimes they are integrated within the project team and they're working alongside the project team members with the design and developing this information and these technical communication products as the products being developed and they have interactions with the team. And then there's also the aspect of hey, you wrote something and this doesn't make a lot of sense. So there's also a sense of independence with these information developers. Do you find that technical communicators do they have to walk that fine line between being in the thick of it in the design and being independent, or is there more than one person that kind of picks that up? So there's really not a line that has to be walked, but just more than one person taking a look at what's being produced.
Speaker 2:Yeah, I think there are lines, and it depends right is the answer on what kind of company and what kind of management style you have and your culture, whether or not technical communicators are even involved in the process. So in some places they're treated as, hey, we did this product, figure out how it works and explain it to my grandma, you know, get busy While other companies and organizations integrate technical communicators onto the product development team. So they're there from day one, and that's the argument most consultants will make is that you should have them there from day one because they'll be intimately involved and working alongside you. Now, most of my experience recently, in the last 10 years or so, were with software as a service software developers and engineers. So they're developing digital products and they often follow agile development methodology.
Speaker 2:And on the teams where technical writers are embedded, they're all working together so that the product is being documented while it's being created, so they're involved in the sprint.
Speaker 2:They're involved in all of the activities. So the technical writers become very useful because sometimes they'll say hey, in the last version of the product, when we wrote about this thing that you just reused from a previous version of our product, we got tons of support calls and I talked to the support manager and they said that when we set it a different way, fewer people called. Let's stop using that word. So you may learn from having a technical writer embedded on a team things from their experience, because they're constantly customer focused. Other times they're in their own department, let's say the technical documentation department or maybe some kind of information management team, and they get brought in to work with the teams as they're developing their products. Software developers in particular sometimes feel like that is wasteful because they would prefer to be having the developers write all the documentation, Even though developers, when you talk to them, they don't really want to do that, because they enjoy solving problems with code and they may not be that good of a writer.
Speaker 2:So having somebody on the outside that comes in helps them in one respect but hinders them in another. Sometimes the architects and developers of the products say I spend 40% of my time now explaining to a technical writer rudimentary concepts from software development that all my developers already understand. So they don't always see the value of having somebody embedded, so they keep them kind of on the side. And then there's a third kind of role that some companies adopt, where marketing needs to know what product development is doing, because they have to eventually market and sell the product, and so they sometimes attend meetings too.
Speaker 2:So now you have people that are foreign to the development of the actual product, the people who are going to market it and the people who are going to document it on your teams. And so one approach has been let the marketers stay in their office and not have to attend any of these meetings. Instead, send the technical writers to the meeting and make them part of the team and make part of their job. To translate what the developers of the products are saying in their development, ease the languages that they use to describe what they're building and then to tell marketing. Here are the three things in the meeting that occurred that you need to know about. So they become kind of translators internally, so they can fill different roles and become very valuable for a product development team because of their experience.
Speaker 1:So I'm hearing you say that the information developers, they sort of are the bridge between the technical product development. They're very user-focused, so they're like a translator for the user and how they approach things and look at things, and they also translate things for marketing. Is that it? Did I get that right?
Speaker 2:It's kind of like they have to serve internal and external audiences, because if we put a group of people together and say you guys are going to develop a product, that group of people are going to develop familiarity with one another and habits of sharing information in a specific way and using specific words, and eventually they all get it. And so it becomes hard for them sometimes to explain to somebody like a technical writer what needs to be explained in a way that the technical writer can grab onto it and then translate that into meaningful language that's customer-focused. Whoever the customer is, an internal person or an external person, that challenge isn't always showcased. That's one of their big things that they can do is they can help you become better communicators. Now, we don't necessarily want to make developers of products be writers, but in some instances there are developers of products who can write well. It's just that they're two different disciplines and they cross each other and there's some reasons to understand one another, but they are very different. For example, sometimes a software developer might say to a content person we reuse our software code. So if we develop a way to write some code that allows you to use our software to print something, every time the print button is enabled on that software, we use the same code. It's called object-oriented programming. We write the code once and we use it in many places, but it's the same code over and over again.
Speaker 2:Well, writers do the same thing. We write a product description and then we repurpose it in multiple places. But we don't do what developers think we do. Some writers do, but more modern information management focused writers do not do copy and paste. For example, we write something once, we give it a name, it has a unique identifier and then we call it. Whenever we're writing a document, we pull in the pieces that are already pre-written. That assures us that we have one product description. So it's write it once, use it many times. Or it's also called, sometimes referred to as COPE, which is create once, publish everywhere.
Speaker 2:The idea there is that you have one single source of truth. So if you have one product description and the product changes, you change the product in one place and everywhere that that description was used, that it's linked to, will change automatically. If it's a deliverable, that can be changed. Obviously, a PDF is a picture of an image. It's an image, right. We can't change that. We could change anywhere. That's digital. So if you had your product description on 15 different web properties and in a training session, in a documentation area and in a marketing site, you could change it in one place and have it change and be accurate everywhere.
Speaker 2:But in order to do that, technical communicators have to do a lot of pre-work. We have to build models. We have to model the content. We have to structure it in a way that the computer understands. It's not about choosing fonts or decorating the document. It's about making it machine-readable and understandable by Google and by chatbots and by others.
Speaker 2:In order to do all that, we have to know a lot about the product and we have to push back sometimes and say wait a minute, why are you doing it this way? You're making it more complicated for us. Downstream, we also know things about what happens to our content after we are done with it, after a writer is done with it. It has to go to localization and translation, especially in a medical device company where you're probably selling your device across borders to people who speak other languages, or even internally in your own country. The United States is a great example you may have 10 different languages that you'll need to support in order to do that. It's not sufficient to just add more people to your staff. You can't scale that way. Our discipline of information development is really about how do we most efficiently and effectively produce this information, be capable of updating it, maintaining it, publishing it, delivering it, augmenting it for other people, sharing it, remembering it, personalizing it. There's just so many things that we do that we're much like product developers and engineers, but for content.
Speaker 1:Yes, I think a lot of the listeners will be able to identify with how you describe that information development management, which is what you're really promoting. That's interesting to hear how it's modular, and I like the cope acronym too. You said it was Create Once, publish everywhere.
Speaker 2:Everywhere. Yes, it's actually based on a thing called the Unified Content Strategy, which was invented by a person called Anne Rockley, r-o-c-k-l-e-y. She wrote a book in 1999 that I edited for her, called Managing Enterprise Content a Unified Content Strategy, where she proposed that we treat content like code. We manage it in the way that the engineers are managing their code and their project plans modularly. We identified these and named these little pieces of modular content components. Now there's an entire industry called Component Content Management. There are component content management systems. They're specifically designed to manage all the little pieces and then weave them together into the deliverables on demand.
Speaker 2:When somebody hits your website and they own a product, let's say you sell three different products, but they've only purchased one of those products. You can know that because you know you sold that to that person. When they log into their account, you can serve up just the information that's relevant to the product that they own. They can still find information about your other products that they don't own because you might want to sell them to them, but that's a different intent. When the viewer, when the person who comes to your website, is looking for information about a product they own, it's usually because they can't figure out how to do something with it and they have a question. Nobody wants to call support. This is a huge thing. By the way.
Speaker 2:Consumers hate calling support, so much so that I did a survey of a thousand consumers with SurveyMonkey. We asked the question and the question asked how people felt about calling support. One of the questions that we added for drama was you would rather do what I would rather do X than call support. It was like 60% of the people would rather clean the toilet than call support when given a choice. The reason that they give when you dig deeper is because the support agents are reading a script and they're being walked through a bunch of not very personalized experiences. Now, this may not be the case if you call Apple or somebody who's good at it, but if you call the average company especially cable companies, utilities, anything that we have to deal with on a daily basis, they are just not good at it.
Speaker 2:Banks, all of them. They just really have room for improvement. It's awesome because they've never componentized their content. They have documents and they wrote a document, let's say a specific document aimed at a specific purpose for a specific audience. You might be sort of in that audience, but maybe you straddle a different audience or maybe you're looking at it from an advantage point they've never thought of. Those companies don't have the ability to rearrange their information modules, which we call components, and deliver the information you need in the way that you need it, because they can't scale. By creating documents instead of content, they are limiting their deliverability and they're limiting the ability to personalize the experience.
Speaker 2:We all know that consumers hate customer support and we also know that leaders of companies hate paying for it. The solution is usually let's put all the content on the web and then people can self-serve themself, which is a great idea if you know how to do it. But most companies don't. They simply say we have a library of PDFs and now we've made them all available on one page Not very useful. That 80-page PDF is maybe the answer to my question, but first I have to find it, then I have to find the PDF, then I have to download the PDF or search the PDF or print the PDF or read the PDF. It's not the same thing as asking your talking device for an answer to a question.
Speaker 2:Consumers are being habituated. We are accustomed to the drive-through window mentality for everything. I ordered some stuff from Staples that was delivered within an hour. Now consumer demand is I want the information about your product and I expect you to be able to give it to me in a format that's appropriate for wherever I am. I may be on a mobile device, I may be inhibited by some kind of temporary disability or a permanent disability, I may have a language barrier, I may only have five seconds or five minutes, I may be in crisis.
Speaker 2:All of these things we have to do, we have to prepare for and we have to be able to provide the content at the moment that's needed. It's called the right information to the right person at the right time, in the right format, in the right language. Here's the kicker on the device of that person's choosing, you don't even get to choose. You have to prepare all of these for all of these potential scenarios In order to do it. Modularizing your content and then having a componentized content management system that can weave together a bunch of little components into a deliverable on demand for you, based on some criteria that the user would either supply through telling the system, or it could be by us monitoring your behavior, or maybe there's some information in your profile. All of those things come together to provide a great information experience. I feel like we're at the cusp of doing it right. This whole movement toward artificial intelligence has gotten people interested in content, but it's still a big roadblock for lots of companies.
Speaker 1:Yeah, well, it sounds like it would be a big system development for our company to adopt, but it's not undoable and it's certainly needed. I'm an engineering and product development developing physical products. Information is a big part of that product. We've been talking about information developers being part of the team and developing these modules along with the product being developed. We had touched on a little bit earlier risk.
Speaker 1:The engineering development team are developing this product. They're going to want to find the failures and understand what the failures are and try to mitigate those. But there are going to be things that are going to happen in the field with the field failures, or there's going to be. Maybe they did some usability studies and found that the product is okay, but in a very few instances this happens and they want to be able to direct the customers through that. That's where I think information developers and the product development engineers can really team up too for this right information at the right time and provide that to the people that are handling the complaints or interacting with the customers on the back end. They can help those complaint handlers be able to help the customer through that particular problem. Do information developers? I'm sure they get into risk and evaluating risk. Are they usually part of a risk management team? Do they get involved in risk management? How does risk and information developers how does that mix work?
Speaker 2:In my experience it's been risk adverse industries. So anything that will kill you, right? Aerospace, pharmaceuticals, weapons development, travel, all that, chemicals, any of those kind of things. There is a more likelihood that the teams of people involved will include information developers and other disciplines from inside the company, but traditionally it's not really thought of. People still think that writers are like artists and less like manufacturers, right? Which is silly, because writers actually have to follow a content manufacturing process. It's very much streamlined, exactly the way that a factory floor would be.
Speaker 2:We try to strip away any unnecessary steps. We try to automate manual processes. We try to, you know, shortcut our way right to the end so that we can produce a quality product with as few defects and as few risks as possible. And in order to do that it really takes a company that understands the disciplines and allows them to kind of meld together. So you have the product development understanding, the engineering that goes into that, the science behind how we're going to talk about it, what words we're going to use, how we're going to market and sell it, how we're going to support people internally. I think that also gets kind of overlooked. The content that these information developers produce isn't just some user manual that you might find not very useful, because one of the other things that consumers say is that they don't read the instructions right. So they don't want to call support and they don't want to read the instructions, which leaves them kind of with less visibility right into how the product is going to work and maybe a chance of making a mistake and making an error.
Speaker 2:But technical writers are often involved in things like warnings, cautions and dangers. Those are three different words. They have three different legal meanings. So if product development teams don't know that and they say, oh, we need a warning or a caution, you need another difference. There's a difference between a warning and a caution and a note and a danger and a tip and advice, and you know all these different vocabulary words and there are legal definitions for them. There's even science behind whether you should include a symbol next to the word warning and should the title of the warning contain words that also help you understand what to do about it. For example, the yield sign. We know what it means, but what do you do? Right, there's no instruction yield to us now we've become habituated to it as a yellow, you know diamond shaped sign. That means slow down. But the word yield itself doesn't contain any other words, in that, in those characters that tell you what to do, for example, there might be one call high voltage, don't touch. So they're telling you don't touch. That's right.
Speaker 2:Yeah, the science behind all of this and there are mistakes, that are risks that could cost millions of dollars, by the way, for the wrong information or missing information, omitted information, from not being in there, by skimping on product documentation and not understanding how they work. There's also this whole kind of litigious society that we live in.
Speaker 2:Yeah the words were not given the respect that they have are compiled into something called terms of service, which everybody clicks, a box that says that they read and nobody reads, right, that you agree to the terms of whatever software product you're using or whatever you bought, and those that the language that's in there has even been interpreted by some judges as intentionally cumbersome because it was written by lawyers. So lawyers do not have in mind customer experience. They have in mind liability, avoidance, right, yeah, mitigation, other concerning and important things, but nothing about the customer. And so what we like to say in the industry or at least I do it has to pass the judge Judy test, right. And so judge Judy, television court judge, and if anybody's ever watched her show, she's very entertaining and I would probably say the word I would use to describe her as no nonsense. So judge Judy would probably read it and say, yeah, that's a bunch of mumbo jumbo. I don't even know what that means and I'm the judge, right. So why? How do you expect this person here, who just came here, who has a limited education, who has no money and and they're struggling to use your product and they're suing you because you gave them all this mumbo jumbo instead of some straightforward language. So there's a lot of risk that can come in in places where content people could be valuable, but they're not always applied there, for example, even within the description I just gave you.
Speaker 2:That's a subset of technical communication called plain language, and so there are consultants who specialize in helping companies adopt plain language, or sometimes it's called plain English, but what they really mean is language. It's about simplifying things. So manufacturers and product developers and aerospace will be familiar with this limited, controlled vocabulary known as simplified technical English. So this is a subset of the English language and people at Boeing, for example, when they write product information about those airplanes, are only allowed to use this subset of English language words. I don't remember how many there are 1800, 18,000 or remember the number, but there's. It's a much smaller corpus than all of the dictionary and they only can use those words and their tools are optimized to prevent them from using any other words. And that's oh, wow, some of the other words they've been sued for.
Speaker 2:And so you don't want to say we put a word that's for both, for you know, forbidden or verboten if it were German into the style guide and then the writers read the style guide and therefore they will not make that mistake again.
Speaker 2:No, writers will totally write that they do not read the style guide every day.
Speaker 2:They're not sitting there with the style guide, so we've had to encode the rules for what language is allowed and what words are prohibited into the authoring environments that authors use so that if they want to use the word, the tool will prohibit them from doing that and then that will guide them toward better words. We're using that same functionality now in the political environment that we are in to make our language more inclusive and to reduce the chances of less than inclusive language slipping in which, by the way, product developers are primarily responsible for in some industries because the words that they introduced things like whitelist, blacklist, master and slave relationships, you know, which is a programming thing so things are viewed as not what you want in your content today, and so we're now in the process of also having to go back to legacy content and kind of clean it up If you're still going to use it. So the information developer has so many roles that can help companies reduce risk and reduce uncertainty and ambiguity and problems that could crop up that could be legal, ethical or otherwise.
Speaker 1:I've learned a lot from just just even this last part about risk, about all the things that information developers need to think about when they're creating their products for other physical products, and that they really should be an integral part of the engineering development team.
Speaker 2:Exactly and I'm not sure if I you know, I don't. I don't have an opinion about which model of management, of putting these teams together is the best. I think it might depend a little bit on the structure of the organization. You know the surrounding influencers and dependencies that you might have. The culture is also that the product of the people who are working there. It really all depends.
Speaker 2:But if you can get the writer closer to the beginning of the process and you can weave them in, you can find them to be useful for a lot of things. What they're not useful for is they're not your secretary. Do not ask them to take notes, do not add. This is totally beneath them and not the jobs. And yet many companies there's still people who see writing. As you know, they're like artists. They come up with these words. I don't know, I'm not a writer, right? I'm not creative. That's the kind of the thinking. And yet it's true, we do have to have creativity. But we are very structured. We have rules, we have tools that will not prevent or prohibit us from violating them. We have standards in place to make sure that our content is interoperable. That means that my content can be switched from one system to another without human intervention. That's not migration or conversion, that's interoperability. And in order to do that, two organizations or more have to agree on the same standard to exchange the information.
Speaker 2:Technical writers and information developers often write to a standard called the Darwin information typing architecture, or Ditta D I T A, as the acronym is usually referred to. It allows for companies to create information in a standardized way that's human readable, machine readable and interoperable, which also comes with lots of additional features. You can sort the information, you can rank it, you can syndicate it. You can do a lot of things you couldn't do with the precision that you would like to do with just what we call unstructured content. So documents like a Microsoft Word document, that's an unstructured document.
Speaker 2:It could be structured visually like you have a headline in it. You know our title. That appears at the same place every time you start a new section. There can be visual structure, but we're talking about semantic structure. We're declaring. Underneath the content and where you can't see it, we're adding extra information called metadata to tell machines what to do with the information that we're writing about our products. And most product development teams don't know we're doing that. Marketing is starting to realize it, because they realize that machines that process information and send people back to their website rely on that metadata to know where to send people and what information is valuable. So marketing is finally starting to be a silo. That's kind of cracking open a little bit, and marketers and technical communicators are working together in some companies to try to come up with strategic ways to sell the products that the product development team has invested so much time in creating.
Speaker 1:That is a good synergy the marketing, the technical communicators and the product development people. I can certainly see that being then. That would lead to successful product designs in the field.
Speaker 2:Yeah, and you know it's, I think, for technical communicators. For a long time they have not been recognized, but that's starting to change. So, for example, I tried to. I tried to discern how could I know if technical communication and information development is valuable. Now I've given you many reasons and those are all intellectually makes sense and we could all probably agree. Yeah, that probably makes sense. Yeah, that's probably true, but they never really were rewarded in the way that I think that is appropriate. So, for example, this year, the Cody Awards run by the Software Information Industry Association so SII, the Cody Awards 38th annual contest, which is considered to be the Academy Awards of the web Okay added a category called best knowledge center.
Speaker 2:So a knowledge center is an online portal where companies try to bring together all of their information about their products. Very few companies do it well, but the companies that do are amazing at what they do. It's not a marketing site, but it can actually drive through search. It can be a place where prospective customers land. Like you described earlier. When you're curious about a product, you sometimes search the web and that's maybe you land there. But these knowledge centers are super important to building customer experience that people will value and tell their friends about in a good way, and one of the things that technical communicators and information developers are struggling with is trying to figure out how to do this. And so, by having a third party contest, acknowledge that knowledge centers are important. This helps kind of elevate the message that technical information is important.
Speaker 2:And the third factor that I found was investment dollars Turns out. Investors don't invest in things they don't think are important. So it turns out that many of the companies that sell component content management systems the kind that technical communicators use to create content and more advanced companies they all received lots of investment money this year. No investors would invest if there's no reason to do that right, that's not a thing. So I can see that there's like a crack in the secretiveness you know about the information development value, and I can see product managers, marketing managers, customer satisfaction managers getting involved. For example, the customer satisfaction manager just wants the customer to be happy. So it turns out that maybe the marketing team wants people that are customers to come to their website and do whatever they want them to do there and they get counted. They count those clicks. That's their KPIs, those are their metrics.
Speaker 2:And then now Google is starting to see our content that we've made machine readable and if you've had this experience, you can ask Google. Try it tonight. Ask Google how to do something simple Like how do I change my password on Facebook? And it will not give you a link to a page to Facebook. It will instead serve up the answer and it goes to the Facebook website, where the technical writers made that content machine processable, and it sees this is a question and here is what it is how do I change my email address for Facebook.
Speaker 2:And here is the answer and it's provided by Facebook and it will serve that answer up in the browser, which means that the technical writers have done something negative to the marketing team, because the marketing team will not get the click For you to change your email address. You don't have to click through and go to the Facebook website, right? So you're not going to click. All you have to do is read it right there on the search engine results page. So if we think about product satisfaction, customer satisfaction, the product team should want the most advanced information management possible, because advanced information developers are going to semantically enhance the content so that it's so easy for search to find that it will serve up the answers to people, which also means that talking devices will be able to serve up the answers to people instead of I don't know. I can't help you with that, which is a big challenge.
Speaker 1:Wow.
Speaker 2:There's a lot, isn't there? I think there is a lot. There's so many topics we could go down, but I think for your audience, it's just important to know that this is a resource that sometimes underappreciated, and also some of the people and I realize I'm stereotyping, but some of the people in the industry are described as stereotypically introverted or let's put it a different way, and we're probably never invited to rethink how you ought to be developing your products, but they may contain information that would be helpful to doing so and you may be unaware of that.
Speaker 1:So for the product design engineer that is working on a particular module of a product and they're starting to design it and they're talking with their team to get design inputs, how would you recommend they find and approach their information developers within their company?
Speaker 2:I think the first thing to do is just to do the human thing. It takes somebody to coffee, go to lunch. They have just curious. What do you people do down there? How does it all come to be? I mean, we're developing this product and it's going to be launching in July. How does that even work? How do you guys keep up with this? How do you do everything?
Speaker 2:I think if you just go down and feel out the turf there and talk to the people, you can start to see who are the interesting people who will share with you, who is not afraid to step out of their comfort zone and maybe learn something new. I mean, it is challenging and sometimes scary as humans to learn new things. And so think about this If you're really great with the command of the English language and that's the language that you write in and that's your experience and people have rewarded you for that and now there's a product development team that invites you to go participate and you don't know anything about whatever they're doing let's call it radio therapy or software programming or building an airplane you might be nervous that you may think you're an impostor. Do you know about the impostor syndrome, where you know enough to know that you don't think you do because you haven't written a book on it or you haven't taught a class or whatever. There's a lot of that going on and I think if you go and you actually interact with people, you can start to find the people who will want to be your champions and want to work with you, and you can then start to figure out how do we cross pollinate, can we borrow your skills on our team? Can you dedicate time to that? Is your boss aware that you want to do this? Because sometimes there's just not this thoughtfulness about content until it's too late.
Speaker 2:Believe me, once one of those bad things happens that we discovered earlier, that changes everything. One of my pharmaceutical companies was sued for $80 million. As you can imagine, every one of my projects costs less than $80 million. So the thing I wanted to do to prevent the $80 million loss they were so happy to do as long as it costs less than $80 million. So these don't have to be $1 million problems, by the way. They could be inconveniences, they can cause time slippage, they can cause damage to brand and reputation which might be hard to quantify. So I think there's a lot to talk about there. You're right that bringing those two together is a good first step.
Speaker 1:Just knowing and understanding more about the information developers world, what it is they need to look for, because I sometimes take a customer approach to things. So, for example, with a product design engineer is creating a product. They're creating it for someone on the outside, an external customer, to be able to use, but there's a whole lot of internal customers that that design engineer has that they're the ones that are going to make the product actually happen and become a reality, from paper to actually holding something in your hand or using software on a computer. That includes the production people and the shipping and handling and the suppliers and the quality. So, looking at those as internal customers and I would also look at the information developers as an internal customer to the developer but also in parallel developing their own product that's going to support the success of the product design in the field. Did you have something to add to that?
Speaker 2:Yeah, I was going to say that seems to be the modus operandi for companies that are making application programming interfaces or APIs, so that one product can talk to another product and those APIs are understood by the development teams that make them and the developers that implement them.
Speaker 2:And then sometimes they say things like we don't really need any documentation, and so some companies just don't do it, and some companies do like a really really not very good job at it and they're not diligent about it. It's usually outdated or whatever. And when a developer comes along who does not know everything, the engineers who invented the product know which would be a new employee in your example, internal user. They come to the table super smart, with lots of experience elsewhere, and they expect to be able to read some stuff and understand what they should be doing. But because we didn't treat the information with the respect that it deserved, there's a lot of internal miscommunication that goes on because we don't invest the same amount of diligence into producing internal information that we do external information. So if you've got crappy external information, you can bet your internal information is way, messier.
Speaker 1:Yeah, that's a good observation. Yeah, I can totally see that being another need.
Speaker 2:Kind of. If you think about the software example for a minute, developers document their own code inside the code and then they leave. And then now it's your turn. Yeah, yes, did each of the plate. You are new and you are the developer of this product and you open the code and you read the comments and you don't know what it means or says.
Speaker 2:Instead, you have to do tons of research to retroactively go back and figure out things. It's just not productive. There's so many hidden costs to the information dilemma that I've been describing that if you rack them all up, it's a large percentage of wasted time. And if we were to optimize just a few things in the production of content, which we call the content life cycle, all the different steps that occur from ideation to archival or just destroying the product at the end, we have to kind of get rid of the information as well. So we have to do every single step along the way and it needs to be optimized. So right now, technical writers and information developers are going through exercises known as content operations projects. This would be content ops. You've probably heard of DevOps and other.
Speaker 2:It's the same thing, it's just for content.
Speaker 2:And so we kind of need to, I think, bring those people together.
Speaker 2:And I mean just think of under your example earlier, when you had the product guy or Gal who goes to meet with a technical writer and they find out that they're both trying to operationalize things.
Speaker 2:They have something in common they really are trying to get rid of waste and usually the product developers don't understand what the information developers are struggling with and they don't understand our process, so they don't know that they're creating problems for us and we don't always understand what the developers of the products and the designers and the product managers are struggling with. And when we better understand each other and the people that come before or after us, we can construct better operational models that accommodate everybody and don't break something downstream because we fixed something upstream. So I think there's kind of an ecosystem that we could build of like-minded individuals and companies who want to say how can we make our department and what we do interoperable with the department that writes about us? How can we look for ways to streamline the information swapping that needs to occur, the knowledge transfer that needs to occur? Could we do something different that in the end, has a better impact, and the answer is usually yes.
Speaker 1:And that it could all start with just that hello and have a cup of coffee.
Speaker 2:Yeah, that's all we could start with yeah.
Speaker 2:And even if it's just you have to do virtual coffee because of remote work, you know, make it a. I'm not here to get something from you. I'm here because I realized that information is part of our product and that the consumer experiences the information about our product, regardless of whether you believe that's true or not, like they totally do. And if there's an absence of information, they experience that as well. And then, survey after survey after survey, consumers and B2B or B2C, it doesn't matter will say that they would prefer to do business and pay even more for a product or service that doesn't cause them drama. If they have a problem, they want an easy solution. They don't want to be waiting on hold for 45 minutes. That, disconnected back into press one, press two, to be disconnected, land Right. They want to self serve. They want to find information themselves and they don't want to learn your vocabulary. They don't need to. They don't want to have to figure out what you meant, right. They need clear, concise information and it's not as simple as just writing a few words and saying we're done with it.
Speaker 2:It's really a process of it's evolved so like a content strategy for a company that's producing information about a product is a living thing.
Speaker 2:It changes every day based on the ebb and flow of the world.
Speaker 2:And what changes in technology and what changes in our culture. What legal I mean think about just the law surrounding AI companies are having to deal with the fact that some countries are like we forbid you from doing this, or, if you do it, you have to store that information on our soil. These were all things that no product developer was probably thinking when they came up with the nifty idea to make this tool that does some useful. But having all these information people involved in it means that you've got a higher likelihood of preventing some bad things from happening, probably improving your experience overall and reducing the friction that's caused when a consumer of your product cannot find what they want and that results in some kind of negative perception of your brand. So there's just so many reasons that you'd want to pay attention to it. Even if you only learned one or two little things that could make your product better, in the end, it would be worth it to have that relationship with the team that's going to document everything for you.
Speaker 1:I agree Now, just about with every profession it has its own acronyms, its own terms, and sometimes that can hinder communication. And I understand you have a couple of websites you can recommend for engineers to look at to sort that stuff out. Is that right?
Speaker 2:Yeah, there's a couple. I created a book series called the Language for a Company called XML Press. That's the publisher. Xml is a markup language that we use to write our content in, and the XML Press website has three books in it that are probably really useful. One is called the Language of Cybersecurity. There's another one called the Language of Technical Documentation and the third called the Language of Content Strategy.
Speaker 2:Each one of those have a URL the language of contentstrategycom, the language of technicaldocumentationcom, the language of cybersacuritycom, and if you go there, you'll see that I've recruited 52 experts and I ask each of the 52 experts to define one term that's related to our discipline. That helps explain why you need to know this word. So there's a definition, a short explanation of why you might need to understand that and then a little bit of information about the person who wrote it so you would understand contextually why that person is an expert and you should believe them. But those words were all terminology in our industry that people misused or used differently, just because humans right and we decided we didn't know that we had the be all and all definition for every word. But this was a good way to start the conversation and by having 52 experts in each one of these books, we were able to have the term of the week right 52 weeks in a year.
Speaker 2:And we were able to publish them on playing cards because we could have 52 cards in a deck of cards, so we had basically the content strategy term of the week or the technical documentation term of the week and we would print them on cards as well. And we were able to do that because we used the advanced deformation management practices I told you about earlier. We created those definitions once, but we plan to have many outputs, including t-shirts and playing cards, which are not traditional deliverables for a technical documentation team. But we were able to do that without reinventing the wheel, because we had thought thoughtfully about how we architect our information and how we're going to produce and deliver our deliverables.
Speaker 1:OK, Scott, which which term is on your t-shirt? Do you have a t-shirt?
Speaker 2:And it's content strategy and it is because I was involved early on in being a content strategist and I had my first business card that had the word content strategy as my title on it in the year 2000. And so I was a little bit ahead of the game with some other folks in that particular discipline. So that would be on mine and I think it's because I want people to recognize that we can think strategically about this stuff and that means we can make different decisions with how we create, manage and deliver information. And when you do it with a little bit of evidence and some science behind it, you can really do things that you just cannot normally do with just a creative brain.
Speaker 1:Now, if somebody wanted to contact you or maybe they listen to the podcast and have a question, or they want to explore an idea with you a little more may they reach out to you. And what's what's the best avenue or way to contact you.
Speaker 2:I'm on all the social media channels with the exception of Twitter, which I quit recently, but you can find me on LinkedIn, definitely, as Scott Abel. I also have an email address you can send to Scott at the content Wrangler and I'll be happy to reply to you. Well, scott, we boy, we talked a lot of today, I learned a lot.
Speaker 1:I think some of the other product design engineers listening will have gained appreciation of information developers and I will definitely link to those websites that you mentioned qualityduringdesigncom so they can click and get to those easily.
Speaker 2:Lovely, I appreciate that and for anybody that's kind of looking for bigger picture ideas. There are lots of companies that produce case studies about how they're working with their design teams and kind of cross pollinating work. So there's probably some great medium blogs out there and other social media sites where people are authoring and telling their stories. So don't think that I'm the keeper of this information. I'm just one of the instigators for getting people to think about it. But there are lots of super smart ways to do that For getting people to think about it. But there are lots of super smart people out there that are probably conjuring up something very specific to the industry in which your listener might be working in.
Speaker 1:That's great advice. Thanks, you're welcome. Well, scott, thank you very much for talking with us today. I appreciate it and I look forward to catching up again another time.
Speaker 2:Great Thanks for having me on the show today. I really appreciate it.