What This Actually Is
A field guide for a graphic design template isn't a product you buy off the shelf. It's documentation that walks someone through how to use a template properly, when to deviate from it, and what breaks when they do. Most templates come with a style guide attached — colors, typography, grid measurements — but those are surface-level. The field guide is the thing that lives in your shared drives and gets referenced during reviews when someone asks why the CTA button isn't centered or why the heading uses a different weight than the rest of the page. Start with the template itself, not the other way around. Open the file, go component by component, and document every decision. If the header has a 120px top padding in the desktop version and 60px on mobile, write that down with the breakpoint. If the color palette includes a "primary" blue that you actually use in six slightly different shades across different states and hover conditions, list all six with their hex codes and explain when each one is appropriate. Beginners tend to skip the mundane stuff like line heights and kerning values because they assume those are "obvious." They aren't obvious to the next person who inherits the project six months later. I once had a situation where a template had three different card layouts that looked similar but weren't identical. The spacing between the image and the title varied by 4px depending on which layout was used. A new designer on the team defaulted to the wrong one on a client project, and the feedback round took two days just to correct inconsistent spacing. After that, I started including explicit layout variant tables in the field guide — not just screenshots, but actual spacing values for each element in each variant. Now the table has 14 rows for a single page template. It's tedious to maintain, but it prevents that kind of issue from recurring.
What Goes Inside
Component inventory. Every reusable element in the template should be listed with its naming convention, version number, and the file location where the master lives. If you're using Figma, this means listing the component name exactly as it appears in the library, not a colloquial description. If the component is called "Card/Featured/Image-Left/V2," write that, not "the fancy card with the image on the left." Modification rules. This is the part most people skip. Document what can and cannot be changed without breaking the design system. Can the font size be increased to 48px? Only if the line height is also adjusted to 1.15. Can the color be swapped? Only within the approved palette, and never on interactive elements without running a contrast check. These rules matter more than the visual specs themselves. Breakpoints and responsive behavior. List every breakpoint the template supports and describe what changes at each one. Not just "mobile and desktop" — the actual pixel values, and which components behave differently at each breakpoint. Some templates have a three-breakpoint system (mobile, tablet, desktop) but the field guide often lumps them together. Don't. The padding values shift between tablet and desktop in ways that aren't proportional, and calling it out explicitly saves someone from guessing.
Where It Breaks Down
Field guides become obsolete quickly if they aren't treated as living documents. I've seen teams write comprehensive guides that are three hundred pages long and then never touch them again after the initial handoff. Six months later, the template has been modified, renamed, or had components deprecated, and the field guide describes something that no longer exists. The workaround I use now is versioning the guide alongside the template. Every time the template major version bumps, the field guide gets an update log at the top noting what changed and why. It adds about twenty minutes of work per release cycle, but it keeps the documentation honest. There's also a limit to how much a field guide can replace actual understanding. If a designer doesn't know why a template uses a 60/40 visual weight split instead of 50/50, the field guide can explain the reasoning, but it can't make them instinctively apply that logic to a new context. Templates that are too rigid tend to produce work that looks uniform but feels lifeless. The best field guides I've written include a section called "When to Break the Rules" that describes acceptable deviations and the conditions under which they're justified. That section alone tends to get more reads than the rest of the document. The format matters less than the habit of maintaining it. I've used Google Docs, Notion pages, and plain Markdown files hosted on GitHub. They all work. What doesn't work is writing the guide once and assuming it will remain accurate. Treat it like code — review it, update it, and delete sections that no longer apply.
Get the Full Details
