Journals by RSS
Journals by Email
I wonder if there’s a tech writer out there—in the software industry, anyway—who would argue that being involved in the design stages of a project is a bad thing.
This theme comes up time and again among our User Education team members. Yesterday, one of us gave a presentation to our community of practice about usable design, what makes something usable, and how tech writers can contribute. She suggested we come up with some metrics that help us demonstrate how our contribution to usable design increases user productivity and lowers cost.
As part of her illustration, she showed a chart about the more and more expensive it gets to fix a bug from the requirements stage through to the maintenance stage.
An idea came to mind, and I shared it with the team, that one of the things that we can use some hard numbers with is determining how many steps it takes to complete a task. The presenter had used an example to show how a process that she would have expected to take four steps instead took twelve. If we can analyze designs and determine how many steps it takes to complete associated tasks, we can tell the project team, “That’s going to be hard to explain. That process will take ten steps (or fourteen, or twenty). And when a user sees a procedure with that many steps, the first thought is ‘This is going to be hard,’ probably followed up with ‘I hope I do it right.’ Confidence goes into a nosedive.”
The second part of the idea is that to give ourselves more clout, we ought to get the project manager’s support at the beginning. We can explain how expensive it gets to fix usability problems later and how we can help catch those problems early on because we think in terms of “how do I do this?” By virtue of our job, we quickly learn how complicated a task is going to be. Once we get the manager’s buy-in, he or she can back us up if the team hedges when we point out that a design involves overly complicated steps.
Metrics are a tech writer holy grail. How do we show return on investment? How do we show that we reduce support costs that would otherwise outweigh the money our services cost—especially when we’re working on a new project that has no support history? In the case of usability, how do we numerically increase the usability of the product?
So procedure length is one way to quantify the usability of a feature or product. What other ways can we quantify our contribution to usability?
Image credit: Image: Master isolated images / FreeDigitalPhotos.net
Related posts (auto-generated):
Ben Reply:
October 10th, 2011 at 1:21 pm
My concern with the first approach you’ve mentioned is that it’s a post-launch process. But I wonder if that’s a model that would work better in some ways. Many tech writers don’t agree on what “good enough” is, and it can be hard to pin down before people start using the product. But we want people to have the documentation they need at the time of launch. I wonder if project teams, especially product managers, would agree to mediocre or limited documentation at the time of launch with the understanding that it will get better based on feedback and analytics.
Once you have your standards for writer time, how will you calculate money saved or earned by the company? How will you tie those things directly to documentation?
[Reply]