TC Myths

All technical communication myths in place.

Good documentation can fix a bad interface or design

Documentation can be created or added at the end of a product development cycle to fix or accommodate any shortcomings of a product’s design or implementation.

Background

Hart (Ten Technical Communication Myths) does not cite any research or provide any case studies or other emperical research that supports or refutes this myth. It does, however, seem reasonable to believe that a difficult interface will still be difficult to use with documentation. Somewhat less so with the help of documentation, but difficult nonetheless.

Survival tips

Hart cites Carliner (1998) who suggests that technical writers insert themselves earlier in the design process, while acknowledging that can go against the corporate culture.

If you’re a writer who ends up in the unenviable position of documenting a product with a less-than-perfect design, start by empathizing with your reader/customer/user and working back to identify the gaps and challenges and provide guidance around and through them. Your reader will appreciate the effort (even if no one else does).

Commentary

This is to technical writing as “We’ll fix it in post” is to filmmaking. In practice, the flaws in a design (script, blueprint, etc.) tend to get worse over time rather than get better.

Mentions

References