A Page Pattern is a framework of placeholder text, markers, and other objects that - when applied - enable the designer to easily place artwork (e.g., wireframes) and annotate (e.g., content specs) into a consistently structured deliverable page.

As I demo custom documentation systems that we build at EightShapes, I often implore attendees to think about architecting their documentation as they architect the digital experiences they design. Goals emerge like reuse, simplification, clarity, audience focus, and patterns.

Recent analysis and discussions with a range of clients has led me to begin creating a new aspect of these documentation systems: page patterns. Our systems mostly result in paginated PDF deliverables. Through analysis of 100s of sample deliverables, I’ve realized two things: (1) there’s no one-size-fits-all page from which you start to document design, and (2) there is a clear set of prioritized patterns to those pages that emerge.

“But I’ve been doing this for years, it’s called master pages/backgrounds!” Not so much. I’ve not encountered any documentation systems built organically that include more than 2 or 3 master pages as starting points. And usually there’s just one starting point for wireframes.Instead, I assert that you communicate your design in a range of contexts.

For example, I’ve presented wireframes like:

• Wireframe only
• Wireframe with strategic goals
• Wireframe with content specs
• Wireframe with high-level chunked areas
• Wireframe with behavior specs
• Wireframe alongside “inspired by” screenshot and criteria
• Wireframe variations (2 or 3 side by side)
• Wireframe with editorial guidelines
• Wireframe with “pattern” attributes (use when, rationale, description, etc)

Similarly, there are numerous context for other design illustrations, like components (parts of a page), flows, maps, stories, strategy, research, interviews, usability testing reports, basic project planning, document metadata (change history, distribution list, TOC, etc).

Each of these contexts serves a different purpose, often for a subset of audiences to whom you communicate design. Therefore, our documentation systems have begun to include a wide range of page patterns as starting points for each given page. I’d estimate that a mature set will include 40-50 patterns per system we deliver, even if they are moderately customized based on client needs.

Why Not Backgrounds?

Such patterns are explicitly NOT master pages/backgrounds, but instead snippets that can be easily added to a new page as needed. This helps (a) keep template files light and (b) maintain, grow, and distribute new patterns with minimal collateral impact to system usage.

The gains in efficiency are enormous, as system users have immediately responded with excitement and declarations of saved time and “I don’t have to think about documentation as much - I just think about my design and know how to communicate it effectively!”