Archive for Best Practices

Cognitive loads are heavy

What we do for a living – we being the field of people who develop information for others to consume – is educate people. We may teach them about the proper way to use our products, complete their vacation form, use that machine correctly, why they should buy our products, or many other things. But at the core, we educate people by giving them information they didn’t have before.

Driving on the left

This occurred to me when I was in New Zealand. For me, driving was a constantly attentive activity for me. As with any attentive process, I couldn’t do anything but focus on driving because I was on the wrong side of the car driving on the wrong side of the road. All my instincts, if you will, were completely wrong.

For most of us, by the time we’re 4 or 5, we’ve learned the proper side of the car and the road at such a level that we don’t think about it any more. We know what side of the car to get in, it’s instinct. This is called preattentive. It’s like muscle memory – you don’t think about it, it just happens.

This is very useful to us because it lets us (humans) function in the world. If we had to think about everything – walking, reaching for a cup, etc – then we couldn’t cope. When we’re learning something new, it’s attentive until we’ve mastered it and then it slips into the preattentive areas.

It’s all wrong

So what happens when you move a preattentive activity back to an attentive activity? You put your user under a lot of stress. Our brains want to function at that preattentive level for this activity and we’re forcing it to work at an attentive level.

We’re under a cognitive load. The entire activity has to be thought out at all times while our brain fights us, trying to drop back to the easier preattentive level. Our entire attention is taken with it. Cognitively, it’s really hard. Really hard.

This is where those we educate get cranky. They complain that it’s too hard, they don’t like it, and they don’t want to do it. It’s true for them: it is hard and their brains do hurt.

So how do we help?

Part of our job is to reduce the cognitive load for our users as we educate. We are more successful if our users don’t have the extra effort of trying to find what they’re looking for or if the information they need is right in front of them as they need it. Think of us as carrying the load for our users.

One of the ways we can carry that load is to not make our users stop their task and go find the information they want. I’ve read studies that show up to 30% of the day for knowledge workers is spent just trying to find the right information.

Where’s the metadata?

Metadata is lovely but it means you’re probably putting the burden on your overloaded user to go find what s/he needs. They are already unhappy because they don’t know something–why are you now forcing them to play Guess Our Metadata? There have to be better ways to reduce cognitive loads.

Original published here.

New tools are a chance to improve your workflow

I was talking to a friend whose employer has merged with another company. My friend’s company spent the last 5 years clawing its way to supportable and repeatable processes throughout the company as they build software products. If you are familiar with the 5 levels of the Capability Maturity Model, they had finally reached something close to a level 4.

It was hard and they struggled but development, testing, and documentation had stable processes that supported consistently developing products.

Then the merger happened.

Post merger

As they bring the 2 companies together, they are also breaking the company into 2 parts, based on markets. The split is not based on previous company affiliation, but rather on the needs of each vertical market both companies sell into. It makes sense to break it up this way, because the products are related but the needs of each vertical are very different.

This could all be very good, except for one thing: the company they merged with has no actual product development processes.

And that could all work if Company A (my friend’s employer) consumed Company B. But that’s not what’s happening. As they break the companies apart and regroup into 2 separate business units, the processes of each company are staying in place. Those people who are moving into the business unit that was Company A get the existing and stable processes of Company A. Those who are moving into the business unit of what was Company B get all the processes of Company B, which is to say, none.

6 levels of the CMM

My friend and I have thought for years there are actually 6 levels of the CMM. We both discovered this level when we ran our own consulting companies. We also learned to identify and then run away when we first met with these potential clients because nothing good ever happened.

The 6th level is negative 1. Working with a negative 1 level will destroy your processes if you are a contracting company providing outsourcing services, like product documentation. Think of it as entropy.

There is a place for the negative 1 level – three people creating some wild new technology in a garage somewhere can actually benefit from this level because it strongly encourages crazy mad ideas that then get tried. These ideas would be shot down any other place because they are crazy mad ideas. But for these people in that garage, it’s a creative environment that works.

The moment these people move into any level of developing the crazy mad ideas into some actual products, level negative 1 will kill them. Perhaps slowly, perhaps quickly, but entropy will have it’s due.

And how do tools fit in here?

Very often, companies with few to no processes decide the problems they’re having are because they don’t have the right tools. If they got the right tools, they reason, this would all be better.

So they build a feature list. And they buy new tools.

They don’t bother to train anyone, or set up any Best Practices for using the tools. They just buy them, install them, and then continue on the way they’ve been. And nothing changes, except some vendor somewhere got a nice fat check.

New tools are not feature lists

If you (or your company) are thinking about improving how you do the business of what you do, new tools can help a lot. But new tools also require that you look at your existing processes and be brave enough to change what isn’t working. And something isn’t working if you’re looking to get new tools.

Think of purchasing new tools as a time of reflection for your company. Identify what’s not working in your processes and then find tools that support your efforts to make it work better.

Don’t look for new tools based on a feature list – look for new tools based on the business problems you have and the business solutions you need. When you identify the business issues you need to solve, you’re going to be looking at processes as well. You can’t help it.

I can help you identify and select tools that improve your business. Contact me to find out more.

Modified from the original found here.

Single sourcing and content management

The journal Technical Communication has article that I found very interesting.

Single Sourcing and Content Management: A Survey of STC members. David Dayton and Keith Hopper.

I’m not going to do a detailed review because you all can read it yourself. But what I found interesting was some of the results.

