Dianna Deeney interviews Scott Abel about 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.
This episode is Part 2 of our interview. Part 1 (published earlier) was a discussion involving information development management. This Part 2 focuses on technical communication in design.
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.
Scott and Dianna talk about:
Visit the podcast blog for extra information and links! 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 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.
This episode is Part 2 of our interview. Part 1 (published earlier) was a discussion involving information development management. This Part 2 focuses on technical communication in design.
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.
Scott and Dianna talk about:
Visit the podcast blog for extra information and links! 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. Today I'm interviewing Scott Abel, who is an expert in the field of technical documentation and product information. My interview with Scott is in two parts. Last week was part one and we talked about information development management. You're now listening to part two of my interview with Scott, where we will be getting more into technical communication in design. 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. 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. I will tell you more about Scott and we'll get into our interview after this brief introduction. 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. We're talking with Scott Abel.
Speaker 1:While working on cross-functional teams, scott often serves as chief content strategist. Typically, organizations involve content strategists for one of two purposes. Content strategists get involved to solve focus problems such as making a website mobile friendly or communicating with more brevity and better comprehension. Another reason that content strategists get involved is to diagnose business critical content related challenges. By this we mean optimizing and improving content production processes. This is so the organization can efficiently produce and distribute content, and that helps them achieve their business and customer goals.
Speaker 1:So let's get into our interview with Scott about information development and product development. So I'm an engineering and product development developing physical products and information is a big part of that product. Like we've been talking about information developers being part of the team and developing these modules along with the product being developed and we had touched on a little bit earlier risk 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.
Speaker 1: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 and that's where I think information developers and the product development engineers can really team up to 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. So do information developers, and 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 averse industries. So anything that will kill you, right? Aerospace, pharmaceuticals, weapons development, travel, you know 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 1:Yeah.
Speaker 2: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 there's 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, and 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 verb Bowton, 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 languages 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 it will guide them toward better words.
Speaker 2: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 these 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 that the information developer has so many roles that can help companies to 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 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. I'm not sure, if 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, 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. 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. This is totally beneath them and not the jobs. And yet many companies. There's still people who see writing as 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.
Speaker 2:But we are very structured. We have rules, we have tools that will 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. 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.
Speaker 2:You can sort the information, you can rank it, you could syndicate it.
Speaker 2: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.
Speaker 2:So documents like a Microsoft Word document, that's an unstructured document. It could be structured visually, like you have a headline or a 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 a thing that would lead to successful product designs in the field.
Speaker 2:Yeah, and 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 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 make 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 Codi Awards, run by the Software Information Industry Association so SIIA, the Codi Awards 38th Annual Contest, which is considered to be the Academy Awards of the web they added a category called Best Knowledge Center. 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 a 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:Another 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 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?
Speaker 1:there is a lot.
Speaker 2: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 they'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 what 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 it 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, 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. Then 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 in 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. Yes, did you need to 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. Instead, you have to do tons of research to retroactively go back and figure out things.
Speaker 2: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 lifecycle, 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: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 fix 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, make it that I'm not here to get something from you. I'm here because I realize 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. They totally do. And if there's an absence of information, they experience that as well. And in survey after survey after survey, consumers in 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. And if they have a problem, they want an easy solution. They don't want to be waiting on hold for 45 minutes. They're disconnected back into press one, press two to be disconnected land. 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. 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 evolves 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, 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.
Speaker 2: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 something 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. 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. 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 technical documentationcom, the language of cybersecuritycom, 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 use the advanced information 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 our 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:Okay, Scott, which term is on your t-shirt? Do you have a t-shirt?
Speaker 2:It is content strategy. And it is it's 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 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 thecontentranglercom. Scott at thecontentranglercom, and I'll be happy to reply to you.
Speaker 1:Well, scott, we boy. We talked a lot of today. I learned a lot. 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 OQualityDuringDesigncom 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 people out there that are probably conjuring up something very specific to the industry in which your listener might be working in.
Speaker 1:Well, 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.
Speaker 1:And that wraps up our interview with Scott Abel. We just completed part two. Remember that Scott's interview is in two parts. If you missed part one, go to qualityduringdesigncom and search for Scott Abel within the blog. From there you'll find part one of our interview and you'll also find a blog post for this episode with extra links and ways to contact Scott. I hope you've enjoyed this special episode of a chat with cross-functional experts. Thank you for listening.