The Not-Boring Tech Writer

Paul Stoecklein knows documentation: As Documentation Manager at MadCap – the industry leader in documentation software – and longtime technical writer, Paul understands what does and does not work for documentation teams.

A methodology that Paul believes is essential for documentation teams is single-source authoring: to use a single-source of documentation for multiple outputs.

In this episode, Paul shares how you can implement single-source authoring in your organization, including:

• how single-source authoring can add value to your organization.
• why all documentation teams should consider single-source authoring.
• what tools and processes can help you succeed.

Show Notes: 

• MadCap Software
• MadCap Flare
• Doc-To-Help
• MadCap Capture
• MadCap Mimic
• Flare’s Online Help

We’ve all read (and perhaps written) a boring document: the robot-like language, the walls of text. And we’re all familiar with the result: a disengaged reader who’s likely missed the message.

Enter John Espirian, freelance technical writer and Director at the Society for Editors and Proofreaders.

John believes the difference between a boring and a not-boring document comes down to one essential element: a human connection.

In this episode, John shares how you can create that human connection in your documentation, including:

• how to better understand your end-users.
• why your documentation tone must match the brand.
• what simplicity means (and doesn’t mean).

Show Notes:

• Pen Portraits 
• John Espirian (Twitter) (LinkedIn) (Facebook)
• John’s site

Knowledge – as technical writers, it’s one of our greatest assets.

However, amid the information overload technical writers often face, it’s also one of the most difficult assets to acquire.

Enter Tom Johnson and Lisa Meloncon. Today’s guests and tech comm. advocates that have graciously shared how you can filter the information overload and shift your focus to the three types of knowledge you need to succeed:

• Product knowledge
• Technical knowledge
• User knowledge

The Show Notes:

• Tom’s post Three Types of Knowledge Every Technical Writer Needs to be Successful
• Episode #6 with Neal Kaplan
• Episode #7 with Ted Hudek
• Tek-ritr.com
• Lisa Meloncon on Twitter
• Idratherbewriting.com
• @tomjohnson (Twitter) (Write the Docs Slack channel)
• Tom’s podcast

As the tech comm industry develops, technical writers must embrace a sobering truth: As Dr. Stan Dicks writes in Digital Literacy for Technical Communication, “Technical communicators who add value to their organizations do not merely write and edit documents.”

So how do we prepare for the future of tech comm so we can ensure we’re adding value to our organizations?

Preparing for the future is difficult without a compass – but fortunately – Ted Hudek, Senior Programming Writer at Microsoft, knows the way.

In this episode, Ted shares his tips on how you can prepare for the future of tech comm, including:

• why you should always have a side learning project.
• why you should not freak out about tools.
• why you should actively build relationships with your colleagues.

The Show Notes: 

• Episode #5 with Eric Holscher
• Episode #6 with Neal Kaplan
• Write the Docs on Slack
• Write the Docs Meetups
• Ted Hudek on Twitter

Documentation and Support teams share a common goal: to give customers the information they need to get the greatest value from a product.

But despite a shared goal, consistent communication rarely follows.

The result: tech writers missing out on content-rich customer feedback, thus, as our guest Neal Kaplan phrases it, “creating documentation in a vacuum.”

In this episode, you’ll learn how to bridge the gap between Documentation and Support, including how to:

• build rapport with your Support team.
• use the relationship to create better documentation.
• measure the efficiency of your documentation.

The Show Notes:

• Neal Kaplan’s talk at Write the Docs
• Neal Kaplan on Twitter

We’ve all experienced the joy of community: colleagues mentor you; friends encourage you; strangers point you towards their favorite pizza shop downtown.

For that moment, whether you had previous ties to each other or not, you feel that sense of community.

And while every community is unique, one concept is constant: As urbanist Charles Montgomery defines it, “people gathering, talking, and helping one another everyday.”

Eric Holscher (today’s podcast guest) and Troy Howard have captured that concept and created a community for us – the tech writers.

The community: Write the Docs.

In this episode, Eric shares the story of Write the Docs and describes the power of getting involved in a community, including:

• why tech writers need community.
• how to Write the Docs empowers tech writers.
• how to get the greatest value from community.

The Show Notes:

• Ericholscher.com
• Eric Holscher on Twitter
• Writethedocs.org
• Write the Docs on Twitter
• Write the Docs resources

Where should user experience (UX) design fit in the technical writer’s toolbox?

Well, think about how your users experience your documentation:
Are they following a workflow path, following a series of pages to complete a series of tasks sequentially?

• Are they following nav links, jumping around to find task-specific information?

Understanding how your users experience your documentation is understanding UX design – which can make or break your docs’ usability.

As our guest and UX designer Autumn Hood describes it: “You can’t have good technical communication without good UX design.”

In this episode, you’ll learn how to think like a UX designer so you can create an effective documentation experience for your users.

The Show Notes:

• Janice Redish’s Understanding Readers
• Susan Weinschenk’s ROI of User Research webinar
• Autumn Hood on Twitter
• Autumn Hood on LinkedIn

Face it: sometimes, documenting software can be tricky.

Not because we don’t understand the software – we get that. Nor because we can’t articulate it in layman’s terms – we’ve got that covered, too.

But because feature guides – the traditional style of software documentation – isn’t enough to ensure your end users can find the information they need to accomplish a specific task.

Enter just-in-time documentation: a new methodology of documentation that complements feature guides by creating task-oriented documents, as our guest Bri Hillmer describes it, “just in time, when the customer asks the question.”

In this episode, you’ll learn about the power of just-in-time documentation and how you can apply it to your documentation today.

The Show Notes:

• Zendesk
• Zapier
• KnowledgeOwl
• Google Custom Search
• Bri’s Twitter
• Bri’s super awesome documentation

What’s the ultimate stereotype of technical writers?

Easy: that once you begin your career as a technical writer, you’re caught in a documentation vortex. And worse – that there’s no way out.

But just like all stereotypes, they’re meant to be broken.

As communication experts, our skills – analyzing an audience; writing crisp, clear, concise copy – surpass documentation into an industry many technical writers like yourself once deemed “in someone else’s wheelhouse.”

The industry: Marketing.

In this episode, you’ll learn how your skills translate to marketing so you can – if desired – get out of the documentation vortex and transition into marketing.

The Show Notes:

• Adam’s Twitter
• Adam’s blog
• Blue Steele Solutions
• Blue Steele Solution’s Twitter

Once you’ve found your end-user, think about how you find his or her truest needs for the product or service.

For many technical writers, it looks something like this: compile a series of  fairly generic questions – “how old are you?”, “how familiar are you with the technology?” – and hope their responses unveil their needs.

Sometimes it works; but other times, you’re left asking yourself, “What did I miss?”

The answer is simple: Empathy.

In this episode, you’ll learn how to apply empathy to your audience analysis so you can get greater insights on your end-users’ needs, and in turn, create more effective content.

The Show Notes

• Virtual Crash Course in Design Thinking
• Dr. Lam’s scholarly article on audience analysis