|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2013 --> Defining content
Vous êtes ici : Essais --> 2013 --> Defining content
By Geoff Hart
Previously published as: Hart, G. 2013. Defining content: going beyond the explicit to find the implicit information. Intercom May:26–30.
There’s a lot of buzz these days about content and content management, but nobody seems quite sure what that content is and how it should be managed. That’s partially because the field of content management is still young and evolving rapidly, but it’s also because so many things fall under the umbrella of “content”. At one extreme, content includes large-scale artifacts such as end-user documentation for your products, marketing materials, documentation to support certification processes such as those specified by ISO 9000, legal documents (e.g., Sarbanes-Oxley), and policies and procedures manuals intended purely for your own employees. At the other extreme, it includes small-scale artifacts such as e-mail addresses for key clients (which may exist on a single employee’s computer rather than in a central repository), a copy of a PDF file from a crucial client (which may only exist “in the cloud”, in an employee’s Apple iCloud or Microsoft SkyDrive account), and even the automatic text entries stored in Microsoft Word’s document templates and .ACL files. Although many types of information belong in this category, it represents the easy part: this information is all explicit and easy to identify, though it may take persistence and a rigorous strategy to find it all.
Content also includes intangibles, such as the information about what you do and why you do it. That’s the hard part. Most often, this exists only in the heads of your employees, and is passed on orally from managers and senior staff to new hires. This information has often been acquired over years and sometimes even decades of experience working for your company and with your clients, and is often responsible for much of your profits and most of your efficiencies. (It can also be responsible for severe inefficiencies, as I’ll discuss towards the end of this article.) Identifying and finding ways to record this information is referred to as knowledge management. Business-process knowledge is a crucial and often neglected aspect of content: it may never appear explicitly in documentation and other content, but it forms the invisible backbone and backstory (the context) in which all other content exists. This is why you have policies and procedures: they (nominally) represent the implementation of proven strategies and tactics that define how to act on a large body of implicit knowledge.
Rather than trying to create a narrow, exclusive definition of content, it’s better to think of content in more general, inclusive terms. From the perspective of technical communication, I like to think of content as the knowledge that your organization requires to accomplish any of the following:
It’s no coincidence that these categories, enacted in roughly that order, recapitulate the product development life-cycle that most companies follow to a greater or lesser extent while they develop their products. This is true whether those products are concrete items ranging from bulldozers to books, or intangibles ranging from brands to best practices. In the rest of this article, I’ll discuss each of these aspects of content. Note that depending on your specific work context, not all of these categories of knowledge will be relevant. Nonetheless, understanding why they might be relevant in other contexts will often provide useful insights into your own work. At the end of this article, I’ve provided a list of useful references to help you start exploring some of the topics I’ve discussed.
Understanding your audience begins with a process referred to as audience analysis. This subject is too broad to encapsulate within a single short article, so instead I’ll summarize the key points and provide references to my past articles on this subject. At its most basic level, audience analysis starts with learning the identities of the people who will use your product or its documentation: who are they? Once you know the who, the next question focuses on the what: what are their needs and how do they meet those needs? Armed with that knowledge, you can identify groups with different sets of needs and begin looking for solutions to meet those needs. For example, if you live in the U.S., you may need to comply with the provisions of the Americans with Disabilities Act, and specifically with Section 508 of the Rehabilitation Act, which is designed to ensure accessibility to information technology.
Branding, which represents the overall perception of your line of work and your products, is a neglected aspect of audience analysis. Consider, for example, the difference in public perception of Apple products (elegant design, simple and easy to use, overpriced) and Microsoft products (complex, virus-prone, often inelegant, economical). Those stereotypes are clearly simplistic and thus, inaccurate, but they shape how audiences think about your product and how you may need to shift those perceptions. A related issue faced by both Apple and Microsoft is the (correct) impression that computers are difficult to use and therefore somewhat intimidating. Solving that problem is a challenge that many technical communicators face.
Although this audience knowledge may never appear explicitly in your product or documentation, other than perhaps in the form of separate manuals for technology managers and technology users or for experts and neophytes, that knowledge shapes all the content you create, and is therefore a crucial component of your content: it defines the goals your products must help your audience to achieve.
About a decade ago, while I was traveling in China with a delegation that was invited to discuss technical communication with people in academia and in high-tech industries, we ran into a stumbling block: many of our hosts couldn’t understand the difference between technical communication and marketing. The explanation I finally came up with that successfully communicated the difference was the following: Marketing is how we persuade someone that our product will meet their needs, whereas technical communication is how we teach them to meet their needs using our product—and incidentally, how we try to ensure that they don’t get fed up and return our product for a refund.
Marketing builds on a key aspect of audience analysis: understanding our audience’s needs and how our product could meet their needs. Effective marketing seeks ways to persuade people that we can really meet their needs. This requires an understanding of your company’s brand and of the context in which your company produces products, both of which strongly affect how people think about your product. In some cases, your marketing must strive to change those perceptions. For example, computers intimidate most of their users—an inconvenient fact that most technical communicators forget because most of us are comfortable and proficient with the technology, and because most of us work with experts who lie at the high end of the expertise curve. Understanding the strength of the intimidation factor for people who are less confident or competent lets us directly address those concerns: marketing eases the fear, then we try to live up to the marketing hype (a subject I’ll discuss in the rest of this article).
Marketing was traditionally seen as one-way communication: we delivered persuasive arguments, and the only way we knew what our audience thought about that message was indirectly, in the resulting sales. But marketing increasingly seeks to build partnerships with our audience. As I’ll discuss in subsequent sections, working together with our audience to meet their needs (i.e., listening to their concerns and trying to account for them in our product and documentation development) is more effective. First, it eliminates the widespread perception that the only goal of marketing is to sell a product. Second, it provides important feedback about how to make our products better, and thus easier to sell. Third, and possibly most important, it replaces a soul-less commercial transaction with a relationship that lasts long after the sale is history. To learn more about technical communication marketing, visit STC’s Marketing Communication community.
The relationship between marketing and content may not be immediately obvious, but a little thought reveals how this might work. First, audience information defines the content implications discussed in the previous section. Second, it reveals entirely new forms of content we should develop. For example, relationships are sustained by dialogue, and dialogue requires content in the various forms of social media I’ll discuss later in this article.
Understanding audience needs is the first step in finding ways to meet their needs. It seems redundant to say so, but you can’t meet a need that you don’t know exists. Iterative design, in which each new design is tested with your audience to see how well it works and identify omissions or failed designs, is how this is done. The approach pioneered by Alan Cooper and his colleagues is a highly collaborative form of design, explained eloquently and at great length in books by Alan Cooper and Kim Goodwin. Both approaches work best through a relationship that provides opportunities for testing of a design—indeed, the Cooper process cannot work without the relationship—and the relationship strengthens as the audience learns that we really do want to help them. Related fields include user-centered design, user experience design, and usability testing, all of which are the focus of STC’s Usability and User Experience community.
Product development therefore includes unsuspected sources of content. First, content is implicit in the details of the relationships you’ve established and of the strategies that resulted in both failed and successful designs. Second, descriptions of both effective and ineffective types of testing become important parts of your organization’s formal policies and procedures. Third, content may be forgotten when it is transformed from explicit forms such as printed manuals and online help into implicit forms such as embedded help that becomes part of the workflow and interface and that disappears from the explicit documentation. This leads us to the next point.
When you think of documentation, the odds are good you picture traditional forms such as printed manuals, online help, and Web sites. Content originates during the development of this information: writing, editing, product and documentation maintenance, and product and documentation revision. If you’ve engaged in single-sourcing, content management is integral to your actions. However, all of these steps conceal an important type of content: an understanding of the thought processes that guide the processes with the goal of letting someone learn how to use your product correctly and efficiently. After reading the previous section, you’ll understand that embedded help is one such form of content. These include implicit forms of content such as the strategies used in flexible or fluid design (i.e., to let a Web page reflow to fit both a 21-inch desktop monitor and a 5-inch smartphone screen), and software-based assistance such as Microsoft’s wizards and how the help system in Macintosh OS X highlights components of the interface to show users where settings and tools can be found.
The relationships with your audience that I discussed in previous sections provide an opportunity to create feedback mechanisms by which your audience reveals their needs and how you’re failing to meet those needs. For example, a neglected content area involves the online discussion forums that most software and many hardware companies now implement. The problems people experience and the solutions that experts provide are critical for improving your products and documentation, yet are rarely used in this manner. Few companies recognize the value of this resource and allocate sufficient human resources to managing it. Additional strategically important content involves an understanding of how the needs of your audience are evolving, and how both your product and your documentation must evolve to meet those new needs. Online forums are just one form of social media, a topic too large to address in this article; I’ve provided links to two of my articles that provide more detailed descriptions of these options.
In some cases, content is external to your organization. Industry magazines (e.g., PC Magazine, MacWorld) are excellent examples, since these magazines stay in business by understanding the needs of their readers and providing content that meets those needs (i.e., by performing ongoing audience analysis). Newspapers and non-industry-specific magazines with subjects that relate to your field are also excellent sources of content, since they monitor new technologies and business needs, both of which affect your audience and therefore affect you. They also periodically misinterpret a product category badly enough to create misunderstandings and false expectations you must solve through marketing or documentation.
One of my favorite catchphrases about the modern era is the seemingly oxymoronic phrase “the constancy of change”. Never before have the technologies and cultural institutions that support society changed as fast as they’re changing now. Thus, your strategy for monitoring and responding to these changes is an important form of content (as I noted earlier). Any content you create now is only an interim solution: as business contexts and audience needs change, content must change to reflect the new reality. This means you’ll need to carefully monitor your context and audience, and as both change, to review both your content and your processes for producing, maintaining, and updating that content. I’ve provided two articles on process improvement that discuss one powerful way to perform this review.
As I hope I’ve demonstrated, a surprising amount of content is implicit and hard to pin down. Information about what you do can be determined by watching people carefully using the formal and semi-formal techniques of ethnographic or contextual inquiry or more simply, by careful observation. But understanding why someone acts in a specific way is less obvious. Most often, this exists only in the heads of your employees, and when asked why, they may have difficulty explaining the reason. Often this is because the method was passed on orally from managers to employees, without any explanation beyond “this is how we do it”. Then, it may be necessary to think deeply about the process and ask: “What conditions must exist for this approach to be sensible?” Understanding those conditions often reveals the why, and once you know the why, you can record it. Note that the “why” can include knowledge of both facts and ways of thinking, and each can be important in different contexts. Next, ask yourself whether those conditions still apply. If they don’t, it may be time to change the process to reflect current conditions.
Even when conditions haven’t changed, inefficient or illogical processes may need to change. When I worked for a branch of the Canadian Federal Government, I encountered the least rational and most inefficient paper-based filing system imaginable. When I needed to balance my annual budget, it could (I’m not exaggerating) take a day to track down the source of a suspicious debit and reconcile it with a corresponding entry in my budget printout. It turns out that during the 25 years my office had existed, three generations of bureaucrats had developed their own approaches to record-keeping; the result was a system in which any given invoice might have been stored in one of three separate ways, depending on which generation of bureaucrat had trained the clerk who filed it. Although it would have made sense to scrap the entire system and establish a single repository, this wasn’t done during my tenure because it was prohibitively time-consuming to refile 25 years of records using a new system, not to mention identifying where the older systems linked into unsuspected aspects of our daily operations and relinking those parts with the new system.
Implicit content must be protected against disaster every bit as much as explicit content. This involves far more than just onsite and offsite backups, which should be (but often are not) a given. Planning for disaster recovery also involves identifying key resources such as people who cannot be easily replaced if they leave suddenly, and finding ways to protect their implicit knowledge.
Content is both the information we produce and the audience characteristics, organizational context, and thought processes that shape that information and how we produce and update it. The modern era is referred to as “the knowledge economy”, and content is the fuel that powers that economy’s engines. A good way to begin thinking about your organization’s content would be to conduct a content audit. Econsultancy provides a useful summary of what’s involved in a content audit.
Audience analysis:
Design:
Knowledge management:
Process improvement:
Social media:
©2004–2024 Geoffrey Hart. All rights reserved.