- Image by Arenamontanus via Flickr
Non-scientific observation: many technical communicators think their microcosm is global. If only the rest of the world would just learn to do things their way there would be candy puppies for everyone. Over the years I've read article after article defining what technical writing is and what it should be. If there was really a hard and fast definition of technical communication, there would be no debate, just a formula.
However, I think the world has moved on past what is considered traditional technical communication. Or at least things have changed enough because of social networking and advanced Web technologies that technical communication is at a critical change-or-die moment. By this I mean the people who own the creation, collection, and distribution of content may not be the same people in the very near future.
I've always defined technical writing as this: the process of taking complicated, scientific, or technical information and presenting it for a specific audience. I wrote that definition in college and still stand by it, fifteen years later.
I also believe technical communication is part of information architecture and user experience design. While the technical communication community, specifically many STC members, also work in usability or information design, the culture of the user has changed faster than the culture within the tech comm community. Web designers have been fast and flexible in accommodating users and are now also becoming the default content strategists.
Information is Not Chaos
I've heard the future of information described as chaos. Calling information chaotic and complaining how users still need "the manual" has been a way for technical communicators to avoid adapting to the realities of the savvy Web user. Chaos is in the eye of the beholder. I would argue information cannot be chaotic by the very nature of interpersonal communication and rules of language. If you dig deeply enough, you will find order in every seeming pile of chaos. For example, Twitter seems like a mecca for chaos, but it's not. There are rules: 140 character limits, each tweet must come from a registered user, every tweet goes into a searchable database, etc. Twitter opened the doors and asked for people to come and post. In the meantime, users have naturally added their own metadata (hashtags) and have learned how to make it meaningful for them with relatively unsophisticated tools.
The success of Twitter and FaceBook alone are enough to make anyone who writes content re-evaluate how information is delivered to their users. I'm not saying all content is appropriate for social networks, but I am saying that patterns in user behavior send signals technical communicators should pay attention to.
The Content Creator Approach
Traditional technical communication has made the technical communicator the center of the solar system. Ever since I started in this business, I've been fascinated with single sourcing, the process of taking multiple sources and pooling them together so you can create multiple output types. The first time I heard the term was in Oklahoma City at a regional STC conference in the mid-90s; someone from Doc-To-Help presented on the shiny new concept of single sourcing and I also became an InfoAccess HTML Transit beta tester (I still have the floppies!).
(Holy Crap!) Vintage Single Sourcing Workflow I made in 1999 for my boss
Single-sourcing is a concept created completely around the content creator, whose position is the center of an information hub. At the risk of being burned at the stake, I think the Earth actually revolves around the sun. While these approaches are about making the job easier, more efficient, and more automated, I'm afraid the user has been left from the equation. A lot of technical communication concepts are that way. Darwin Information Typing Architecture (DITA) is another example. I've yet to see a DITA presentation where the presenter didn't claim it was the future of all technical documentation. You'd think the "D" in DITA was for deity.
The User Experience Approach
A user-centered approach to technical communication requires your starting point begin with the users themselves. How do they want to receive information? How are they actually reading information? How specifically are they using your information? JoAnn Hackos' seminal work, Managing Your Documentation Projects, was instrumental in helping me build an understanding of audience analysis. But I would argue that today's technical communication culture is not obsessed with users/audience. It hasn't been for a while. I firmly believe this to be one of the many reasons STC is feeling pain right now. STC sets the cultural tone for the technical communication industry and users have with information technology. Through their actions, users have been telling us they like finding things quickly via Google.com or Amazon.com and they like social networking. Our community should pay attention and follow them.
In addition to focusing on users, having cultural awareness of other industries and working with people who represent them is part of product development overall. This in itself can be a lofty topic, but it's important to point out because positive user experience (UX) should be the goal of any product or service. Technical communicators are part of a team creating the UX. They are not stand-alone product creators; they work for companies producing products. Technical communication is not about the lone writer mentality anymore. As a community, technical communicators need to add to the UX conversation so they know where to swim in this workflow, for example.
- Image by Paul Veugen via Flickr
I personally believe you can argue the merits of DITA or single sourcing all day long, but the dirty little secret of our industry is simply that users don't care. They just don't care. They do know what they want information for and will consume the information in ways that are comfortable or familiar to them. I'm not saying DITA is a bad thing; I'm saying users are the first consideration and the process works backwards from there.
Information Types
User needs and usage actually help us define types of content and how we create it. This can be directly opposed or complimentary to our own needs for process or expediency. Information types can range from casual to controlled, again dictated by the users. Casual information is the most informal. Controlled is the most structured. Then there are many flavors between. On the casual side of things, there's not a lot of structure. Think of casual information as blog postings with tags, release notes, or a larger works without metadata. Casual information is consumed by users who need to know how to a do a job, but these jobs do not involve physical safety, legal requirements, or even standards compliance.
Controlled information must comply with a series of standards that are absolute. From the content creator's perspective, the standards are imposed by the user. For example, engineering drawings may need parts in diagrams tied to the part numbers in a logistics system. This is a user requirement, even if it's imposed by the company because it's necessary for the delivery of a positive user experience. Controlled information requires metadata and the development process is extended depending on the granularity of your control.
The Modern Technical Communication Environment
If I had a dollar for every time I've heard "nobody reads the documentation anyway", I would have had this article written by Zombie Hemingway. Instead those dangerous words have made it into corporate culture and people actually believe it. So technical communication exists in many places for its own sake. In order for technical communication to contribute to the user experience, the environment must be conducive. The ground rules for this environment are:
- Technical communication is part of a team working together to produce a product or service
- The afore mentioned team understands each other's part contributes to the overall user experience
- A positive user experience is the goal
- Users read documentation and want information especially for products or services they've paid for
- Individual users consume information in many different ways, but that should be addressed in the overall user experience
- Users don't know who created what within your organization; they only know your brand and their own user experience
Finally With the Sheep Metaphor
Content is Sheep as imagined by Cecily Anderson
Think of sheep in a field. The sheep are as controlled as you need them to be. You can let them wander for miles and you can round them up when you want. If you need to control them tightly, you can tag their ears and track each sheep individually.
It's hard work watching the sheep all by yourself, so you get some herding dogs. The dogs have to learn your boundaries and will keep the sheep together based on your training and your commands. Think of the herding dog as the automation you use to track content. It can be a content management system, for example. You need the automation to enforce the rules defined by you.
The point of the sheep metaphor is to communicate content can be controlled and you can exercise control depending on your situation. But the overall user experience is bigger and relies on your judgment and shepherding skills to help make metaphorical wool coats and socks.
So There
After watching the STC's slow motion Chevy Chase-esque prat fall for a few weeks I've come to the conclusion that there are technical communicators who get the UX movement and there are technical communicators worried about keeping things exactly like they were in 1995. Obviously I'm in the first camp. I actually started this article months ago as a simple metaphor exercise and grew into a general technical communication article because the STC has unknowingly asked us all how relevant technical communication is.
So how relevant are we? STC hasn't been the architect of any of the major movements in user information technology. DITA is a good example of something that happened outside of the STC. I saw today that STC is dropping W3C membership to save money. If STC doesn't participate in the conversations related to the future of technical communication, who will?
I recommend technical communicators begin to rethink their relevancy to their organizations and how they can retool themselves to contribute to the user experience. I want everyone to rethink what technical communication actually is. I also want everyone to understand different types of information and apply standards to their work set forth by their own users. Is this too much to ask? Whether or not STC survives, the work must be done.
--
Thanks to Chris Hester for helping me pull my thoughts together.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=fac20cb6-5d9e-4f5a-8841-744ae0950319)
Popularity: 3% [?]
Wretched Human Mirror by Bloodbath
{ 3 trackbacks }
{ 8 comments… read them below or add one }
This is well written and thought out. The fallacy that no one reads the documentation is a poor excuse for not doing the job the right way. It is true that good usability means the documentation is less critical to a successful user experience. The successful experience should be the goal of all software, but seldom is. Twitter is excellent example of success in the face of chaos. People find a way to get it.
The best part is the use of Cecily's picture. We all are sheep, hoping for a good Shepherd to watch over us.
I had a conversation with a colleague last week that echoed some of the points you make about DITA and the lack of impact it seems to make on a user. Although the DITA structure is an advancement in technical writing methodology, to the user, it still looks like the same old manual. I agree that it doesn't seem like a user-centered advancement.
On the other hand, DITA has given us the ability to produce more deliverables that are more role-based and customized to the user, in a shorter amount of time, without copying and pasting. So there's an argument there as well.
Thanks for the engaging post.
My thoughts echo those of Tom Johnson's. There's this "technical writer as artisan" v." technical writer as factory worker" debate implicit in this. The missing piece in DITA is the publishing – everything else is under the hood – making writers more efficient, more systematic.
However, the publishing aspect is likely to arrive. It's like the car industry – you need modular components in order to be able to create 30 odd variations from the same platform (VW Golf, Audi TT, VW Jetta, Skoda Octavia,Audi A3, Golf convertible etc ) .
I agree with many of the points in this article. I evaluated DITA for our docs about a year ago, and ended up with some other misgivings not mentioned above:
-It seemed to require me to rewrite some topics and present some information in a way that was not in the best interest in my users. (Maybe this fits into the "controlled" point you made above.)
-When I read a book that was put together in DITA, I noticed a disconnectedness between topics that were supposed to be sequential. Coding examples didn't show progression from one graphic to the next – previous steps were omitted. This was confusing.
However, I have to say that when you look at what your users want, not every audience is yet ready to embrace social networking as the way to receive information. Our audience includes users with a pretty wide spectrum of computer and internet skills, and some have told us they still prefer manuals. (We don't print manuals, but we do provide PDFs.) We are focusing more attention on the Web-based delivery methods that have more long-term promise, but we don't want to leave part of our audience behind.
Thanks for the food for thought. I think it's important to constantly gauge how your audience is changing and how they prefer to receive information.
For me it's not about artisan versus factory worker. Some tech writers are creatives and some are not. It depends on the job. It's about an entire industry remaining relevant.
I only used DITA and social media as examples of trends. The user experience is not about jumping on bandwagons, but it is about watching what users are doing in the real world and making their experience with our products as positive as possible.
Agreed, DITA is not where it should be from a user's perspective, but is coming along as a good structured standard. I only used it as an example of a process that left out user experience and also as an emerging standard the STC organization ignored. In retrospect, my article covered a lot of topics because I keep seeing them overlapping when I write about them. You have the STC culture, the traditional technical communication culture, and the user experience culture. Technical communication as we know it today will either evolve to compliment new technologies and user expectations, or somebody else is going to come along and take ownership of future technical content.
Although some may try to convince us otherwise, I don't believe that DITA will ever be a one-size-fits-all solution. I also do not believe that it is designed to produce the ultimate user experience. Where I believe that it will eventually succeed is in highly regulated industries where content must be ultra-precise and consistent–industries where, in some cases, accuracy of content can literally make a difference between life and death. There will always be a need for this type of content. Whether the content is engaging is a secondary consideration.
The interactive software market is where DITA's success is questionable. Designing user assistance for more creative types of software is simply not a one-size-fits-all scenario.