Designing for your Audience

Today's xkcd (a fantastically geeky webcomic) is about designing for your audience ...

http://xkcd.com/773/

The parallels to technical writing are obvious :-) How can you know what to write if you don't know what information your audience is looking for?

Proof that UI Adds Value

At NI, technical writers often are the first non-developer users of a feature (API, dialog box, what-have-you). We are expected to notice UI issues and raise them with the developers.

The next time you defer or reject a minor UI change, consider these examples of how UI can impact your revenue:

• The $80-million-dollar color
• The $300-million-dollar button

The Rubber Duckie Test

Okay, this sounds kind of odd, but hear me out. A developer friend recently told me about the "rubber duckie" method of coding. In a nutshell, you as a software engineer place a generic rubber duckie on your desk. Every time you make a big coding decision or implementation, you explain how it all works to the rubber duckie. If you find yourself straining for an explanation, or if you find yourself unable to even come up with something logical, stop. The duckie has served its purpose -- it's helped you expose a bug or design flaw or implementation flaw that otherwise might have gone unnoticed (until later when the build breaks and it's your fault, or a customer's app crashes and you lose a $2k sale).

This is why technical writers are valuable. We are living, breathing rubber duckies, forcing you to explain your code and decisions (so that we can explain them to users) and thereby helping you uncover errors, inconsistencies, or inefficiencies in your design. And also, because we're human beings, it doesn't look like you're trying to hold a conversation with a squeaky toy.