April 28, 2018 No Comments

How Much is Lost Productivity Costing You?

Usability and User Experience (UX) are hot topics in the product development sector right now. The concept is that if you improve design, workflow, and other user-facing aspects of your product, leading to a better user experience, you will increase customer satisfaction, customer loyalty, and predictably, revenue.

This is something technical communicators have understood and been working on for along time. When customers buy more products, because their user experience is consistently good with products from that source, companies understand the health that brings to their bottom line. However, there is hidden value in improving product usability (how the product enables users to complete their tasks): productivity.

When workers slow down, have to troubleshoot, have to call user support, can’t figure out how to complete their task, and need to consult documentation, they are losing productivity. When it takes multiple people to solve a software- or process-induced problem, that is productive time stolen from the business. If you think of a ballpark $100 per hour (wages, benefits, overhead, etc.) per employee, delays start to add up quickly.

Poor products and processes can cost businesses tens or hundreds of thousands of dollars a year. The more a system is mission critical for your business, any downtime — whether technical or user-based — is very costly indeed.

To paraphrase Peter Drucker: If you think good usability is expensive, try lost productivity.

April 28, 2018 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: Business, College, Communication, Design, TechComm

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…)