Technical and Marketing Communication: Content for a Convergent World

Collaborative Writing

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?

 Photo credit, jayfreshuk

A Social Media Call to Arms

In his post “While Others Paint the Trim,” social media evangelist Chris Brogan sounds a call to arms, challenging all social media enthusiasts and practitioners to supply specifics on how to implement and inter-connect social media tools, especially in larger organizations. He also says that social media is much bigger than any one discipline in the enterprise:

[Social media] isn’t a PR tool; it’s not a marketing tool; it’s a communications tool and a media making/distribution tool set. And further, it’s not the only way to the finish line out there. It’s about working on the larger need and then using the tools judiciously.

He goes on to say that larger organizations are already sold on social media and are now looking for “actual strategies with definition and detail.” He adds:

They want a better understanding of how the tools go together and which ones will make the best impact for their business goals. They want a whole lot more than “you’ve gotta get on Twitter,” and they want it to demonstrate impact, but have a path for sustainability. They want it not to be an island, but to be tied logically back to the right parts of the business.

As a technical communicator, I summarize Brogan’s persuasive call-to-arms in my more matter-of-fact style: Large organizations want a process. They want to know how social media works, for each component discipline in the enterprise, from start to finish. Relating to the software development world that I am most familiar with, that means Sales, Public Relations, Marketing, Product Management, Development, Quality Assurance, IT, Technical Support, Technical Publications, Manufacturing, Operations, and gosh—I’m sure I’m forgetting someone—but that’s the idea.
  
A framework for deploying social media in the large organization is exactly what Chris Brogan provides in his next post, “Pirate Moves – From Awareness to Extended Action.” In his “continuum” of relationship-building stages, Brogan lists each part of the social media deployment process: awareness, attention, engagement, execution, and extension. He provides general examples of how to use social media tools at each stage, with the end goal of getting a “buyer” (a term he uses loosely to describe “the person you want to have take an action”) and your “would be product” (be that “an opinion, a service, or what have you.”)

Tonight, Brogan praised Keith Burtis’ post “Sharing a Social Media Story from the Arts,” which describes how Burtis used social media tools at each stage of the deployment continuum in his online woodworking business. In drawing our attention to Burtis’ post, I think Chris Brogan is challenging each of us, from our respective disciplines, to come up with a strategy (including activities for each stage of the continuum) for deploying social media in our organizations.

—That’s just what I’ll be doing, at least starting to do, in my next  post (see A Model for Collaborative Writing on the Social Web). I’ll be writing specific steps for deploying social media tools in the technical communication discipline. How about you?

Photo credit, dbking

Developing Audience-Centered Content

In the March 2009 Intercom issue (the magazine for the Society for Technical Communication), Rich Maggiani describes social media as “all about community by engaging people through interactions and conversations around a shared goal” (p. 20). He goes on to propose a new model for technical communication, known as– “social media technical communication” (p. 19, Technical Communication in a Social Media World).

Before describing this new model, Maggiani traces the traditional process for delivering technical documentation and other user assistance deliverables. This traditional process usually consists of interviewing, writing, and designing.

During this process, technical communicators do not usually directly speak to the client. Instead, technical communicators complete deliverables “based on information from the project manager and subject matter experts.”

From there, the project manager usually delivers “content to the client, fields comments from the project administrators, and reports these comments back” to technical communicators. Throughout the documentation’s development, technical communicators remain behind the “corporate veil”  (p. 19).

Through social media, technical communicators are moving from a standard one-to-many communication, to a many-to-many communication, where the content becomes a “collaborative effort, combining the knowledge of all participants” (p. 20). In this model, the technical communicator is no longer hidden behind the corporate veil. Instead, technical communicators are on the frontline, providing “content for collaboration, not just consumption”, as both the content expert and “the moderator for soliciting, interacting, and gathering comments and reactions from engaged users in short, fluid cycles (not disengaged, unknown users)” (p. 19).

Maggiano encourages technical communicators to start using social media tools to moderate these types of customer interactions:

• Blogs:  Creates an opportunity for all customers (internal and external) to comment on whatever is posted.
• Forums:  Can maintain a number of different threads on various topics, with the community able to quickly read past comments and post their thoughts.
• Wikis:  Provides technical communicators a place to to capture, maintain, and manage collective knowledge, while allowing the community to rewrite it.
• Mini Social Networks:  Captures “the essence of the community members and their backgrounds and expertise.”

As technical communicators, we are uniquely poised to expand our existing skill set, creating the initial content for collaboration (as we always do), and then “managing, collecting, evaluating, and including the most relevant comments and feedback” from our customers, on the variety of social media platforms we are moderating.

This process is really how we already incorporate comments and feedback from our internal content reviewers. With social media, the notable difference is we are using new tools (something technical communicators already know how to leverage quite effectively) and collaborating with our customers first-hand, rather than the customer surrogates and product specialists (product management, marketing, sales, engineering, quality assurance, and customer support) who technical communicators ordinarily rely on for the audience and product information we are already responsible for integrating.

Do you have any examples of successful social media technical communication? What other ways can we collaborate more closely with our intended customers or customer liaisons? What obstacles do you see?

