Designing your binder structure: sections, subsections, and indexing

Forty-seven pages and no way to find anything

A monitor arrives at the site for a routine visit. The first request is straightforward: "May I see the investigator's current medical license?" The coordinator opens the regulatory binder, flips to the tab marked "Site Personnel," and finds 47 pages in no discernible order. Curricula vitae sit next to delegation log addenda. A GCP training certificate from 2019 is sandwiched between two photocopied medical licenses -- one current, one expired, neither labeled. The coordinator begins paging through, one sheet at a time.

Thirty seconds pass. A minute. The monitor waits.

This is not a story about a missing document. The license is in there, somewhere, buried under the accumulated weight of records filed with no organizing principle beyond "put it behind this tab." The problem is not that the binder lacks content. The problem is that the binder was designed -- if one can call it designed -- for storage, not for retrieval.

And that distinction, between designing for storage and designing for retrieval, is the single most important architectural principle this lesson teaches. A binder designed for storage answers one question: "Where do I put this?" A binder designed for retrieval answers a different, harder question: "Where will someone look for this -- including someone who has never seen this binder before?"

Every design decision in this lesson flows from that principle.

Forty-seven pages and no way to find anything

Thirty seconds pass. A minute. The monitor waits.

Every design decision in this lesson flows from that principle.

Forty-seven pages and no way to find anything

What you will learn

Designing your binder structure: sections, subsections, and indexing

Forty-seven pages and no way to find anything

What you will learn