[Intro Music]
[Ryan Weber] Welcome to 10-Minute Tech Comm. This is Ryan Weber at the University of Alabama in Huntsville, and I’m excited to introduce today’s guest.
[Jason Swarts] My name is Jason Swarts. I’m a Professor of English and Technical Communication at North Carolina State University in Raleigh. I do research on technical knowledge creation networking and communities.
[Weber] Jason wrote the recent book, Wicked, Incomplete, and Uncertain: User Support in the Wild and the Role of Technical Communication. The book looks at the way that changes in technology have changed user needs and therefore changed the work of technical communicators alongside them. We’ll get to the interview with Jason in just a moment but first I’ve asked two friends of the podcast to introduce another podcast that you might be interested in checking out.
[Natasha Jones] Hi, I’m Natasha
[Genevieve Garcia de Mueller] And I’m Genevieve Jones And we host Chingonas and Bad Bitches.
[Garcia de Mueller] The podcast explores lives and experiences of Women of Color in academia. We focus on issues such as parenting, publishing, policy, and pop music.
[Jones] You can follow us on Twitter at bad_woc and you can also find our podcast on Buzzsprout, Stitcher, and Google Play.
[Begin Interview]
[Weber] Welcome to the podcast Jason. I’m really excited to talk with you about your recent book and about the changes that are coming for technical communicators and how they interact with their audiences, and I guess that’s a good place to start. You argue in your book that recent changes to technologies and our relationship to technology requires changes to technical communication practices and genres. So, let’s start with the first part, how are technological changes creating new demands?
[Jason Swarts] Well there’s a lot of ways, I think, I think what comes to mind first of all are all of the technologies that we’re encountering now. That they’re customizable, that they’re adaptable, that users can get in and can make changes to them, but also that we’re just developing technologies for smaller and smaller markets and for smaller use situations. And so, the result of that is often that we’re getting problems that people will encounter with their technologies that are unique to their particular installation or their unique to their particular situation. So, even for technologies that have broad market distribution to the extent that users are able to get in and make their own changes to it, you could end up with use situations and questions that are just not anticipatable by people who are writing documentation for it. So, you know that’s one of these changes I think we’re seeing but related to that is we’re seeing a cycle of updates and cycle of development for technologies that is pretty much continuous and incremental. And so, what we’re starting to see, you know, in a broad range of technologies are people who are using different versions of the same technology and there may be significant enough differences between those versions that while the basic functionalities of those technologies are the same, they’re compatibility with other peripheral technologies is not quite the same. And so, the systems that a user might get from user documentation for the software might not be entirely applicable to the situation that they’re using it in, depending upon which developmental version of the software they’re actually working with. Maybe the third part of this is that I hinted at this in my last answer, which is that increasingly these technologies are not standalone technologies and so we’re using technologies to interact with other technologies. So, what we’re looking at with any given user situation or user problem that someone might encounter, is that there’s a broader ecology of peripheral technologies that require interactions with the technologies that people might think about themselves as using. So, if they’re using something like excel, that might be the technology that they think of themselves as using, but it also ties in through scripts or it ties in through shared libraries or it ties in through you know any other kinds of calls to other technologies that would rely on that information. So, the problems that they encounter, you don’t know where the problems are located. So, that can be another challenge that technologies are seeing as well.
[Weber] Great. So, we’ve got this situation where technologies are customizable now to individual users or user groups. They are routinely updated in much more incremental ways and they are interacting more with various technologies. So, a user isn’t just using one thing. So, you know the traditional technical manual idea is, “Okay I’m going to write for these particular set of tasks that everyone is going to be completing with this technology and only this technology,” but it sounds like what you’re getting at is that users now demand a whole different set of information from technical communicators. Is that right?
[Swarts] I’d say that is right and they’re not always certain about what, what it is that they do need. So, there’s still a situation where users will need the kinds of standard user documentation that which should be with or be available with a new piece of software or a new piece of hardware for instance. Because there’s still a segment of the population that needs to use the default technology and needs to have that beginner’s knowledge. But once that technology gets into their hands, it takes on almost kind of like its own social life within a situation. The-they at least have to understand that technology, get more complex and that’s when that level of complexity outstrips the ability for standard approaches to user documentation to supply satisfactory answers.
[Weber] So, I mean I think this ties into your-your book is called wicked, uncertain, and incomplete, and I assume that these three adjectives refer to some of these challenges that have cropped up with the changes in technology. Can you talk a little bit more about why you chose that title?
[Swarts] Yeah sure. Well it’s, part ofit is I just like the ring of the title, and so (chuckle) so there’s that reason but some of these terms come from specific places too. So this, the term that was, the one that I started with, and I-in all versions of this title was played around with, and one adjective in it is wicked and it comes from research in sociology on wicked problems, which are problems that have no clear solutions to them. And that the solutions to those problems are continuously changing and there’s no one solution to it that is going to be satisfactory to all parties that are involved with it. And the best that you can get to is a solution that is good enough for now. It-that struck me as being a fitting description of the kinds of technological problems I was looking at. Not only are these problems that are continuously evolving and changing but they’re also problems that are tied up with situations. They’re problems that get tied up with values and you can’t really disentangle values in situations from what those problems are and so as a result you can’t ever really address some of these questions precisely. There are problems that you can address precisely but not all of them. So, not all problems are wicked problems but increasingly we are encountering wicked problems when it comes to our engagement with technology. Part of what I was trying to drive out with this is that I’m not sure that our documentation is set up to address wicked problems even though we’re starting to encounter those. So, I think uncertain has to do more with this potential lack of fit from standard answers to the situations that users are bringing to them, but also uncertain because when we are trying to think our way through the problems that we want to address with documentation, we can’t really see all of the interconnections that that problem has to other problems. And so, that adds to the complexity, which adds to the wickedness but when we recognize that we are trying to address uncertainty, then I think that that ends up changing the way that we think about what help documentation is trying to do. You’re not ever going to completely address uncertainty. You can begin to engage with uncertainty but you’re not going to supply the one answers that removes uncertainty. And so that then leads to I think incompleteness, which is recognizing that the task of providing documentation or providing user support is an incomplete process. Probably because of the long tail of development for technologies results in this long tail needed for different help solutions. One of the things I was noticing is looking through some of these threads on various, you know technology communities and someone will ask a question in say 2015 that you know gets some traffic for a couple of weeks. And you know somebody comes back four months later and they have the same problem, but the solution that was offered doesn’t work anymore because the versions have changed. That thread just stays perpetually open unless it gets managed in such a way that a person says, “The problem that we started with back in January 2015 is not the same problem anymore. It looks the same but it’s not the same problem,” so it’s you know closing that down and saying, “We need to open up something that’s brand new to address this and to basically grapple with the incompleteness of our answers by changing the way that we provide answers.” So, instead of thinking about it as providing static documentation that is meant to suffice between versions of the documentation itself, we’re saying, “Those answers are going to be incomplete and we need to then instead think about a way to engage more directly or interactively in order to scale the solutions the way that they need to be scaled.”
[Weber] So, I guess this really leads into kind of the big question, is you know for technical communicators facing these challenges and trying to help users deal with the these increasingly complex needs and tasks and technology use, scenarios that they have, how can we help? What can we do as technical communicators?
[Swarts] Well I think about there being a couple of things that we can do. Number one, the most important thing to keep in mind for me is that this is not an argument that says that, “Technical communication or technical communicators no longer have a place, no longer have the same place in the documentation production cycle that they currently do.” There are all kinds of problems that users encounter and that lead them to documentation, which are not wicked problems, that they are stable problems that what they’re doing is they’re coming to a technology and wanting to learn the default version. So, there’s always going to be a need for that kind of documentation. There’s always going to be a need for intra-organizational communication that technical communicators are doing to communicate between developers and the marketing people and the user experience groups. So, so that part of it, I don’t think really changes. I think what we’re looking at or what I’m trying to look at is this group of users that are generating these wicked problems because of the social nature of the technologies that they’re using but also the adaptive nature of those technologies. That part of what we’re trying to figure out is, what can technical communicators add to that process of help if the help that these users are getting are coming from other users. So, part of what we’re recognizing there is that there is help that is really in the act of giving help not in the product of help. So, to the extent that technical communicators can engage in the process of providing help, so conversationally engaging with users to figure out what these issues are and address them, and then to the extent that’s possible to take what’s learned from engaging in that conversation back to the development cycle or back to the product documentation cycle to change that documentation itself. That’s something that we can do. Even there that’s not really a scalable solution. It’s not economically feasible for a group of technical communicators to interact with all of the users who might be wanting to engage and talk about situations of use they’ve encountered. So, the result is I think we’ve got to figure out a way in which these communities of users that organizations are setting up and sometimes letting them run on their own, looking at the ways in which community engagement and community management might be part of that broader ecology of documentation practices. And this is something that you mentioned Ann Gentle’s book at the start of this podcast, it’s something that she talks about as well, but it’s more along the lines of saying, “We really ought to be looking at the ways in which we incorporate communities of users into documentation,” but it’s a challenge to do that. And so part of it is figuring out, you know and this was really the goal of the study that I tried to talk about here, is can we figure out what it is that other users are providing as I guess a form of technical communication through engaged-direct engagement with users on these community sites? And if we can figure that out, is there something we can learn about what that process of knowledge creation looks like so that it could be, I don’t want to say managed by technical communicators, but it could be nudged by technical communicators so that we say nudge users into better articulations of what kinds of issues that they’re encountering. We nudge them to provide better feedback about what kinds of help solutions worked and why they worked, so that we have a better sense about what it is that we can learn from that both to help other users but also to factor back into the development of a better technology all together.
[Weber] So, here you’re talking about you know maybe a user help board where a one-user, like you said, poses a question you know, “I don’t know how to do this with this product,” and another user answers that question, and they are kind of engaging and helping each other. And you’re suggesting that technical communicators can both lean from that process but also kind of facilitate that process in a way that makes it a little more effective.
[Swarts] I think so. Definitely facilitating that process is a good way to put it because the training that we bring as people who are skilled in rhetoric, people skilled in communication, people skilled in writing, people with a humanities background, I think in a lot of cases we bring to the situations an understanding of how to interpret user experience and how help talk about those experiences directly in a way that leads to a better engagement but also a better solution that comes from that conversation.
[Weber] So, really what you’re saying is you know this is not bad news for technical communicators, it’s exciting news.
[Swarts] Oh, I definitely think so. It-I think it opens up a new place where we can see the value that technical communicators are bringing to an organization. If we pitch our tents on our ability to produce written documentation that attempts to provide standard solutions to standard problems, then we start to run up against situations where, as we’ve already starting to see, where people are not using that documentation. And they’re instead turning to these, these communities forums but these community forums are not always the best places to get help either. They can be a little chaotic. They can be a little messy. They can be wrong at times and to the extent that technical communicators are able to recognize, number one that knowledge work is taking place in those settings and that there is different kinds of knowledge that’s being generated that is both user-facing but is also organization-facing. That they can get into that process and figure out a way both, one, to understand it and two, to contribute to it, and then also to take something back from that as knowledge that is worth preserving and making available to future users but also making available to an organization.
[Weber] Great, great. Well I really appreciate your insight on this. I know a lot of technical communicators are probably wondering, you know how they fit in with this larger situation. So, I really appreciate your insight.
[Swarts] Yeah, thanks for the invitation. I really appreciate it.