Results

Of the 276 respondents to the survey, half reported using single sourcing or single sourcing with some sort of content management. I would have expected that number to be higher, since single sourcing has been around since at least 1996. The cost (time) savings alone make the content development method make sense. It’s just not a new technology and I was surprised that not 90% or more are single sourcing.

Drivers of moving to a single source and/or content management development method were unsurprising:

  • faster information development
  • regulatory or compliance issues
  • translation efforts

About half the people using single source and/or content management said there are downsides and tradeoffs, which I found completely unsurprising.

These information development techniques are potentially restricting if you want to just focus on writing. These methods force you to think about how and where your content is going to be used and that can feel restricting. But it’s critical, I think, to consider when you develop information.

A surprise

Apparently, the majority of people are using Word to author and are trying to do some sort of single source and/or content management. Which I think is doomed to failure.

Word is a delightful tool for short documents. But if you’ve written a 400 page book in Word (as I have, several times), you know it’s the wrong tool to try anything like single source and/or content management. They don’t give us numbers for the failed projects that were done in Word, but I’d like to see those.

They do seem to find that more larger companies have moved to single source and/or content management as compared to smaller companies. I have to wonder if larger companies see the business benefits of managing their information the way they do any business asset. Smaller companies may not have reached that point yet.

I’d also like to know how many small companies are using Word, as opposed to the larger companies. Again, smaller companies might be using Word because they are not thinking of information as an asset to be managed.

The summation

The summation was interesting to me – the authors say that a single source and/or content management environment has hit critical mass. This information development method is now into the early majority.

But if you look at just those using a content management system (which should include single sourcing but the authors say it doesn’t have to), then this development method has not quite crossed the chasm.

There are a lot of other pieces of good info and you should look up the entire article. It’s worth it.

Original found here.

Adult learning theory

I’m not a strong visual learner. I like words and getting my hands on things. But many people are strong visual learners and I need to accommodate them in any content I develop. So, since I like words, I found a book that helps me with visual information. I thought I’d share some highlights with you in case you’re also not a strong visual learner.

By the way, to find out your learning strengths, take the VARK quiz.

The book is a classic: William Horton’s Illustrating Computer Documentation. Wiley Press, 1991.

I realize it’s older but the concepts and principles are valid regardless of when it was written. If it’s not on your shelf, I strongly recommend you get it. Mine is dog eared and written in and tagged all over.

Design content for scanning

Since I like words so much, I was delighted to discover that words can be graphical elements, too. Lists and tables are visual and need to be designed as such to support your visual learners.

While tables are inherently a grid, you can make tables harder to read by using horizontal AND vertical lines. Pick one (and you may not even need that) that suits the information and stay with that. Make any lines thin enough to let the eye follow but not thick enough to visually draw the eye.

Since humans are hard wired (because of the rods and cones in our eyes) to see lines, we want the thickness of the line to not overwhelm the visual field.

Lists are always a good thing to use. If you use lists, make sure they are used correctly.

  1. Numbered lists imply steps.
  • Bulleted lists imply a lack of order.
  • Check box (which I can’t figure out how to show you here) lists imply completeness.
    • If you use several levels of lists, use a different bullet for the other levels

Organizing content visually

Screen captures are good and we all use them, assuming you’re developing content for software. But think about how else you can visually show information.

For example, the last time I was documentation manager, I instituted a policy that every chapter (section) must have an introductory paragraph(s) and then a graphic that illustrated the ideas in the paragraph(s). This supported both our word learners and our visual learners. It visually organized the content in that section.

Typically, we had a flowchart, showing information flow through the system but sometimes we showed how parts worked together. It depended on the content in that section. We single-sourced that graphic to the online help to support the different learners there as well. Had we the time and the staff, the graphics might have become animations online.

Original found here.

How do good workflows go bad?

I’ve been in this industry a long time and I’ve seen a lot of workflows. I’ve been in the position of:

  • Write like crazy, hoping for the best
  • Plan every detail to the smallest step
  • Not allowed to talk to the developers
  • Easy reviews
  • No reviews
    • A personal favorite reviewer who would not sign the docs off as accurate if the word “must” appeared any where in the 800 page mainframe manuals. “It sounds like we’re ordering them,” she said.
  • And everything else you can imagine

My heroes have always been writers

Because I have no life, I was thinking about this as I was walking my tricolor Australian Shepherd over the weekend. During the 2.75 mile brisk walk, I was thinking about all the places where technical documentation goes wrong.

I was also thinking about my duckling engineering students. I’m trying to grow the engineers we all want to work with. This quarter, they seem very passive and helpless. I’m worried that if they don’t show more initiative that they are going to go in the box of “bad reviewers”. I’m worried about other things for them as well, but these were my thoughts.

And that made me start wondering why we get crazed bad reviewers in the first place.

  • No one cares? I see such passion in other areas of the product development, so I don’t think that’s all of it.
  • The reviewer finally has control over something? In the case of my “must” reviewer, I think that was the case.
  • Engineers have a hard time understanding the different audience needs? I see this from some of my ducklings, so that’s part of it, I think.
  • Institutional culture? I think sometimes this is the case. I worked at a place where one of the senior dev leads would stop my writers in the hall and spend 10 minutes talking about how what we did was stupid and a waste of company money and not needed. The VP of Dev didn’t think this was out of line. I wanted to do the same to his developers but I’m too nice.

Modified from the original found here.