A Collaborative Writing Model for the Social Web

 

In my last post How to Deploy Social Media ~ a Call to Arms, I promised to explore the activities and social media tools that as a technical communicator, I can use at each stage of the product development life cycle to collaborate with members of my user community, as we develop audience-centered content for the social web.

The stages that I am using as a writing framework are “awareness, attention, engagement, execution, and extension” (as described in Chris Brogan’s post: Pirate Moves-From Awareness to Extended Action.)  I am also using as a model the five stages that apply to almost all software usage:  unaware, interested, first-time use, regular use, and passionate use”(see Joshua Porter’s Designing for the Social Web: The Usage Lifecycle).

Both Brogan’s “continuum” of relationship-building stages” and Porter’s “Usage Life-Cycle” mirror the five traditional stages of the writing process: prewriting, drafting, revising, editing, and submitting. In the sections that follow, I interweave these related processes, providing specific examples of how I would use social media tools for collaboration, at each stage of the life-cycle. I also incorporate examples of how Charlene Li and Josh Bernoff used social media tools in their collaborative writing process, drafting the BusinessWeek Bestseller, Groundswell.

Awareness

According to Brogan, “If you’re selling the coolest software [or Peg’s note: software documentation] in the world, but no one knows that, how are you going to sell it? [or Peg’s note: get someone to follow your instructions?] What comes first is awareness.”  For Porter, this is the Unaware stage in the usage life-cycle: “This isn’t so much a stage as it is a starting point.”

Here are some ways technical communicators can use social media tools to increase awareness of their documentation initiatives and to encourage collaboration with their primary and secondary audiences:

  • In addition to traditional Release Notes (the documentation users are most likely to refer to), use podcast or video to highlight information about new features, guidelines for use, inter-operability issues, operational notes and restrictions, and software problem reports.
  • Use podcast or video to supplement the How-To Use this Doc Set (a guide that often accompanies lengthier doc sets).
  • Use a blog or forum to make users aware of legacy docs and to solicit feedback for improvements, recommendations on how to organize the doc set, and input on the preferred medium for delivering online help.
  • Use a combination of social media tools (including the blog, wiki, forum, mini social network, and twitter) to complete an audience analysis & gain more detailed understanding of primary and secondary audiences, as well as the purpose of all content deliverables.
  •  Distribute a documentation plan, via a wiki, so community members can anticipate exactly what deliverables you plan on providing content for and can provide input on what types of content they would most prefer.
  • Welcome community members and ask for their help collaborating on content, by revising content via the wiki, adding new content, and helping to edit content.
  • Use Twitter to announce when you’ve posted any new content, podcasts, or video to your blog, forum, doc wiki, or company website.

Attention

Brogan describes the Attention stage as “a bit more than awareness. It means that people are giving you a little bit more of their time. They expect something back for this, be that entertainment, or a perception of value, or a sense of participation.” Porter describes this usage stage as ‘Interested: These people are interested in your product, but are not yet users. They have lots of questions about how it works and what value it provides.”

Here are some ways technical communicators can use social media tool to increase attention and participation from their content collaborators:

  • Post early outlines of the content and solicit feedback on the doc blog, wiki, and user forum.
  • Include “talk pages” parallel to each wiki page, where contributors discuss (and sometimes fight over) what ought to be included (Groundswell, p. 25).
  • Ask users for real-world examples or scenarios that they want the doc to help them solve.
  • Share any bookmarks, related to background research on the technology or product you are documenting, through social bookmarking sites. Authors Charlene Li and Josh Bernoff, of Groundswell, used social bookmarking in this manner to share links about their research and book on Del.icio.us. [del.icio.us/the groundswell].
  • Ask your community members (reviewers and co-authors in the next two stages) to share their technology and product-related bookmarks, allowing them to become collaborators with the technical communicator, not just in the writing, but also in the research stage, of the writing process.

Engagement

