The QA of Product Design

I bring this article to you courtesy of Gryphon Mountain Journals, as I think it adds enormous pertinence to what I do. You may view the original article here.

Technical Communication: The QA of Product Design

Friday, August 13th, 2010

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.


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.