Creative Spaces: Where Process & Serendipity Meet

This past winter, when I was preparing for my presentation on the New England tavern’s similarities to social media (see Social Media 18th Century and Today), I found Steven Johnson’s excellent TED talk, on open innovation systems.

The author of Where Good Ideas Come From, Steven Johnson explores the recurring patterns that make environments more creative and innovative.

Fluid Networks and Creativity

Just as an idea represents a series of new connections between neurons in our respective brains, so too, Johnson suggests, are some environments more likely to stimulate these new configurations.

He describes the architecture of the creative space as a fluid network, where people from different backgrounds and interests can get together, allowing their ideas to mingle. He goes on to say that good ideas have long incubation periods, known as the slow hunch, which may take years to evolve. A good example, Johnson elsewhere cites, is the Worldwide Web, which reportedly Tim Berners-Lee worked on at the back of his mind, for at least ten years.

According to Johnson, innovation and deep thinking take place in environments, similar to the seventeenth or eighteenth-century coffeehouse or tavern. With the increased connectivity, we’re more likely to borrow from others’ hunches, combine them with our own, and over time, form something new.

Intentional Serendipity

Johnson’s talk made me recall one job setting, where as part of my interview, the product manager proudly gave me a tour of the company’s newly designed office. The office provided a large open space and every detail of the physical layout was designed to reinforce the Agile methodology.

In that open space, the various members on the product development team, with reps from each discipline (including technical writers) met daily, for their SCRUM status.

The thing that struck me the most about that setting was the intentionality of the office design…The entire environment was architected from the start to invite the kinds of unpredictable collisions that lead to innovation.

It represents to me process and serendipity working together, and is probably what Johnson meant when he concluded: “Chance favors the connected mind.”

Fostering Open Innovation Systems

So, what environments have most inspired your own creativity? Do you agree with Johnson that innovation is rarely a single moment of inspiration, but rather the collision of smaller hunches over time, within fluid networks? How can we foster open spaces and other hunch-cultivating mechanisms, within our own organizations?

Finally, is it possible to connect and protect ideas at the same time? What are, (if any), the acceptable tradeoffs? (In the O’Reilley Webcast on Information Security and Social Networks, Ben Rothke provides excellent tips on finding this balance.)

About This Blog: Copyright Information

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

Links of Note, June 2009: Technical Writing and Communication

It’s Links of Note time, with a look this month, at technical communication. Like marketing, technical communication is evolving in a Web 2.0 world. This post gathers technical communication links about the future of the profession, the future of the Society for Technical Communication, and recent books on timely topics, including the social web for documentation and DITA. Of special interest is a post about core technical writing skills, including information architecture and usability expertise, which are finding their way into high tech copywriting.

Future of Technical Communication

55th Annual Conference – Technical Communication Summit: Session Materials:

If you missed the Society of Technical Communication’s 55th Annual Conference, check out the session materials for the latest tips and trends.

How to Avoid Extinction as a Technical Communicator:

An excellent post, in which I’d Rather Be Writing’s Tom Johnson summarizes a career development workshop where Ellis Pratt (@ellispratt on Twitter), one of the founders of Cherryleaf, argued that technical communicators may eventually become extinct, if they keep using the same methods and formats to deliver information.

Although there will always be a need for people to explain technical material to non-technical people, Ellis said, others may be doing it instead, through the formats users prefer. To survive, technical writers may need to morph into content strategists, managing the information in a systematic way, rather than merely creating it.

Rather than being a “technical communicator,” Ellis believes these roles will more likely be content wrangler, information strategist, user-generated content editor, information assets director, and content use analyst.”

Johnson shares his thoughts on Ellis’ vision of the technical communicator’s evolving role, agreeing that technical communicators have shown little innovation delivering information, in more consumable formats. As an alternative to online help and the long manual, Johnson offers his own success with quick reference guides (anywhere from 1 to 8 pages) and short video tutorials (2 to 4 minutes), as core deliverables. He also mentions his excitement about the potential of new DITA publishing capabilities of Flare 5, because “it means you can push the content out to additional formats more easily.”

You can convert DITA to the Confluence Wiki format, DITA’s XHTML target to WordPress, DITA to InDesign, DITA to web pages, and other formats.

Johnson does not think technical communicators will be displaced by user-generated content.

Except for public, web-based, multi-author, open-source software models, I just don’t see a lot of users contributing help content to the corporate-grown applications (except for the big ones, such as Microsoft Office). Most companies want their help content to look attractive and be accurate, and few project managers believe users can and will fill that gap if you take away the technical writer.

This is the Future of Technical Communication:

Sarah O’Keefe considers the implications of technical communicators monitoring and managing your organization’s communities, via forums and wikis. She asks, “Under what circumstances do you delete information? How do you respond when: information is inaccurate, information is unflattering, or both?”

What if the information is accurate but incomplete?
What if someone describes a way of using your product that could cause injury, even though it’s technically possible? Do you delete the information? Do you add a comment warning of possible injury? What if the reader sees the original post but not the comment?

U.S. Government Acknowledges Technical Writers As Distinct from All Other Writing Professions:

