Getting it right, avoiding unpleasant surprises, and ensuring consistency: these are some of my motivations in pursuing precision. Whether I'm developing an infographic that is accurate and clear, or knowing the difference between "its" and "it's" and their proper use, or going through the variety of checks involved to properly set up a document for process-color printing, it's fair to say that I am inclined to bring an engineer's approach to the nuts and bolts of graphic design production. I do love whimsy and spontaneity, but I also know there's no substitute for due diligence that can prevent a disappointed client or costly printing errors.

The goal of precision is a big factor in my strong preference for using styles, whether it's paragraph and character styles in InDesign and QuarkXPress, or layer styles in Photoshop, or CSS in XHTML. Styles pay big dividends in areas like avoiding random formatting irregularities, some that can be difficult to detect until a piece is printed, not to mention other benefits in speed and flexibility. CSS layout also makes code far more compact and intelligible than table-based HTML layout.

As suggested above, I'm interested in precision in language, such that my language skills are substantially better in my experience than that of most of my design colleagues. My vocabulary is quite good, and I can often catch malapropisms and other improper word usage. I can spell well, and while we all have spellcheckers, they won't catch other types of typos that I watch for. These skills are not typically expected of designers, but they allow me to help you in this way as well to present a competent and professional face to the world in your published speech.

I am interested in documents that are well-built "under the hood" as well as in their visible design and typography. I've encountered many a print piece that was a mess in its internals, leading to unpredictable performance when press time approaches and random difficulties and inefficiencies when changes were needed. Sometimes it's faster to virtually rebuild the whole thing than to try to sort out the kind of spaghetti pile that tends to get built by someone who doesn't have a good grasp of how their software is designed to work. Build it right, and you may only have to build it once. That's a key to precision, performance, and profit, especially over the longer term.