Forever HIPO
/My middle initial is L and L stands for Loyalty. I kept making soda water with a Sypholux for as long as I could, I will continue watching Seinfeld reruns until they’re finally off the air, and I still believe in the unfashionable old HIPO design philosophy. How old? Nineteen seventies. How unfashionable? It doesn’t even have an article in Wikipedia; not in English, anyway.
HIPO was an IBM methodology for software design, but I think it also applies to technical writing, childrearing, peace in the Middle East, advertising, and probably motorcycle maintenance as well. Basically everything.
HIPO stands for Hierarchy of Input–Process–Output. The idea is that before you set about doing something, you should know what you’re starting with, what you’re planning to do to it, and what you expect to wind up with at the end. And that pattern of input, process, and output is hierarchical. For example, it applies both to writing a user guide and to every meeting that you hold as you research that user guide. You arrive with certain information and expectations, and a certain process produces a certain refinement of the information and expectations.
The output of one process often serves as input for another process. You may think of your manual as output, but down the line your manual becomes input for a process of instruction — along with the reader (knowledgeable? ignorant? reluctant? it's up to you to know) and the product (actual, not ideal) — where the major output, if your work succeeds, is a properly informed reader.
By imposing a HIPO view on a task, you can minimize misunderstandings in advance. Write a user guide? All right, but what is the input? Where is the information coming from, and how stable is it? What are the style guidelines? How many work hours are available? How much hands-on time with the product?
What is the expected output? What would be considered too short, or too long? Too sketchy, or too detailed? What about the quantity and quality of artwork? What level of expertise is the document supposed to instill in the reader? Should the guide be friendly and reassuring, or strictly informative?
You may find a mismatch between the input and the output. For example, you may be expected to produce realistic-looking screen captures without having a source for realistic data. Or you may be expected to summarize a hundred complicated commands on a pocket-sized card.
But once the concept of the input is clear and reasonable, and the concept of the output is clear and reasonable, what remains is to plan a process — or a hierarchy of processes, each with its input and interim output — that turns the former into the latter. Such a process may look possible under the anticipated constraints of time and resources, or it may not. If the process can’t turn the input into the output, then something needs to be redefined, and it may be any of the three.
The boss who says simply “write a user guide” isn’t ignorant of all the factors. But what isn’t spelled out is assumed, and by making assumptions explicit in a HIPO framework, you can more easily tell if they are reasonable and appropriate.
Just don’t call it HIPO to the boss. From a youngster you’ll get a blank look, and from an oldster you’ll get a stare as if you’d asked which room has the keypunch machine.
Questions and comments are welcome: ]]