Related Links

• The Impact of Social Media on Technical Communication — Podcast Interview with Bill Albing
• Anne Gentle Interview’s about Conversation and Community: The Social Web for Documentation

Photo Credit, toprankonlinemarketing

Who is my Customer?

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.
• Including 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

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, see the steps here: Conducting an Audience Analysis. For more detailed information on audience analysis, see these articles: Online Technical Writing: Audience Analysis, Technical Writing Audience, and Designing for the Social Web: The Usage Lifecycle.

Photo Credit, *L*u*z*a* return to nature

Working Together

Getting a steady stream of good information from your SMEs (Subject Matter Experts) is not a given. It’s something that occurs over a period of time and is based on a work relationship, built on the same ingredients as any other successful relationship: mutual respect, trust, and if you are lucky, as I have been on lots of occasions, comraderie & fun.

Most of my SMEs work very long hours, always under deadline, and always in crunch mode. Though as a technical communicator I often step up, crunching especially long and hard nearer to the product’s delivery, I think it’s only fair to state that our more technical colleagues, more often than not, are *always* in crunch mode. 

When I approach engineers or testers and ask them to review my work, I am respectful that reviewing the documentation often requires my SMEs to help me on their own time–either their own personal time, or work time, when they could be completing assigned deliverables. So, if I ask SMEs to help me in such a way, I better make sure that I’ve done as much legwork as I possibly can, on my own, to make the draft as reasonably complete as I can, and to help guide my reviewers to the places in the doc that I know are probably the weakiest. I also stagger my reviews in small increments and find out my reviewers’ commenting preferences (e-mail, hardcopy, PDF, etc.) In other words, I try to make the review as painless as possible, for the people who are helping me.

Building a successful work relationship with your SMEs also means convincing them that you are worth making the investment of their time, and that you will actually incorporate, or at the very least, strongly consider their feedback. Good technical writers want feedback. Good technical writers aren’t defensive about feedback and incorporate most of what they receive, perhaps not verbatim, and not always that release, but as much as possible. When reviewers come to trust that you will incorporate their technical feedback, and that you are willing to work as hard as they do, especially near the end of the cycle in crunch mode, then they are more willing to continue helping you.

Finally, people tend to help people, whom they like as much as respect. How do you be “likeable” in the work place?

• Showing an interest in your co-workers, not just at review time.
• Avoiding the blame game.
• Being pleasant.
• Helping out your reviewers when the occasion arises (offering to proofread their documents, helping them with Word questions, pitching in on formatting tasks that may take you no time, but them a lot of time, pitching in on ad hoc assignments that often come up, from the other disciplines).
• Hanging out once in awhile (lunch, holiday parties, at the gym).
• Showing reviewers that you incorporated their comments, so they see the difference their comments made.
• Keeping a list (in a centralized place) of comments that you did not incorporate, either because of time constraints, or the need for further discussion. (Don’t let your reviewers feel like they have been unheard, or that their review efforts were wasted.)
• Saying thank you, both personally, and in public.

A lot of these suggestions may seem like common sense, but relationship-building is one of the most important, and I think, often overlooked parts, of successful technical communication.

Do you agree? How do you build rapport with your SMEs?

Photo Credit, bikamoo

New Releases

Gathering information for a new product’s documentation requires even greater resourcefulness, research, and communication skills, than gathering information for a maintenance release. The challenge with a first release, is not only is there no existing UI to help you understand the functionality, but there is also no legacy documentation to use as a building block. In shops that follow the agile methodology, there are also often no specifications to follow. So, how does a technical communicator get information about a product that doesn’t even exist yet?  

These are the methods I have used to gather information for new product releases:

• Reviewing the competitor’s documentation (if available) to consider organizational issues and evaluate an approach to similar content.
• Researching, as much as possible, any technologies new to me, via the web especially, by interviewing my internal subject matter experts, and using any additional company resources (for example, marketing data sheets, knowledge bases, and webinars).
• Particpating in any use case or UI prototype reviews to understand functionality and to help me start building an outline for each deliverable, based on the implied tasks.
• Using a combination of the following methods to create placeholder headings in the new user documentation: emerging product requirements, technical specifications, interviews, any early prototypes of the UI, any available demos, or early builds. 
• Using various iterations of the product hands on, as those builds become available to me, to complete the documentation’s content.
• Interviewing Subject Matter Experts (primarily engineers).
• Staying especially in the loop with QA engineers, who provide valuable input on ”rough” functionality and bugs, that are going to require the most detailed documentation.   
• Using a combination of reviews, edits, and sign-off/s to further refine the information. 
• Ensuring mechanisms to provide additional internal and external feedback on the documentation.

How do these methods compare to your approach for gathering information during new product releases? How much of your success implementing these methods, depends on your ability to successfully build and maintain relationships with other members of your project team? For me, relationship-building is so integral to a technical communicator’s sucess, on either a maintenance or new release, that it requires a post of its own.

Photo Credit, Parksy1964

Maintenance Releases

As long as I have been writing technical documentation, the most common question interviewers ask me is how do I go about getting information for my documentation deliverables.

