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.’”

I’ll run that by you again:

Saying “If the interaction designer does his job right, the product doesn’t need documentation” is like saying “If the developer does his job right, the product doesn’t need quality assurance.”

Not many project managers would argue the value of QA. So why should they argue the value of technical communication?

If you boil this designer’s statement down to its basic premise, you get “The technical writer provides quality assurance for the interaction designer.”

When you think about it this way, you’ll start to get a sense of why tech comm ought to have a place in every project meeting from the design phase all the way through to the end—why we ought to be sitting at the table with the other project leads.

You Provide Quality Assurance Too

Let’s take a look at what quality assurance is all about. At least in the software development world, quality assurance engineers, more simply known as testers, exercise the software once coded to make sure it meets functional requirements. Clicking a button or link brings about an expected result. Inputting certain data returns certain other data or provides specific options. The idea of all of this is to make sure that someone using the product accomplishes certain predefined objectives.

If you’re fortunate, you work in a company that places usability testing among its priorities. In the Agile environment I work in, we don’t have much time between design and development to conduct usability testing. Any testing we could do would have to be early, probably with paper prototypes and grabbing some person at home to try them out. Usability testing, as the name suggests, tests the design.

Either way, the tech writer tests the design. We do this by making sure, as we provide documentation and training materials, that the user can accomplish predefined objectives using the design that’s provided. Yes, we may log some bugs along the way. Yes, we want the product to actually work and not return errors. But what we’re mainly concerned with is how to navigate the product’s visual elements to accomplish a task.

As we document steps, we can see when terminology doesn’t make sense or when a control is hard to locate. We can see when a task takes too many steps, includes steps with too many substeps, or has an inordinate amount of permutations of the same step. We can see inconsistencies in different parts of the product. We are the first users.

People are people, and we like simple. Some business processes or other procedures are complicated, and we may not be able to do anything about that. But we can help make sure that the products that support those procedures are as simple as possible.

Wrap-Up

Quality isn’t found solely in working code. Quality is found mainly in the experience. Technical communicators are immersed in the experience of a product because we have to understand it. We have to see it as the user sees it. As a result, we can provide quality assurance for product designs beginning in the early stages of design and development.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. A Writer's Exercise for Critiquing Design
2. An Interaction Designer Who Understands the Need for Documentation
3. Four More Reasons Your Company Needs Technical Communicators
4. Problem-Centered Design for Documentation
5. Where Usability and Documentation Meet

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.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Usability and Maintainability: Understandable Information
2. Visualization Can Improve Writing
3. Consistency Leads to Trust in Information Sources
4. Clear, Common Language Leads to User Success
5. First Principles of Technical Writing

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.

I: Let the Presenter Just Present

In WebEx, the host or leader of the meeting is by default also the presenter, but he can give the presenter role to someone else. (The host role can also be passed around.) The leader of the meeting, or the individual whose account is being used to run the meeting, has the ability to vary the privileges of the attendees, such as whether each can take notes in the Notes panel or send private chat messages to other attendees. With an integrated audio conference, the leader can also mute attendees’ phones to reduce background noise and echoes and then unmute them when they have questions or comments.

We discovered that all of this was difficult for one person to juggle. We began having someone other than the presenter run the meeting and act as host. It has made presenting much easier when all I have to think about is giving the information. I don’t have to worry about whose phone is muted or try to assign privileges as each person joins the meeting.

II: Provide Multiple Voices

No, I’m not talking about trying out your celebrity or Looney Tunes impersonations. The host can take a minor part in interacting with the attendees by doing some or all of the following:

• Welcoming each attendee.
• Asking for introductions once the meeting has started.
• Introducing the subject matter and the presenter.

Again, this helps the presenter focus on her responsibility to teach and train rather than having to switch gears and go from greeter to presenter.

In one of our sessions, the host greeted the attendees, and the product manager for the project, with whom the attendees were a little more familiar, gave a welcome and introduction once we started the meeting. He gave a good explanation of the purpose of the training and our expectations.

Multiple voices help keep the attendees’ attention engaged because they don’t have to listen to the same person for an hour. If two people can smoothly co-present, that will add interest.

III: Have SMEs on Hand to Field Questions

Remember that you may be providing training as a technical communicator because you’re one of the people who understand the application as a whole, but that doesn’t mean you can’t have a test lead or business analyst in the meeting to help answer questions that the attendees will have (because they will have questions).

Best is to have a stakeholder or customer along for the ride as well, because he can answer those business and policy questions that the end users may have about their everyday use of the product.

Sharing the load when it comes to running Web conferences has increased our effectiveness as we have provided training. One of the benefits of Web meetings is that you don’t have to have your leader or host, the presenter, and SMEs in the same room. While it helps, so that you can respond quickly to technical difficulties or other problems, the fact that they can instead join from their offices or homes adds to the convenience of this method of conferencing.

In case you’re wondering how we solved the problem mentioned in the first paragraph about the restricted callers, our quick-thinking test lead called the audio conference from a desk phone, then conference-called the restricted caller. Another reason to have backup.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Training by Web Conference: The Saga Continues…