Prototyping is a powerful tool in any development process, and making a book is no different. I’ve seen quite a few books lately, however, that don’t look like they’ve been prototyped, so here’s a primer.

A prototype is a category of simulation. Now everyone simulates all the time — it’s part of how being sapient works. When you wonder about how to solve a problem, you simulate the problem and the solution in your head and, presuming your simulation is adequate, you find out whether your idea is stupid before actually implementing it. In hardware design we do a lot of simulating too — we can’t afford to actually run trains around the office in the early stages of testing and development, so we have train simulations that supply identical inputs to the controlling software.

Simulations have limitations that need to be thought about very carefully (and there is a relationship to game design here that I won’t explore further in this article but you might want to file away for your own use later, because all games are also simulations). The first is, obviously, whether the simulation is correct — whether you are getting your math and logic right. This is also not something I want to explore because that’s part of testing the simulator. The two critical elements of the simulation that you need to think deeply about are the granularity and the scope.

The granularity of a simulation is the minimum unit on each metric that you will care about. You cannot simulate continuous time or continuous distance, so instead you chop your simulation up into, say, 1 second intervals and centimeter segments. This is your granularity. Because you decided it carefully, you  know that it is a strict limitation on the functionality of your simulation by design — you know that if you measure an event that takes 1.7 seconds, that you only know it’s around 2 seconds. And you know that if you need to know what happens in a half-second interval, then your 1 second granularity is broken.

The scope of the simulation is the range of values over which it will operate. This has direct bearing on game systems because we don’t often thibnk about it very hard and assume, consequently, that the scope is infinite. It isn’t. All simulations have limited scope and it’s better to design it than discover it. So a simulation that is designed to consider weather events over a six hour period has nothing whatsoever to say about month-long weather cycles. A simulation that considers only wind speed and humidity has nothing to say about suspended particles. Not “little” or “weak” information, but none.

Okay so prototypes. A prototype is a physical model of your end product. Its objective is to broaden both scope and granularity past the point that intellectual or software simulation can achieve by using the real (continuous — baring quantum limits) world for some parameters. So when you want to see if your new electric shaver design is comfortable to hold, you could simulate holding it in a computer, or you could build a little plastic one and weight it so that it’s the same as the real thing would be and then, well, hold it. Your scope is still limited (it doesn’t shave anything) but within the scope you intend, you have nearly perfect granularity.

Okay so books. When you are laying out a book in software, you are working with a book simulator. It has intrinsic scope and granularity choices and you did not make them. Consequently you may not be entirely clear on what they are. For example, you cannot see the whitespace effect of your margins, because your artboard is usually laid down on a white background (change request for Adobe — please make the unused portion of my artboard black or something). You cannot see how your fonts will work because your screen is only a hundred dpi or less and your paper is between three- and fifteen-hundred. You cannot see how your artwork’s colour will look on the shelf because your screen has a different colour gamut than print (there are colours you cannot display that you can print and vice versa) and because your screen has different refelctivity and diffusion characteristics than your paper (and you will choose between a wide range of papers).

When you understand the limitations of your simulation, you begin to understand first that you must have a prototype relatively early in the production and that you now know roughly what its scope is.

So, when you are making a book, while you are still playing with layout ideas, make prototypes. Here’s what I do. I print a half-dozen or so spreads (left and right pages) at full size so that the output art and type are exactly the size they will be in print. I then trim the paper to my actual paper size (printing with registration and crop markings will help you get this as right as you can) — there is zero value in printing 6×9 pages zoomed up to your letter size paper, or real size in the middle of the whitespace of a too large page.

Then I assemble a mini-book by stapling or otherwise fixing these pages together. My printer doesn’t print on both sides, so I glue odd pages to their even back face. Now you can detect things that will have escaped you before. You are not done, though — you need to use the prototype properly. So sit down and read your book. Don’t skim it. Read it. Come on, it’s only twelve pages and it’s your job.

Does your printed line slide into the gutter in an aggravating way? This will now be brutally obvious. Are your margins too thin? Are the lines too long? Is the font too large or too small? Is the page colour good? Do those callouts or sidebars invite or obstruct? Is that too many fonts maybe (chaotic page colour)? Is that really the green you want there? Does this ampersand really work with full-height caps in the context of the page it’s on? Are the headings distinguishing their associated text from the rest of the page? Can you even see black print on that grey? Is that even a number there with all that fooferah — it looks awfully foggy now.

Does the spread look good? Is a blank page or a full page illustration maybe better on the left to balance the chapter heading whitsepace? Does the eye move across the spread the way you want? Is turning the page to continue reading annoying in this particular context, inviting re-flowing to keep stuff in one spread?

The earlier you do this the better you’ll unerstand what you’re making. Waiting until you get your test copy back from the printer is hundreds of man-hours too bloody late — you will now be under pressure to live with your errors because you’re so far along. So do not wait. Prototype now and prototype often.

–BMurray