A few months ago I posted seven reasons an organization needs technical communicators. This week, a program manager I work with provided a few more ways that technical writers provide value to organizations and projects, so I wanted to pass along his wisdom—with my own discussion, of course. Because I gave seven reasons before, I’ll start with number eight.

(more…)

For a moment, let me just sing the praises of Akismet.

Me me me me me…

But seriously, if it weren’t for that nifty little plugin, my blog would be drowned under the disgusting tide of trash that hits it, and I’d have to shut it down. So if you post a comment and it never sees the light of day, I apologize; that may just be Akismet getting a bit gung ho.

Now on to the topic of the post here. Recently, the project I’ve worked on since I was hired at the LDS Church has been launched. With that, a chapter has closed of sorts. But perhaps there’s something of an epilogue.

I think the fact that I’ve spent the last three years documenting this software has contributed to my allowing myself to be pulled into support. I provided live training to a number of users, and I have offered my services to train others who may step forward and request it. It’s kept me busy lately.

I posted awhile ago about drawing a line between training and support. But I find that it’s tempting to remain involved at some level because of one key consequence.

I’m getting to know the users.

*Gasp!*

I have found myself wanting to start over with the documentation. My eyes have been at least partially opened. It’s backwards to try hand someone a manual and watch him or her start looking through it so that you can start writing that manual. But maybe the right idea is there. Maybe the thing to do is hand them a manual—any manual—and see what they do with it.

By the way, for “manual,” substitute quick-reference sheet or whatever other form of documentation you want. But what I’d like to do is get to know what my users do with documentation before the expense is made to create it. I’m getting off-topic here, and I intend to think (and post) more about this, but the idea is that spending time with the users has made me aware of how they approach documentation. In this particular case, I expect the need for tech support from me to drop off, but it has turned into a valuable insight for going forward.

In a recent post, I talked about having documentation design reviews. Yesterday, I showed my team a new project I’m working on. I was trying out a new approach, the idea behind which was good. But the team’s feedback helped me turn it into something better—and visually simpler.

(more…)

I’m back in the saddle after camping and then participating in a pioneer handcart trek reenactment last week. The world at work moved on without me, but not far enough that I wasn’t able to get back into things quickly.

A program manager and I were helping some users today when he talked about getting their feedback on aspects of the design that don’t work for them; for example, we have a page in the application with a lot of text boxes, and in order to save page scrolling, these text areas were designed to be three lines high. Therefore, if there are more than three lines of text in a box, scrolling that box becomes necessary. The users were accustomed to seeing all the text at once on paper, so they wanted the same thing on the screen.

The program manager told them that their feedback would be taken into consideration for enhancements in future releases. This made me ask myself when it’s better to enhance the product or simply explain the current state in the documentation. Where’s the line?

A coworker who used to be a technical writer once gave me a pin he received at a conference. The pin reads: “NO. You can’t just explain it in the manual.”

The point is that documentation shouldn’t have to make up for lack of design. However, there are probably some cases where adding some information to the documentation instead of changing the product makes more sense. Cost of doing one or the other is certainly an important consideration. The degree to which the enhancement would relieve user headaches is another.

Where only one of the two is needed, how do you make the determination whether to enhance the product in a certain way or instead add to the documentation?

When I met other technical communicators at the STC conference in June and told them that I work for the LDS Church, most were at least a little surprised. What does a church need technical writers for?

As I answer that question, bear in mind that we’re not classifying marketing writers as part of this (especially because we’re not selling anything). Our team is called the “user education” team, so our concern is teaching users.

But what are we teaching them to use?

Our Church’s headquarters includes an IT department, part of which exists to develop and maintain Web sites and applications. Church software is designed to provide resources for Church members to learn about the gospel of Jesus Christ and perform their ecclesiastical responsibilities. It also helps others learn about and understand the Church.

Some applications help workers at headquarters accomplish their day-to-day tasks, and other systems are used by people in their homes or church offices to perform certain ecclesiastical duties. The work they do with Church software is important to them not just because it’s part of something a leader or manager expects of them, but also because these tasks are immediately connected to their beliefs. They have the deepest kind of interest in the success of their work.

(more…)

Our interaction design group holds regular design reviews. In these meetings, they show each other what they’re coming up with for the projects they’re working on and give each other feedback. A designer will generally put his designs up for scrutiny before he gets very far in his designs so that the others can ask questions and suggest additional factors to consider.

This is a great practice for technical communicators. This field involves designing the way a user interacts with content. I may be designing electronic or print materials, but holding reviews with fellow technical communicators before I go far down a particular path could only improve my thinking and save me work later. As with most things, the more eyes you have to give perspective on something, the better of it will be. We plan on beginning this in our team pretty soon.

Today, I trained a small group of users on an application in expectation of next week’s release. I had printed a small booklet for them that gives instructions; though many tech buffs will argue that the printed manual is dead, there are those users who still ask for them.

Anyway, I had the booklets printed and bound in our in-house document printing center. I picked them up before the training so I would have them ready to hand out at the end of the training session. I’ve had the experience before when I opened a freshly printed manual that I had gone through with the finest toothed comb I had, only to see a problem as soon as I opened the book.

The problem this time wasn’t a typo or missing image; using InDesign, I had put a tan-to-white gradient behind chapter headings, and upon being printed, that gradient turned into a solid, quite devilish, red. (My wife asks, “How did you manage that?” I can only shrug.) The headings are still readable, but I sure was surprised at this outcome. The worst part is there is just about no red in my color scheme.

What surprises have you encountered with either electronic or print publishing?