Engagement, to Brogan, is ‘the sustained interaction between you (or your product or brand or service) and your buyer [again for the technical communicator, the doc user]. Use tools to maintain two-way interactions. Look for ways to engage in a participatory way.’ For Porter, ‘First-Time Use’ involves “people using your software for the first time, a crucial moment in their progression.”

Here are some ways technical communicators can “capture, maintain, and manage collective knowledge” (Technical Communication in a Social Media World) and use social media tools to further engage their content collaborators:

  • Post complete drafts to the wiki and solicit comments.
  • Use discussion boards, based on primary & secondary audiences, as a way to discuss topic threads in greater detail. For example:  Intuit’s quickbookgroup.com forum for small business owners, using its QuickBooks product (Groundswell, p. 26).
    As Li and Bernoff suggest, provide users a place to provide tips, similar to www.ebaywiki.com. (Groundswell, p. 26).
    Collaborate with users to develop a glossary, for example: glossary.reuters.com (Groundswell, p. 26).

Execution

In the Execution stage, Brogan states “we’re talking about the actual event, or the purchase, or the delivery of information.” Porter describes this stage as “Regular Use”: “These people are those who use your software regularly and perhaps pay for the privilege.”

Here are some ways that technical communicators can use social media tools to execute their content delivery:

  • Incorporate all review comments from the community and post a completed draft to the doc wiki.
  • Transition into a more moderator-like role, facilitating as community members rewrite the content and directing members to appropriate content.
  • Organize content on the social web through tagging, enabling others to more easily locate the documentation. For example, when creating Groundswell, Li & Bernoff organized the web using delicious “to create a set of tags for each chapter, neatly organizing Web sites and articles we’d found.” [del.icio.us/the groundswell].
  • Use RSS and widgets to inform your community members of significant updates to the audience-centered content. According to Li and Bernoff, RSS and widgets “give people the ability to consume and process more social content” (Groundswell ,p. 32).

Extension

Chris Brogan describes Extension as “a way of moving from what happened to what happens next” and “the feeling that your buyer was part of something.” Porter calls this stage Passionate Use:  “These people are the ultimate goal: passionate users who spread their passion and build a community around your software.”

Here are some ways that technical communicators can use social media tools to extend their community-building efforts and to make an impact, not just on the next iteration of the content, but on improving the product:

  • Continue to revise and fine-tune the content, acting in a more editorial role.
  • Continue to use the blog, user forums, and doc wiki, as a place to receive documentation feed-back.
  • Actively solicit customer feedback through surveys and follow-up calls.
  • Complete usability tests of the doc with members of the community, showing the live testing process through podcasts, to heighten a sense of participation and investment in the product.
  • Report back to Product Management what documentation topics are most active on the social web and consider those as likely places to review, improve, or add-on to the product’s functionality.

Summary

In summary, the life-cycle approach for designing audience-centered content for the social web could work this way for technical communicators (or any collaborative writer):

  • During the Attention and Interest stages, convince community members to locate, follow, and contribute to the user instructions.
  • During the Engagement stage,”capture, maintain, and manage collective knowledge,”  enabling the community to rewrite the content later (see Technical Communication in a Social Media World).
  • During the Extension stage, reinforce passionate usage of both the content and more importantly, the product.
  • Though I propose these examples from the perspective of a technical communicator, the same life-cycle approach applies to most other software development disciplines and is the best framework for deploying social media in the large enterprise.

What are your thoughts on the collaborative activities that I propose for technical communicators, at each stage of the usage life-cycle? If you represent a different discipline, what social media tools would you use at each stage, as relates to your different goals? Would this collaborative writing approach still apply in agile development settings, where both the product and documentation are delivered by module, in short, iterative cycles?

Analyzing Audience Without Direct Access to Customers

Summary: Provides tips on how to analyze audience for user assistance, without direct access to customers. Asks how the advent of Web 2.0, related social media tools, and user-generated content, can help technical communicators have more direct contact, and beyond that, collaboration, with our primary and secondary audiences.

