Product impact ... affecting the bottom line

by Mike Bates (Northeast Ohio Chapter) mike.bates@software.rockwell.com

We are waiting to get the manuals back from the press before we can ship the product."

"I need you to look at the screens, determine what I've added and deleted in the system, and make as many changes as you can by the end of the day. We'll ship whatever you've got. We can add the rest later."

"I know you'd like to make this a complete help system. Unfortunately, there is not enough time. Maybe we can get it into the next release."

That old story again
How many times have you heard those words before? Obviously, it is in any company's best interest to deliver a product to market before the competitor. However, once the product hits the market, how long does it take before users cannot find what they are looking for and rely on picking up the phone to call customer support? Could those questions have been answered if you had more influence on the product's development? The real question is ... how do I, the help developer, convince the product team that I can have an impact during product development and still deliver on time?

What many members of our product teams fail to realize is that we are now able to deliver information about as fast as developers can lay down the code. Through the use of database publishing techniques, we are able to reuse many information components and create new ones while the developer is debugging the code. By writing modular information components, we have removed some of the burden from the product team by asking them to review definitions for twenty screen elements instead of dropping a 360-page user's guide on their desk and demanding comments within five days.

No time for design?
Many software developers will tell you that they don't have enough time to write a design document. The general feeling is "let's just lay down the code, make sure it compiles, and get it to market." Obviously, it would be great for us if we were always handed a design document that included all of the software's functionality and a copy of the screens as they will appear in the final product. Most of us know that this doesn't always (ever?) happen.

Technical communicators, however, can look at the prototype screens, identify the tasks users can complete, make a list of the screen elements, and begin to list the related topics users might need in order to complete a task. This is our design document. By working with the development staff, we can then fill in the gaps (button and text box descriptions, task definitions, and reference topic text) to form a working design document for the software. The software developers now have a document they can use as a reference when building code.

Let's take this a step further. We are writing help on a task-by-task basis. We should be able to reuse the procedural information outside the help system. For example, each task can be developed into a well-designed storyboard the developers can post on a whiteboard to ensure the system is coming together as planned. By using your tasks as storyboards, you may hear things like, "Hey, you shouldn't be able to do that on this screen." This is also an excellent way to review the outline of your help system in the early stages of system development and affect the software's architecture.

And then there's usability testing. Most usability evaluations involve a domain expert (lead software developer) and test administrator (usability specialist). The domain expert is tasked with creating scenarios that undergo several revisions at the request of the test administrator. The tasks you have finalized are excellent scenarios for an evaluation. The tasks have already been reviewed by the development team during the initial design when you created storyboards. You have just eliminated one week from the development cycle and helped the product move into the usability lab that much faster.

We do affect the bottom line
As help developers, we are no longer just putting text on a page. We are developing reusable, modular, information components. No, we probably aren't going to get all of the credit for that application that saturated the market one week before the competition and quieted the phones in customer service. We can, however, show the product team that we eliminated many potential problems by reviewing the storyboards and defining the software's interoperability in the initial design phase. In addition, you can instantly assign a resource number to the number of hours saved to show how you saved the company both time and money.