Write the Docs Podcast episode 15: User research, tech writer stereotypes, and conversations

After a short summer break, we've returned to the WTD podcast and taken up our mics again to talk about important doc issues. In this episode, we first chat about assumptions we have regarding our users and the value of doing user research. Basing the discussion on Jen Lambourne's talk at WTD Portland 2018, we talk about ways to capture the user perspective and limitations/workarounds for user research within the corporate domain. Next, we chat about an article by Emily January Petersen on the Make-It-Pretty Philosophy, where the roles of tech writers are reduced to grammar and style editing only, without more substantive updates and revisions to content. Finally, we talk about Tom's research project on healing the academic/practitioner divide and how he hopes his conversation posts will bring both sides more closely together.

Teaching Technological Adaptability to Bridge the Gap (Guest post by Melonie McMichael)

The following is a guest post by Melonie McMichael, a senior instructor at the University of Colorado and the proprietor of Technodaptability. In this post, she explores the challenge of teaching technology to students in tech comm programs, arguing that perhaps the chief challenge of teaching adaptability is the need to be adaptable ourselves.

Combatting the "Make-It-Pretty" Philosophy: Technical Writers Fight Back (Guest post by Emily January Petersen)

In this guest post, Emily January Petersen, an assistant professor at Weber State University in the Professional and Technical Writing Program, talks about stereotypes in the workplace that devalues the work of technical and professional communicators. These myths perpetuate the idea that technical communication work is cosmetic, secretarial, unknown, and unnecessary.

Results from my Academic/Practitioner Attitudes surveys now available

The results of my Academic/Practitioner Attitudes surveys are now available. The most interesting response (for the practitioner survey) was regarding the statement that academics understand issues that practitioners face in the workplace. Most (42%) were undecided while 36% disagreed or strongly disagreed. For the academic survey, the most interesting response was regarding the statement that practitioners (rather than other academics) are the primary audience for academic research. About 50% of the academic participants either disagreed or strongly disagreed. Overall, 407 practitioners and 65 academics completed the surveys. The results will fuel phase II of my project, which involves creating academic/practitioner conversation posts.

The relationship between academics and practitioners -- Podcast with Kirk St. Amant
The relationship between academics and practitioners -- Podcast with Kirk St. Amant

In this podcast, I chat with Professor Kirk St. Amant about the relationship between practitioners and academics. Kirk recently co-authored an article about research as a unifying focus to bring academics and practitioners together. Using this article as the basis for discussion, we dive into origins of the divide, why both practitioners and academics of the same field need each other, potential solutions, and more.

Reducing the complexity of technical language (new article in Simplifying Complexity series)
Reducing the complexity of technical language (new article in Simplifying Complexity series)

I added a new article in my ongoing series about simplifying complexity. The article is called Reducing the complexity of technical language and explores reasons why the language in technical documentation tends become so full of jargon and other unfamiliar terms, and a few solutions for simplifying the language. I emphasize the need to read the competitor's documentation and other articles in the industry to get a sense of the right terms and contexts that users likely expect. I also decided to read the article for those who prefer podcasts.

Random reflections on the throwaway mentality in our culture

When should you fix a broken process and when should you simply throw it away? Sometimes we continue on within broken processes for years; it might make sense to systematically try to fix broken processes — to a point.

Thoughts on docs-as-code after 3 years -- it works!

I've been quite happy with our current docs-as-code implementation. It's worthwhile to periodically reflect why the docs-as-code approach tends to work so well.

A short survey to measure academic/practitioner attitudes

The following two surveys will capture the thoughts and attitudes that Tech Comm practitioners and academics have towards each other as members of the same field. The survey takes approximately 1 minute to complete and consists only of 7 selections about whether you agree or disagree (along a scale). Your answers are anonymous. The responses here will be compared to a similar survey administered at a later time.

10 ways technical writing is just like the World Cup

I don't usually watch soccer, but I do get drawn into the World Cup. And this year, I'm finding that there are a surprising number of similarities between the World Cup and technical writing. Yes!!! So let's get started with the top 10 ways that technical writing is just like the soccer at the World Cup.

MadCap Flare 2018 and MadCap Central Review for the May 2018 Release -- Guest post

The following is a guest post from Una Cogavin, a certified MadCap Advanced Developer and Flare consultant. In this post, Cogavin reviews Flare 2018 and Central and explains the features she finds most useful in these tools.

Evaluating the user experience of documentation -- Podcast with Bob Watson
Evaluating the user experience of documentation -- Podcast with Bob Watson

This week I chatted with Bob Watson, an assistant professor of tech comm at Mercer University, about how to evaluate the user experience of documentation. The idea of doing a podcast came up during a comment thread on a previous post about reconstructing the absent user. We had a long exchange in the comment threads and thought it would be good to have a podcast about the topic.

Non-Reference Content section updated in API course

I updated and reworked the topics in the Non-Reference Content section in my API doc course. This section includes the following topics: API overview, Getting started, Authentication and authorization, Status and error codes, Rate limiting and thresholds, Code samples and tutorials, SDKs and sample apps, Quick reference guides, API best practices, and Glossary. These sections are important in API documentation but tend to be overlooked as most discussions around API documentation focus on endpoint documentation only.

Hiding Complexity -- A new Simplifying Complexity article

I added another article in my Simplifying Complexity series. This one is called Hiding complexity through JavaScript show/hide elements. The basic principle is to look for ways to reduce complexity by hiding less-used information on the screen through JavaScript techniques, such as show/hide elements, expand/collapse toggles, and more.

New article in Simplifying Complexity: Reconstructing the absent user

I have a new article in my series on Simplifying Complexity. This article talks about why reconstructing the absent users is essential to creating good documentation.