For me, there really isn’t one answer or method for obtaining information. Much of my information gathering is determined by the availability of the actual product (or legacy products), the organization’s level of process maturity, the availability of reviewers, the corporate culture, and my own initiative as a researcher, questioner, and organizer.  

In the list below, I describe methods I have often used to gather information for maintenance releases: 

• Directly using the existing legacy product, if it is available to me.
• Reviewing the current user, administration, or installation  documentation.
• Reviewing all functional requirements and technical specifications, with a focus on understanding changed or new functionality.
• Identifying where in the current documentation set I must incorporate the changed or additional functionality (for example, is it a global hit or an isolated hit?) 
• Speaking with the customer directly about the completeness, accuracy, and usability of the current documentation. In absence of a direct contact with the customer, asking internal customer representatives about the quality of the current documentation (Product Management, QA, Technical Support, and Sales Engineers).
• Reviewing any bugs logged against the existing product and documentation.
• Interviewing subject matter experts (from both technical and non technical disciplines).
• Incorporating updates for the new funcionality and sending out new drafts incrementally, and in small sections, to the key reviewers, *before* a formal review process even starts. (I use the early drafts as an interviewing tool to flag any anticiptaed issues with the key reviewers and to clarify up-front the best way to work together.)
• Incorporating edits, making requested changes, and adding further content, incrementally.
• Testing my own drafts against the product. Filling out details as I take second, and even third passes, at the sequence of steps.
• Organizing myself, or with the coordination of Program Management (if Program Management exists), at least one formal review of the document.
• Incorporating any required changes, based on the formal review, and recirculating the final draft, in an e-mail, with voting buttons to accept, or accept with changes, the final document.
• Ensuring at a minimum that users have a way to contact the Documentation team with any feedback.
• Developing and distributing a more detailed user questionnairre about the documentation’s completeness, accuracy, and usability.

In general, it’s really important as a technical communicator to remain as aware as  possible, about your company’s strategic vision, product development status, and industry best practices. Active participation in a professional society (like the Society for Technical Communication), attending any internal informational opportunities, such as webinars and brown bag luncheons, regulary using and reading about new technology, and frequently checking in with cross-disciplinary colleagues is the best way to seamlessly gather product information.

Are these information-gathering techniques similar to the way you track down information for maintenance releases, in your organization? How is tracking down information different (or the same), when writing about a new product? What are your biggest obstacles in tracking down information?

Photo Credit, Parksy1964

“Choose a job you love, and you will never have to work a day in your life.” Confucius

This blog covers a variety of topics related to my interests as a Content Developer, who has worked in high technology settings for the last ten years.  Previous to that, I was an instructor in secondary, university, and government settings, with a focus on teaching writing, literature, and history. The continuity in my different roles has been my love of learning and sharing content with others, whether it’s through written instructions, explaining in person, or interacting through a variety of online and offline media.

The tag line for this blog, “Content for a Convergent World,” refers to the intersection of technology with communications.  It also refers to different types of content, as so well-described in Vince Giorgi ‘s post, “Is It Content? Software? Let’s Call It a Branded Experience.”  For Giorgi, a good working definition of content is as follows:

“Value-adding information, interactions, and experiences by which brands engage and build affinity with the audiences vital to their business success.”

In this view, content encompasses, but is ultimately “so much more than words.” Giorgi describes content as “not only white papers and webinars” but also “widgets, generators, configurators, and calculators that let customers, prospects, or stakeholders accomplish real work, or real lifestyle fulfillment.”

Giorgi draws inspiration for his post, from Hillel Cooperman, who formerly directed the Windows user interface team at Microsoft, and is the more recent founder of Jackson Fish Market.  At a recent conference, Hillel proposed that “software and content are becoming so intertwined, there’s no longer much point in drawing any distinction.”     

Exploring this “content-software convergence,” or in broader terms, this communications-technology convergence, is the purpose of this blog. 

Here, you can expect posts that relate to the convergence of technology with communications, from my experiences and interests as a technical communicator. I use Giorgi’s three-part definition of content (information, interactions, and experiences), as main categories for my posts, in addition to general book reviews, technology topics, and professional resources.  

In addition to technical communication (my primary area of expertise), I examine related disciplines,  including content marketing, user experience, instructional design, and most recently (and very enthusiastically)–social media.

Through my posts, I hope to engage other technical communicators, content & social media marketers, user experience specialists, instructional designers, product managers, customer experience specialists, and the many other technical colleagues who make my line of work such a rich, cross-disciplinary experience.

I welcome your comments and participation in helping to shape this blog, especially as the convergence of communications with technology touches every professional discipline. As Content Wrangler Scott Abel notes (as @scottabel, on Twitter):

“Digital acumen is no longer a niche capability; it’s part of the central and requisite skill set for all knowledge workers.”

Thanks for joining me here, as through my posts, I explore the digital acumen, so necessary for all knowledge workers to remain competitive in today’s global workforce.

 Note:

This blog is published for information purposes only and the author is not responsible for any consequences that might arise due to use or misuse of any information herein.

The views expressed here are the author’s alone, and they do not necessarily reflect the views of the author’s employers (past, present, or future) or other organizations.