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.

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