Technical Writing World
The social network for technical communicators
What are your arguments for doing and investing money in Technical Communication?
Everyone of us knows that there are still a lot of companies which don't invest in any technical communication position. A lot of let the documentation write by their engineers or others. Consequently, the people don't know that there can be a lot of improvement through style guides, terminology management, content management and so on.
My question to you is: What do you tell people when they ask you why your job is so important and why companies should invest money in documentation?
I hope we can have some brainstorming about this because sometimes I feel I am banging my head against a wall when I try to explain the people why they actually should hire someone of us :-)
Replies to This Discussion
-
Permalink Reply by Craig Haiss on
-
Great question, Ute!
I'd argue that Technical Communication directly impacts the bottom line of a company. Think about it... if consumers can't figure out how to use a product, they will stop using it. They will not recommend it to friends. They will post on product review sites that it is difficult to use, and others will avoid purchasing the product.
Well written documentation turns new users into power users. It helps them be more effective. They will tell others that your product is useful, and sales will increase as a result.
Great documentation increases usability and makes customers happy with their purchase. It lowers returns, decreases support calls, and more.
Technical communications makes money and saves money. That's why people should hire us! :o)
-
Permalink Reply by Jenny Berger on -
Further to the "increase sales" point -- many companies also consider the quality of the documentation as a weighted factor when deciding to buy a product in the first place, especially if it's a complex or niche product or a security product. So, if the product comes with poor doc or no doc at all, then no sale.
-
Permalink Reply by Ute Klingelhöfer on -
Personally, I don't agree with that. When I buy a product in a store (and not in a webshop), I look at the product itself, if it is easy to use and if it's rather self-explanatory. I don't think about the documentation. And then, when I buy the product and open the package, see the documentation, I have a quick look on it just because of my profession - I want to see how it is structured and layouted... Unless I don't have any problems with the product, I don't consider any look on the documentation. It might be sad, but for me it goes like this.
For more complex products apart from the consumer market, the factor of good documentation may count more. But the point, that there might be no documentation at all doesn't really count for me. At least in Germany, or the whole EU there are laws which say that you have to have a documentation, otherwise the product is "deficient".
I think about it more as Craig, if there is well-written documentation, then users can turn into power users, because they can help themselves - which will decrease the support costs. And instead a lot of "how-to-questions" and complains you will find good reviews on Google and tell your friends about the product.
-
Permalink Reply by Mark Baker on -
I agree with Ute. The case for docs is not universal or clearcut. In some cases, docs make absolutely no difference to buyer behavior. (Do you think anyone made a decision about bying an iPad based on the quality of its docs?)
Improving documentation in specific ways may increase sales for particular products at particular points in the market cycle. It may also be a legal requirement that docs exist, or cover certain functions. But in neither case can you state the case in general terms. You have to figure out how to build a case for the impact of docs on the actual sales or salability of your own product in your own marketplace at a particular point in the market cycle.
And be aware that the particular improvement you would like to make may not necessarilly be the improvement that will change user buying behavior. Perhaps you are a lover of beautiful books and your idea of improving the documentation is to make it a more beautiful book. But is your customer a lover of beautiful books who is willing to pay more for your product or service because its manual are beautiful books? (Hint: probably not.)
So you need to identify the improvements that actually will affect user buying behavior, and make a reasonable case for them. A good way to go about this would be to look at your company's net promotor scores, if your company gathers that data. Look to see how much influence docs have on whether your customers are net promotors or net detractors of your product. Try to figure out what about the documentation makes them net promotors or net detractors, then propose a plan to build on those areas in which they are net promotors, and fix those areas in which they are net detractors. You will find you then have a powerful and compelling buisiness case for an investment in tech pubs.
-
Permalink Reply by Sandy Stuckless on
-
I agree with Craig, but it goes further than customer documentation. What about internal process documentation such as work instructions, build instructions, internal forms and others that never leave the factory?
A lot of times the Tech Comms department is responsible for creating those as well. Having clear, concise, easy-to-use process docs goes a long way in having an efficient operation and providing a product that the customer as asked for, when they asked for it, which as Craig explains, directly impacts the bottom line.
-
Permalink Reply by Mark Baker on
-
Technical writers are traditionally terrible at attempting to express their value in business terms. Actually, technical writers are traditionally terrible at thinking about the product they deliver in terms of business value. "there can be a lot of improvement through style guides, terminology management, content management" -- okay, but what kinds of improvements? Only two things count here: reduced cost to create the product, and delivering value that customers are willing to pay for. Willing to pay for means actually willing to pay for. Not things we think people should be willing to pay for, but things that they actually are, in your marketplace today, actually willing to pay for.
And you know what, most businesses don't think about these things any more than technical writers do. They regard documentation as a necessary evil or a regulatory hurdle they have to jump through. Most of the time, they don't connect it to customer value, customer satisfaction, or customer loyalty. The upshot of this neglect is that tech writers tend to live in a bubble, isolated from the discipline of the market place, with little idea of what customer's value, and less idea of whether or not they are creating it.
Still, someone in your company is talking to customers. Find out who, and find out what customers are saying about their ability to find information on your product. That's were you will find out what customers actually value in docs, and if you are currently delivering it or not. And remember, quality means what the customer says it means. Everything else is overhead.
Recently I speculated that companies might benefit from concentrating the documentation effort on a particularl part of the product cycle. Here: http://everypageispageone.blogspot.com/2011/04/crossing-chasm-with-.... Speculation only, but maybe it provides a useful way of thinking about how docs can add value.
-
Permalink Reply by Ute Klingelhöfer on
-
Mark, thank you for your words. You really made the point I was heading for... we are terrible to express our value in business terms and we should work on that. You have good suggestions to change that.
I also read your blogpost and I think this is a real problem:
(..) there are a wealth of information sources available -- the websites, blogs, and forums set up by the innovators; the guy in the next cubicle who's been using the product for the last six months; their own experience with similar products. Docs are nice to have, but they tend to be a last resort, and if they are not there, or not complete, there are usually ways to work around the problem.
Who actually reads the documentation instead of looking for the solution on Google? When I'm looking for a function in - let's say - Microsoft Word I google it instead of using the Microsoft help. My friends who are the same age do the same whereas people of another generation still read the documentation. And as far as there are products which I am not using in front of a turned on computer, I have to use the printed documentation as well but some time the day will come where I can even have all the documentation on my (not yet existing) smartphone.
-
Permalink Reply by Steve Schwarzman on -
Mark's post of April 26 deserves a "Like" button to click on! It sums up perfectly how many tech writers don't frame the question correctly. What they think adds value is often meaningless to business managers.
Yet there is an added value, and writers - and especially tech writing managers - do well to understand that value, quantify it, and make that value known to their managers. Conversely, tech writing managers need to also educate their writers on which activities add value and which don't - and should therefore be curtailed. I wrote a section in my book on this kind of educating within and outside the tech writing group in a company because it is crucial to the long-term health of the group.
-
Permalink Reply by Sarah Maddox on -
Cool question! Here are some thoughts.
The marketing team and the finance team are often keen on these two things:
- Search engine optimisation (SEO).
- Tracking how customers and potential customers find their way to the place where the finally purchase the product (analytics).
A number of people have put some effort into proving that technical documentation is excellent for SEO, because it is well structured, dense with relevant terms, and concise. In fact, all the things we do as technical writers seem tailor-made for good SEO.
A good way to prove the worth of the documentation, both for SEO and for pushing people towards the sales point, is to install some sort of analytics tool.
I wrote a post about using Google Analytics. It's just a start, but it shows some pretty pictures from GA. There are also a number of interesting comments on the post:
http://ffeathers.wordpress.com/2011/01/22/google-analytics-stats-fr...
Let me know if you're interested, and I'll have a look around for the posts and articles that other people have written on this subject. :)
Cheers, Sarah
-
Permalink Reply by Ute Klingelhöfer on
-
Sarah, for me it would be interesting if you would post more on this subject because I am not sure if I get your point right. What shall one say to a company whose documentation could be improved, why should they hire one of us? Technical Documentation in the best case is indeed well structured and that is what it makes it SEO-friendly. But to use the documentation for SEO, the prerequisite would be that the company puts their documentation online (as in your post).
-
Permalink Reply by Sarah Maddox on
-
Hallo Ute
Yes, you're right. It's a prerequisite that the documentation is online. For some organisations and audiences, that is not relevant. But I'd argue that for most of us, particularly those involved in the software development and IT industry, online documentation is the way to go. If the organisation currently does not offer online documentation, then it's up to us to recommend moving online.
Online documentation is a powerful tool for engaging customers and readers, and for giving them the tools to help each other. Not only does this draw customers to the company, it also reduces support costs.
-
Permalink Reply by Shweta Hardikar on -
Hi Ute, we all face this problem sometime in our career where the team/project that we are asked to work with is skeptical about our need. The current project that I work with belonged to the same category. However, once they see our work, they always keep coming back.
Let me highlight few advantages that you may highlight to the team/project managers are:
- User perspective is most important and since we are “outsiders”, we have the user perspective. Convince the Manager that since you are probably at the same level as the end-users are, you are likely to explore the application in a different manner than the engineer/developer who has been forced to develop and write manuals about his work.
- Our best selling points are our command over language and the ability to modify language as per the end-users. Understanding the kind of audience we are writing for, we can also decide the best ways to communicate. For example, we can help the project manager decide the kind of documents that can be delivered to end-users. Not every time a hard-bound manual is required. We can give the options of videos, screen casts, tutorials, quick reference guides, and so on.
- We are communicators. We can interact with the subject matter experts in a better manner and extract information better. Our language skills also ensure that the user interface is reviewed, clean, consistent terminology is used and so on. After one high-level user interface review that I performed, I was appreciated more and was asked to formally review all error, warning and informative messages that appear on the UI. This was certainly a value-add that the managers never expected before.
- We can deliver more than expected. Along with preparing the manuals, I was in some ways, testing the application itself. I could point out the basic usability issues or usage related issues close to what an end-user might encounter. This helped a lot.
- Show the difference. Nothing impresses people than a smart looking and user-focused rich user guide. Apart from end-user documentation, we may also be able to create marketing collaterals for them. We are that versatile.
Apart from the actual experiences, (which I hope are not too long J) long time back I had read a blog post by Ben Minson that might also help you justify the need for companies to invest in a Technical Communicator.
Sharing the link -
http://www.gryphonmountain.net/2008/03/seven-reasons-your-company-n...
Also see,
http://www.gryphonmountain.net/2008/09/four-more-reasons-your-compa...
Hope this helps!
© 2012 Created by Arnold Burian.
