The STC Rochester chapter hosted a suite of speakers at their annual Spectrum conference to address the following questions.

  • How do we sustain our practice of technical communication and career growth in this challenging time?
  • How do we stay flexible?
  • How do we nurture our creativity and apply it to our work?

While there were many speakers and answers to these questions, I recapped my main takeaways based on the talks that I attended. Looking forward to continuing these conversations at the STC Summit next month!

As a career

Alisa’ keynote focused on sustainability as a career path for technical writers, in that sustainability is an area of increasing visibility within companies. You might approach sustainability from job titles like Scientific Writer, Documentation Specialist, or Compliance Officer, and produce written texts like impact reports, annual sustainability statements, RFPs and bids, and marketing content.

As part of your content creation practices

Even if you’re not directly in a sustainability role, you can think about sustainability in your doc practices. For example, consider the storage and bandwidth that images and videos require, which burns through a lot of energy, and ask:

  • Do I need these images or video in my documentation? presentation?
  • Do I need to share my screen or turn on video in this call? Can it be a regular phone call vs. an VoIP?
  • Can I reduce the size or omit these files for download?
  • Can I use a blog, portfolio, or other online template that uses plain text, whitespace, and selective color instead of relying on graphics?

Just because it’s digital, doesn’t mean it’s free.

As a process or automation opportunity

In my CLI talk, I shared examples of how we standardize CLI documentation across products as well as interfaces in IBM Cloud. In particular, the attendees were interested in an automated script that other folks on my team developed with the engineering team to “single source” the help text that appears in the command line as well as the doc pages from the same source file.

Another process-related area for sustainability relates to templates and style guides, which may sound like old hat to technical communicators, but are constantly evolving. Communities like STC or Write the Docs can be good sources for compilations of such resources.

The need to be flexible seemed to arise from products, systems, and other environments with many components that can be recombined in different ways by the end users to achieve both similar and different goals. In my mind, I connected flexibility with findability, that users have to be able to discover and piece together a solution from amongst the many (relevant and not so relevant) content pieces that we produce. It also seems to me that tech writers are increasingly asked to develop more Solution Architecture-related docs, helping busy, confused, and overwhelmed users navigate entire products, even cross-company.

One speaker, Matt Reiner, works at k15t which builds apps for the Confluence platform, and shared his “recipe” for creating an “information experience” (borrowing a term from Daniel Steven’s Write the Docs talk). Simplicity adds to flexibility, and at least semi-structured authoring (such as using genre conventions or content chunks even if you’re not in full-blown DITA) helps you remix content where you need it.

  • Story: What are you trying to tell? What are you trying to get users to do?
  • Assemble ingredients: What pieces of content do you need to tell the story?
  • Make a starter: What is a quick, basic set of tasks or information that you can give users to do something now?
  • Separate and spread: What are more advanced steps that they might need as they continue?
  • Blend well: What’s the most effective combination of these ingredients, starters, and spreads?
  • Serve: What’s the best way to display this content?

If you, dear reader, are picturing a smorgasbord of delightful delicacies and content morsels that is making you hungry, you are not alone.

Lou Prosperi began his talk on “Imagineering” by posing the question: Are we technical communicators, or are we technical communicators?

Let that sink in for a minute. What types of tools do you gravitate towards using? What value do your coworkers expect to get from you? What type of value do you want to bring?

He argues that technical communicators are well poised to “imagineer,” which comes from Walt Disney’s approach to telling stories. Imagineering is a portmanteau of imagination and engineering.

  • Blends creative innovation with technical know-how
  • Uses various tools, techniques, and disciplines to convey specific ideas and experiences to an audience
  • Creates stories, not necessarily a three-part rising action, denouement, closing, but a core idea, or premise, that underlies each feature, attraction, land, ride, venue, and so forth.

He used the Magic Kingdom to highlight some of Disney’s most effective techniques for creating magical experiences.

  • Wienie. A weinie is something to draw someone into an area. Disney used to lead his pet dog, Duchess, around by enticing her with a “wienie” hotdog, and guests need a similar incentive trail to draw them in, attract attention, and capture interest.
  • Story. It all begins with a story, your subject matter. Your story becomes the basis for all the decisions moving forward.
  • Progressive disclosure. From general impression to specific scenes and details. More details as you move closer. Concept/overview before specifics.
  • Forced perspective. Alter perspective to get them to focus on what you want them to. In graphics, this might mean Simplified User Interfaces (SUIs).
  • Creative intent. You can have fun, but it should have some sort of purpose, like how a makeover prepares you for a gala ball. Design goals to accomplish the experience.
  • Attention to detail, even in places you don’t expect the audience to look.
  • Pre-shows to introduce the audience to the story before it even begins.
  • Readability, clear signs, repeated and expected
  • Theming and staging that intensifies the experience and makes sense within the context of the story.
  • Plussing, a term for making things better, improvement via iteration, constant improvement, how to make this better?

So where is it all going?

The closing panel discussed our most pressing issues keeping us up at night, what we’ve learned with hindsight, how to adapt, how things are shifting, and our most important practices.

Both challenges and opportunities centered around standards; globally spread and remote workforces; the changing reporting structure of tech comm into different units like R&D, Product, Sales, Support, or Marketing; and the perception of technical writing in the workplace.

Some ideas that came out of the panel are:

  • Ground your practices in research. If you don’t know where to start, ask around and google.
  • Adapt to changing genre conventions. One team found success doing product office hours, another produced a bunch of training videos during the pandemic. I jokingly suggested “Tech Comm by TikTok” might be next, and several panelists took up the challenge by thinking of ways that could work for their audiences.
  • Rhythms and times of day to maximize your tasks. Many people need more cognitive attention and “deep work” when writing new content from scratch, and that usually means the morning. If you have the flexibility with remote work, experiment with your calendars to find a flow that works for you.
  • Analytics to help prioritize and focus work…but a lot of this analytical work is a combination of qualitative and quantitative, often informal, research.

Talks that I attended:

  • Keynote event, Alisa Bonsignore, How Sustainability Can Transform Your Career
  • My own (Art Berger), Improving the developer experience (DX) of your content with command line interface (CLI) docs
  • Matt Reiner, Bake a Little Documentation Love into Your Product
  • Lou Prosperi, Tell Your Story the Walt Disney World Way: Adding Disney Imagineering to Your Technical Communication Toolbox
  • Closing panel moderated by Janice Summers and featuring John Freiberger, Mark Kleinsmith, Kerry Roberts, Angela Trenkle, and Ann Wiley, myself.
Art Berger

Art Berger

Technical Writer at IBM and President of STC Carolina

Art Berger works as a Technical Writer for IBM, where he helps create technical documentation for the company’s cloud services and open source projects. His team produces a wide range of products, including instructions, training materials, application program interface (API) documents, user interface (UI) text, command line interface (CLI) strings, error messages, videos, infographics, and more. As the President of the STC Carolinas chapter, he enjoys helping people in the local area connect with other professionals, events, and resources to succeed in their tech comm pursuits.