December 13, 2017 No Comments

Failure to Fix Causes Stress

In tech comm, we often talk about “customer support liabilities”, i.e., product issues that make a customer call for support (which is expensive for the company). Task-oriented design, usability, and good user testing can prevent these costly flaws in a product. In addition to the expense of paying for technical support, there is lost productivity and greater user frustration which companies frequently don’t figure into their analysis of their bottom line. Here’s an example of a fixable issue that causes people a LOT of problems.

A large western college has an online testing system that only works in Internet Explorer. (That’s problem #1.) The only correct way to exit the testing system is to click the small Logout link in the upper right corner. If you close your browser, exit using the X in the corner, your computer crashes, you close your laptop, or exit the system in any way other than with the Logout link, the system _locks you out for a minimum of two hours_. This also happens if there is another login to the testing system on your account from a different machine.

Supposedly, this is a security “feature”, but in reality, it is a huge problem for the users. Students being who they are, they leave their test to the last minute, and then, stressed and anxious to finish, they can easily become locked out.

In the student materials there is a note about the flaw in the system, but it’s easy to miss or forget. You can imagine the problems this design flaw — because flaw is what it is — causes for students, faculty, and customer support.

Does it take money to fix this? Of course it does. But that cost is far less than the overt and hidden costs of it working the way it does. In this case, they have downloaded the liability onto the students, who are least able to deal with such a problem.

Filed under: College, Customers, Design, TechComm, Usability

Tags:

January 20, 2012 No Comments

The Professional Gadfly

I often tell my students that as technical communicators, we are professional gadflies. It is our job to buzz persistently, and bite when necessary, to get certain things done. We cannot move forward with documentation on a product that is languishing, so we interact with the developers to see how things are going. We ask for prototypes and working versions. We query them about deadlines, especially “When’s code freeze?”.

We often become de facto project managers on the projects to which we’re assigned. In managing our documentation projects, we encourage, inspire, assist, and even require others to meet their production and development deadlines so we can take that deliverable and add its information to our documentation. Another rule of our craft is that a product never, never, never is delayed for release because of documentation. When that product is ready to go, so is the documentation, and often it’s that the docs are done and just waiting on the final touches to the product. (Cleanup, not changes.)  (more…)