In our ongoing department reorganization, we technical writers are experiencing some angst as we carve out a desirable place for ourselves. However, as we’ve talked about it as a community of practice (no longer as an organized team with our own manager), I think we’re coming to an agreement that now is the time to make things happen—to strike, as Tom likes to say.

After the initial, high-level reorganization, Tom and I are in the same division, so we’ve discussed a plan for taking a more prominent place in project managers’ and interaction designers’ consciousness. This is the key for us because the PMs are the ones to include us in their project plans and budgets, and we would be working with designers to decide on user education approaches and contribute to the design itself.

Finding Tech Comm’s Place in the Family

After Tom’s blog post about our meeting with an interaction design manager, I asked him about his point of view and his readers’ reactions to the post. We discussed getting involved in projects early and contributing to user interface text. We talked more about this in our community meeting this week. Again, we’re looking to make sure that the people who make the decisions give us a rightful place at the table.

We also talked about many designers’ “holy grail” of creating products so intuitive that no documentation is needed. Tom reminded me and then the group of an important point I had forgotten. An interaction designer once said something like this to me, and I had passed it on to the team: “Saying that ‘if the interaction designer does his job right, the product doesn’t need help’ is like saying ‘if the developer does his job right, the product doesn’t need QA.’”

› Continue reading…

If you’re a technical communicator who’s involved in a software development project from its early stages—the way I think it should be—then you may have some input on error messages and other system feedback that users see in the interface. I spent some time last week editing about 1000 messages for another project, and in doing so I came up with a few guidelines for writing them:

1. Give enough information for the user to know what to do next.
2. Use terms that the user understands.
3. Don’t skimp on words. It’s more important that the message be clear than for it to save space. This even includes articles and related adjectives, like “a,” “the,” and “this.”
4. Be consistent with wording and structure. Don’t say “Employee ID can’t be blank” in one place and “The effective date is required” somewhere else.

Or, Training by Web Conference: Episode 3

Refining our Web training sessions at work has been a challenging experience. We have had to work with some international callers whose local phone companies won’t let them dial any United States area code but 801, so calling our audio conference bridge was out of the question.

In addition, we are using WebEx conferencing software. Trying to juggle its functionality while demonstrating an application takes practiced skill.

Here are three suggestions for teaming up to make your training by Web conference more manageable.

› Continue reading…