Writing for Software vs. Writing for Hardware

Software and Hardware are different worlds – for the user as well as for the Technical Writer. A different outlook is required for Software Technical Writers to scale up and write a Hardware manual.

User Interface vs. Physical components When it comes to Software, we always think in terms of a ‘User Interface’. Most of our effort estimation models are ‘screen based’. When it comes to hardware, however, it is impossible to perceive a world which cannot be counted in terms of user interface. How do we estimate? How do we gather inputs?

There are many tasks performed by the user in the hardware world. For example, assembling the product, installation, and servicing. And these tasks are what helps estimate the effort and gather inputs for our manuals. To get a better idea of how to structure your document, go to the hardware lab and request the manager to show you a dissembled piece of the product. Go through the assembly and installation process. Ensure to use a Task-based estimation model for estimating the effort required to write the manual.

While studying the system, be extremely careful about touching or moving the components of the particular product. You might require a briefing from an engineer before you handle the components yourself. This might be a frustrating experience at first, but the training will go a long way to help understand the hardware components and how to handle them.

Conventional Terminologies vs. Industry Standards In the software world, we use terminologies like screen, field, checkbox, task bar, and menu. But, in the hardware world, many terminologies are used which are very different. For example, you might use names of connectors, wire, boards, semiconductor, or FPGA etc. Each of these components has a specific nomenclature as per industry standards. For example, a connector might be an RJ-11, RJ-12 or RJ-10. A wire might be a 9AWG or 23AWG (American Wire Gauge).

Put in a good amount of research to understand the terminologies for your hardware domain. This will help you phrase the right questions for the engineer.

While writing software manuals, we are satisfied when the engineer says that an object on the application is a ‘Screen’ or a ‘Menu’. Mainly because we know what the engineer is referring to. We also know that both the developer and the writer refer to a ‘Field’ in the same manner. We understand it when the software developer says ‘Hey, the order number field is numeric’. The consequences of replacing the description of a numeric field with an alphanumeric description might not be catastrophic.

Whereas, in the hardware manual, replacing a 9AWG wire with a 23AWG wire might lead to your product going up in smoke! A wire has many characteristics such as AWG, Voltage, Flame Rating and UL Rating. Be particular when it comes to specifying names of your hardware components and their type.

Screenshots vs. Illustrations Obtaining screenshots for your software manual is easy – press the Print-Screen button and you have the screenshot for your product. You can further edit your illustration using various tools.

For Hardware manuals, you need to use complex engineering drawings generated in CAD. You may not always be trained to create such complex drawings. In such a scenario, contact your product designer to use the illustrations created at the product design stage. Illustrations from ProE or AUTOCAD can be exported to Adobe Illustrator format. Adobe Illustrator files (with extension .ai) can be imported or inserted in the hardware manual using FrameMaker.

These illustrations are extremely difficult to create if you have not been trained in CAD. However, you can easily manipulate these illustrations in Adobe Illustrator. For example, you can add captions and change the size of the illustration using Adobe Illustrator with little or no training.

CMM vs. UL Software projects go through CMM certification to ensure that they have a high level of predictability. But some of the software products and projects are delivered to the users without CMM certification. Consequently, the product documentation also goes to the users without the CMM certification.

Hardware products have to be evaluated by Underwriters Laboratories. Unlike CMM, this evaluation is mandatory. Products are evaluated in terms of their reliability and safety. Electromagnetic radiation, exposure to laser and proper grounding are some of the factors considered for evaluation.

Hardware manuals have to carry the appropriate Restriction of Harzardous Substances statements (RoHS). Many substances like batteries, semiconductors, and other hardware materials are hazardous to living beings and hence proper RoHS statements have to be added to the hardware manuals.

Not adding statements for certification or improper RoHS statements might lead to disastrous consequences. First, the product might not pass the UL certification leading to additional expenses for the company. Second, and the most critical consequence, will be that the user might not take proper safety measures and might be injured while using the product. This situation usually leads to a lawsuit. And if document does not have proper safety statements, the company has to pay millions of dollars towards settlement of the lawsuit. Not to mention the damage that such a lawsuit will cause to the company’s reputation.

Work closely with your certification and legal department to ensure that your document is compliant with all certification and has the adequate statements.

Advertisement

2 thoughts on “Writing for Software vs. Writing for Hardware

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s