As I have undertaken increasingly complex projects, I have developed some responses to the problem of huge requirements documents.

The problem is that on a large project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it's very [linear] nature makes it... well, boring! Even developers and designers are human!

They put it on my desk and the earth moved.

The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose propping up a lamp and no one ever reads it. These books typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.

What can prevent this? With all our focus on personas, and the scenarios we construct to walk them through, it is easy to forget that the person who received 150 pages of your careful work is basically just going to look at the pictures.



Take a moment and review that the order of the parts feels obvious. No one except the people who proof it for typos are going to read it in a linear way - most people will open it and refer to a couple of pages. That means that you have to show where ideas came from, how they connect and who they are important to all on the same page. This ends up being a lot of text, so there must be a clear page level hierarchy.

Make sure that the document structure is clear and accessible. This means a contents page with content areas providing immediately understandable names.

Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.

Also, keep to the point in the main document and bury extraneous detail in appendices. This keeps the main series of ideas clear, without doing that brick-to-forehead thing so many technical writers have such a talent for.

Your mindset delivering the document is not how it will be read

It is good to remember that people do not always have the luxury of working on a project in a continuous manner. Imagine this all too common scenario: you start a project, then market conditions or some set of variables change and you are redirected to other tasks. The first task did not go away, nor did the strategic benefit that the company intended to reap by funding it in the first place. Months later you return to the first task having forgotten the details in a blur of other work. Concise, well-organized documentation will be worth time & money.

Visualization is usually roughly equivalent to comprehension. I find that annotated pictures are far more specific & engaging than trying to describe things that can be easily shown.

These visualizations do not need to be elaborate. Humans are experts at understanding abstracted representations - look at the drawing language of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.



In sum, showing what you intend is powerful, yet doesn't need to be elaborate in production. Time is easily wasted creating elaborate documentation that is too soon out of date; minimal documentation should be your goal.