As a technical communicator, I do not often have direct access to my audience. Without a clear understanding of my audience, it’s more difficult to define the purpose of my deliverables, gauge the correct content level, and the best organizational strategy. If this is the case for you, here are some suggested ways to learn more about your audience:

  • Working closely with the Product Manager, who often includes a definition of the product’s intended users in the product requirements.
  • Asking the Product Manager about any anticipated documentation requirements, early on.
  • Speaking with Marketing about customer demographics, segmentation attributes, expertise level, etc.
  • Working closely with QA during the product’s development. As internal users, QA is the best initial customer surrogate and can help you anticipate your audience’s user assistance needs.
  • Working closely with Technical Support representatives, who have first-hand knowledge of the customer’s frequently asked questions and troubleshooting issues.
  • Include Sales Engineers and other Product Implementation Engineers in the review process, as they too, have first-hand knowledge of the customer, and are often champions for the technical documentation.
  • After the documentation is released, directly calling your customers, asking for feedback on the documentation, or using a questionnairre to gain user feedback.
  • Including an e-mail address in the documentation, so customers have a way to provide direct feedback to the documentation team.

What other ways do technical communicators traditionally learn more about the intended audiences for our documentation deliverables? What obstacles do we sometimes face gathering this type of information? Do you see the advent of Web 2.0, related social media tools, and user-generated content, as a way for technical communicators to finally have more direct contact, and beyond that, collaboration, with our primary and secondary audiences? Photo Credit, Intersection Consulting.

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

Understanding Audience and Purpose

Understanding the audience and purpose for your technical documentation is the single most important, and often, most neglected step in the writing process. It doesn’t matter how well written, organized, accurate, or complete a document (print or on-line) is. If your instructions do not meet the needs of your intended primary and secondary audiences, your documentation is useless.

  • Primary audiences most often include naive, new, advanced, and expert users–all of whom have very different requirements.
  • Hidden secondary audiences may include sales, marketing, or financial professionals, who often use the technical documentation to highlight how the product works to potential clients, understand the functionality themselves, or to sometimes even make decisions, related to buying products.

Other important secondary audiences might include the trainer at your customer’s company, who uses the instructions to create company-specific training, or customized documentation for their own employees. In other situations, your own colleagues may be an important secondary audience, as the technical documentation is often referred to by internal users.

Given the importance of correctly analyzing the audience and purpose for my documentation deliverables, I have always found the following criteria from the Society for Technical Communication to be a very simple, but effective way to begin:

  • Is the purpose clearly stated?
  • Does the document fulfill the purpose?
  • Is the audience clearly defined?
  • Does the document meet the audience’s needs?

Another very simple way to start thinking about your audience is suggested in Audience Analysis The Easy Way:

What does the audience know about the thing I am writing about?

  • “Basically, you can assume that some of your users are supreme experts in the technology, some of them are complete greenhorns, and everyone else falls somewhere in between. The trick is to write for the greenhorn without offending the expert.”
  • What does the user want to know about the thing I am writing about?
    Most users want to know “what the product does, how to install it, how to configure it, how to use it, how to respond to alarms and notifications, and how to maintain it”.

Clearly identifying and understanding the mixed nature of your audience (novice through expert) and their multiple purposes (understanding, installing, configuring, using, responding to alarms & notifications, and maintaining the product), as early as possible in the writing process, can help save you countless hours of rework later in the development cycle.

In your own documentation deliverables, what do you see as the main trick of satisfying the novice, without offending the expert? What secondary audiences do you most often encounter? How important are these secondary audiences in shaping your content and organizational decisions?

For helpful tips on getting started, check out the steps here: Conducting an Audience Analysis. For more detailed information on audience analysis, these articles are also helpful: Online Technical Writing: Audience AnalysisTechnical Writing Audience, and Designing for the Social Web: The Usage Lifecycle.

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog