Month: November 2021

Next Gen Writing: Sealed With a KISS

~ Susan Kelley ~ Leave a comment

I often hammer away at this thought, but coming to the close of 2021 and heading into another year of technical writing, closing out the first year of a new decade, it seems like it’s time to revisit.

The KISS approach has worked in many other areas of life – Keep It Simple, Stupid.

It’s a bit like the slogan Bill Clinton used to keep in mind: It’s Always the Economy, Stupid. Not that any of us are stupid – quite the opposite, in fact. Many of us are so smart that we naturally assume that those reading our documentation are equally bright. While that may be the case, often our consumers are bright and talented in other areas. Alas.

In technical writing, a few factors drive change and demand a better strategy. We, as writers, call for more user-friendly tools in our writing. Along came Confluence and SharePoint, along came markup, we got to use DITA.

Our managers expected measurably consistent outcomes and cost control in the content we produced. End-users required more user-friendly content. The evolution continues.

Each of these demands is the consequence of expecting easy-to-use methods and tools. Technical writing, the product, is a tool for everyone. What used to be in the rare air is now at everyone’s fingertips in a highly mechanized world. We used to refer to a revolutionary “plain language” style of writing, and now it is merely dubbed “Simplified Technical English,” the demand for which keeps growing.

There is even a dictionary of Simplified Technical English, and it comes with its own acronym, STE, so it looks as if the trend is here to stay. This way of writing improves clarity and quality, but along with those improvements come some difficulties. Any time there is a standard, there are rules. Can we commit those rules to memory as we have grammar and our beloved Strunk & White? Likely, no.

Instead of rote memorization, we look to tools that incorporate STE for us – again, back to those easy-to -use methods to help us out. We want to lessen the cognitive burden, freeing up more so that we can understand the technologies about which we write. Microsoft helps every time it incorporates a spell- or grammar-check into Word, and Grammarly or Acrolinx are to our benefit, to be sure. All of us in the writing game have a love/hate relationship with authoring tools designed by developers, but until we hybridize our own talents, here we remain.

It is key to remember that a great deal of our output is targeted at an international reader. Adopting STE, or Plain Language, is truly beneficial when we localize content. While we should stay far, far away from idiom, trending toward casual writing is in our favor. Using STE as a guide, and truly standardizing our technical writing across all documentation in a given organization is the single best way to ensure that our technical content is to-notch all the way around.

It may seem as though I am beating the proverbial dead horse in this writing, except that end-of-year is precisely when companies are looking to evaluate the cost, quantity, and quality of content produced. Measuring will help improve overall performance and delivery, and will help create harmony among writers and consistency between texts. Why does that matter overall? Because the team that can write with one voice, and that voice is Plain Language, STE, will project to the end user that the company, and its products, are synchronized in performance and quality. And that, my friends, is the penultimate achievement of any writing team.

Best of luck at year-end, and on into 2022 we go.

Advertisement

How Biased Are Your Release Notes?

~ Susan Kelley ~ 1 Comment

Your Own Thinking Can Make a Big Difference

I should probably start with a primer on Cognitive Bias before accusing anyone of allowing such biases to impact their release-note writing. That’s only fair.

Photo courtesy of Ryan Hafey on Unsplash.

In a nutshell, Cognitive Biases are those thinking patterns that result from the quick mental errors we make when relying on our own brains’ memories to make decisions. These biases arise when our brains try to simplify our very complex worlds. There are a few types of cognitive bias, too, not just one. There’s Self-serving bias, Confirmation bias, anchoring bias, hindsight bias, inattentional bias, and a handful more. It gets pretty complex in our brains, and we’re just trying to sort things out.

These biases are unconscious, meaning we don’t intend to apply them, and yet we do. The good news is, we can take steps to learn new ways of thinking, so as not to mess things up too badly with all of this brain bias. Whew, right?

Now that we’ve established a basic taxonomy, let’s dive in to how cognitive bias may (or may not) be creeping in to things like your technical writing. It’s not just in your release notes; that was just clickbait. But sure, bias can permeate your release notes and nearly any other part of your documentation. (Probably not code snippets, but I won’t split hairs.)

Writers and designers must recognize their own biases so that they can leave them behind when planning. Acknowledging sets of biases helps to shelve the impulse to draft documentation that is shaped by what they already know, assets they bring to the table, or assumptions they make about experience levels.

Let’s start with Self-serving bias. How might this little bug creep its way in to your otherwise beautiful and purposeful prose?

This bias is essentially when we attribute success to our own skills, but failures to outside factors. In our writing, this can appear when we imply that by default, software malfunctions are based in user error. Rather than allowing for a host of other factors, often our writing recommends checklist items that are user-centric rather than system-focused. While it’s true that there are countless ways that users can mess up our well-designed interfaces, there are likewise plenty of points of failure in our programs. Time to ‘fess up.

Confirmation bias can be just as damaging, wherein as writers we craft and process information that merely reinforces what we already believe to be true. While this approach is largely unintended, it often ignores inconsistency in our own writing. We tend to read and review our own documentation as though it is error-free, both from a process perspective and a grammatical-syntactical one. That’s just illogical. And yet, we persist. The need for collaborative peer-review is huge, as even the very best, most detail-oriented writers will make a typo that remains uncaught by grammar software. Humans are the only substitute, and always will be.

We write anchoring bias into our documentation all too often. This bias causes us, frail humans that we are, to rely mostly on the first information we are given, despite follow-up clarification. If we read first that a release was created by a team of ten, but then later learn that it is being developed by a team of seven, we are impressed by the team of seven because they are doing exceptional work. Now, it may be the case that when the ten-member team was working on it, three of them had very little to do. Yet, we anchor our thinking in the number ten, and set our expectations accordingly.

The notion that we “knew it all along” is the primary component of hindsight bias. We didn’t actually know anything, but somehow, we had a hunch, and if the hunch works out, then we confirm the heck out of it and say we saw it coming.

This can happen all too often when we revise our technical writing, jumping to an outcome we “saw coming,” which causes us to edit, overlook, or wipe out steps on the path to getting there. We sometimes become so familiar with the peccadilloes of some processes that we only selectively choose what information to include, and that’s a problem.

Inattentional bias is also known as inattentional “blindness,” and it’s a real doozy when it comes to technical writing, believe it or not. It is the basic failure to notice something that is otherwise fully visible, because you’re too focused on the task at hand. Sound familiar? Indeed. Our writing can get all sorts of messed up when we write a process document, say an installation guide, and don’t pause to note things that can go wrong, exceptions to the rule, and any number of tiny things that can (and indeed might) occur along the way. What to do when an error message pops up? What if login credentials are missing? System timeout? Sure, there are plenty of opportunities for us to drop these into our doc, and many times we do, but I saved this for last because – this will not surprise anyone who knows me – in order to overcome this particular bias, all you need do is become best buddies with your QA person. Legit. I recommend kicking the proverbial tires of your software alongside your QA buddy to see how often you get a “flag on the play.” That will grab you by the lapels and wake you up from the inattention, for real.

Your users will thank you if you learn, acknowledge, and overcome these biases when you write. Is it easy? Not really. Is it necessary? I’d say so. As my Carnegie Mellon mentor told me more than once, and I’ve lived by these words for my whole career: “Nothing is impossible; it just takes time.”

Take time with your writing, and you’ll soon be bias-free.