Designer vs. Programmer

Many newcomers to HotDocs and document generation have a solid grounding in producing documents in more traditional ways. They often understand issues like layout, style consistency, margins, headers/footers and pagination. It’s essentially an art: how do I present this text in the most pleasing/consistent/clearly branded/professional/etc. manner? Document specialists—sometimes authors, sometimes knowledge owners, often both—generally approach their documents (once one gets past the content of the text itself) from the point of visual design. And that is entirely as it should be.

However, automating the generation of documents is a trickier business. The core of automation is the rigid definition of rules and the application of those rules without human intervention. This necessitates a very ordered, logical, by-the-numbers approach. Programmers use this approach all the time and often train themselves to do it unconsciously. It is a mode of thinking that seems a million miles from the subjective, “I know what I like and that looks awful,” approach used by many document specialists.

The truth is that automated document templates require the eye of a designer and the brain of a programmer. The programmer must look at a document and clearly delineate areas which must change and then set up the strict rules under which that change is applied, but the designer must be attuned to how those changes will alter the layout or formatting of the document and adjust to create a final product that functions logically, but also meets that documents design needs.

(I don’t want to say, “also looks good,” because many documents don’t need to look good if they do other jobs. But seriously, the document should also look good.)

I find that many of the people who I train to use HotDocs get anxious about the aspects that feel like programming. To them, computers are still somewhat mysterious and occult, and anything that falls outside their comfort zone feels like having to land a commercial jet when the pilot has come down with food poisoning. It’s nothing to panic about, though. All it entails is building the habit of thinking about your documents in structural terms, as well as aesthetic.

Ask yourself, “If I was to remove this text, how would my document look?” Experiment. Add and remove text from your HotDocs template and get a feel for how those changes make the document behave. In no time, you will start to see the “moves” of the template and be able to predict exactly how your final document will shift, how it will expand and contract, how it willbreatheas new data is fed into its rules. Anyone, with a bit of practice, can be a designer AND a programmer.

And that is entirely as it should be.