The Society of Technical Communication has been working with the US Department of Labor’s Bureau of Labor Statistics (BLS), since 2007 to update its definition of the technical communications profession. At long last, the Occupational Outlook and Handbook (OOH), published by the US Department of Labor’s BLS, will have an individual report on technical writers, soon to be offically known as technical communication specialist, in the next edition.

From Technical Writer to Marketing Writer:

Given tight budgets, many technical writers are asked to take on marketing writing responsibilities, in addition to their technical documentation deliverables. Janice M. King, herself a former technical writer who transitioned to marketing writing, helps you hone your copywriting skills, with Becoming a High-Tech Marketing Writer. This free guide shows you how to write “powerful promotional materials for high-tech products, services, and companies.”

What Technical Writers Know That Copywriters Don’t:

Janice King, author of Copywriting that Sells High Tech, describes skills in the technical writer’s core set, which copywriters in PR and Marketing departments requires these days, to add interactive content (such as podcasts, webinars, blog posts, and other social media outlets) to traditional marketing doc deliverables (for example, press releases, white papers, and data sheets). For more information, see From Copywriter to Content Developer and the related post, What Technical Writers Can Learn From Copywriters.

The Society of Technical Communication

State of the Society:

“This web page will provide community leaders with information about STC’s current financial challenges to aid in the understanding of the recovery plan that will be presented and discussed during the town hall meetings via conference call.”

From Virtual Town Hall slides, projected 2009 shortfall as high as $1.2M USD, caused by overreliance and recession’s impact, on membership dues and annual conference.

Whither STC?:

In a thoughtful post, Sarah O’Keefe calls on the STC to make some significant changes in the following areas: velocity, community, and openness.

Lifelines to the STC:

I strongly agree with many of Tom Johnson’s 15 points on reforming the STC, which can be summarized here: “Closing off and restricting access to information, with the assumption that doing so increases member value, seems to run contrary to directions the web is heading.” In particular, as a member, I feel my dues should cover more training webinars (which are of value to me, for free, or at a significantly reduced cost.)


Anne Gentle on her Forthcoming Book ~ Conversation and Community: The Social Web for Documentation:

Tom Johnson interviews Anne Gentle about her forthcoming book, Conversation and Community: The Social Web for Documentation, due out, by mid-summer 2009.  Gentle talks about “the future of documentation, the writer’s role, community and documentation, commenting and connecting with users, structured authoring with wikis, and more.” For more information about the book’s release, follow developments at Anne’s blog,

New Book Aims To Help Newbies Understand DITA Basics:

Scott Abel recommends DITA 101: Fundamentals of DITA for Authors and Managers, from the Rockley Group, as an important work to help technical communicators learn how “to write modular, topic-based, context-independent content using a new breed of authoring tools.” He asserts that learning about DITA is essential for technical communicators to remain competitive:

Gone are the days of the free-for-all approach to creating technical documentation products one-at-a-time using desktop publishing tools. While this technique was the best method possible in the 80s and 90s, today, those who create user manuals, online help systems, and other types of documentation are increasingly expected to take a more formal approach to content creation, utilizing content standards like the Darwin Information Typing Architecture (DITA).

Technical Writing 101, 3rd edition – a review:

This link provides a recent review of Technical Writing 101: A Real-World Guide to Planning and Writing Technical Content, 3rd edition; Alan S. Pringle and Sarah S. O’Keefe, Scriptorium Publishing Services Inc., Research Park Triangle, NC, 2009, ISBN: 978-0-9704733-7-0, 328 p., $20.00 (PDF Download), $35.95 (paper). I am currently reviewing the PDF version of the book and agree that even experienced technical communicators can benefit from its guidelines. Its an ideal resource for college technical writing instructors.

About This Blog: Copyright Information

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

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

Asking the Right Questions Adds Value

The technical information for a product that is still in development does not often “live” in any one person’s head. It’s my job as a technical writer (or technical communicator, the title many of us prefer) to scout out the disparate pieces of technical information in the organization and to assemble those pieces into a coherent instruction, description, or structure.

How many times have you had two or more technical reviewers contradict each other in their documentation mark-ups, as to how the functionality works? This occurrence is not surprising, because developers are often responsible for their particular cylo of the code, and it is not until documentation review time, that individual contributors have the opportunity to reflect on how the parts fit together.

How often have you noticed inconsistent terminology between the marketing literature and User Interface (even across the same User Interface) and mediated between the different disciplines to adhere to consistent terms?  Or have you ever noticed lots of steps in your install instructions that might be better incorporated in the installer itself?

In other cases, we know as experienced technical communicators that if a feature or piece of functionality is really difficult to explain, then there is probably something still rough, counter-intuitive, or outright missing in the product’s functionality or design.

In all these situations, a good technical communicator, aided by an iterative documentation review process, can help facilitate product development. By asking the right questions, technical communicators can get the right people talking to each other, about how the product works, or should work, as a whole.

In the process, technical communicators can help you develop a product that needs less documentation, saving you the associated costs, and offering you instead more complete or intuitive functionality.

What other ways does a technical communicator add value to product development? In your experience, what are the most succesful ways technical communicators can quantify the value they add to upper management?

About This Blog: Copyright Information

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

How Do You Build Successful Relationships with Your SMEs?

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?

About This Blog: Copyright Information

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