Building a Reusable Template Library: Structure, Naming, Components and Maintenance

Your team shares a Figma file with 15 business card layouts, each slightly varied, because nobody can find the one that is current. The InDesign folder for the quarterly report contains three versions: two with embedded fonts and one where all text reflowed because a missing font substituted. This is the moment a template library becomes a duplicate graveyard, not a productivity asset.

The fix is a reusable design template library that enforces a single source of truth through locked styles, named tokens, and a governance rule that makes duplication harder than reuse. Lacking this, a team of three produces more variants than pages, and every designer spends the first hour of a job checking which file is real.

Every component in your library must carry a prefix that identifies its source and its status. A button component named Button/Primary/Large is ambiguous. A component named lib_button_primary_large with a version suffix is traceable. The prefix lib_ signals that this is a library component, not a local copy. The Ghent Workgroup specification logic for PDF creation relies on similar naming discipline: a file that does not declare its output intent cannot be verified by preflight. A component that does not declare its library origin cannot be audited for drift.

The rule is simple. Every component in the library uses the prefix of the library name, an underscore, the component category, and the variant. A local override adds the suffix _ovr. A duplicate that is not a deliberate override must be deleted, not renamed. Enforce this rule at the folder level, not by trust.

Version control for design files does not mean Git. It means a changelog embedded in the file metadata and a naming convention that includes the date and the version number. A file named q3_report_v2_2026_09_15.indd is unambiguous. A file named final_report_2.indd is not final and not version two.

What A Changelog Entry Must Contain

The changelog convention requires three entries per version: the date, the author, and the change. The change must reference the component or style that was modified, not a vague description. A changelog entry that says updated body text leading is insufficient. The entry must say body text leading changed per Bringhurst minimum recommendation. This level of detail allows a future designer to revert the change or understand its rationale without reverse-engineering the file.

The failure case is the file with no changelog and a name like v3. After four months, nobody knows what changed between v2 and v3, and both versions are kept because one might be the correct one. The library rule is: no file enters the library without a changelog. A file without one is a draft, not a template.

A small team needs three folders in the Figma template library. The first folder is _sources, which contains the design token files, the style definitions, and the component variants. The second folder is _templates, which contains the page-level layouts that place components into a layout and demonstrate the design's underlying content structure, as defined by Brad Frost in 2013. The third folder is _archive, which contains deprecated components and templates that are no longer in use but are retained for reference.

The underscore prefix on folder names is deliberate. It forces these folders to sort to the top of the file browser, making them the first thing a designer sees when opening the library. The archive folder is not a graveyard where files go to die. It is a reference collection with its own naming convention: every archived file must include the date it was archived and the reason. A file archived without a reason is indistinguishable from a file that was simply forgotten.

Attribute	Without Library	With Library
File naming	business_card_final_v2.indd	lib_card_business_v2_2026_09_15.indd
Component variant	Button (local copy)	lib_button_primary_large (linked)
Style sheet	Paragraph Styles 1–15 (unnamed)	lib_body_text / lib_heading_01 / lib_caption
Changelog	None	Date, author, change description
Preflight compliance	Not checked	PDF/X-4 verified per ISO 15930-7
Font embedding	Not checked	OpenType fsType bit verified before inclusion

The InDesign template master page organisation must follow a strict inheritance hierarchy. The base master page, named A-Master, contains the grid, the baseline grid interval, the margin settings, and the safe area trim tolerance. Child master pages, named B-Master and C-Master, inherit from A-Master and add only the elements that diverge: a shifted header position, an alternate footer layout, or a distinct column count.

The Core Inheritance Rule

The inheritance rule is: a child master page must not override any element that is defined on the parent. If the parent sets a baseline grid interval of 12 points, the child cannot change it. If the child needs a separate interval, it must use a separate parent. This rule prevents the cascade failure where a change to the parent master page breaks all child pages because the children had overridden the same attribute.

The failure case is the document with five master pages, each with its own margin settings, none of which match. The document is technically usable, but any global change requires editing all five masters. The library rule is: no document with more than one master page enters the library unless each child master page inherits from a single parent.

A font that cannot be embedded in a PDF cannot enter the template library. The OpenType fsType embedding bit in the OS/2 table determines whether a font may be embedded. A font with fsType bit 0 allows unrestricted embedding. A font with fsType bit 2 (Preview & Print) allows embedding for preview and printing but not for editing. A font with fsType bit 4 (Editable) allows embedding for editing. A font with fsType bit 8 (No Embedding) must be excluded from the library entirely.

Licensing And Distribution

The SIL Open Font License includes a derivative condition that requires any modified version of the font to carry the same license. This condition affects whether a modified font can be embedded in a template that is distributed to clients. The library rule is: every font in the library must have a license that permits embedding in a PDF that is delivered to a third party. A font whose license is unclear or that carries a server licensing requirement for SaaS PDF generation must be replaced with a font from Google Fonts or a similarly permissive source.

The failure case is the template that looks correct in InDesign but prints with a font substitution because the printer's RIP cannot embed the font. The library gate prevents this by verifying the fsType bit before the font is added to the library. A font that fails the check is not included. Find an alternative before the template is published.

Component token naming follows the same logic as file naming. A token named color_primary_500 is unambiguous. A token named brand_blue is ambiguous because it does not specify the colour space, the intended use, or the accessibility compliance. The library rule is: every token must include its category, its function, and its value reference.

The category is one of: color, type, spacing, or shadow. The function describes the role: primary, secondary, accent, or neutral. The value reference is the specific value: hex code, point size, pixel value, or opacity. A token named type_body_large_16pt is a complete specification. A token named body is not.

The supporting terms that a token system cannot exist without include the baseline grid interval, the glyph count font coverage check for multilingual content, and the variable font axis dead weight that occurs when a variable font file includes axes that are never used in the templates. The library rule is: every token must be referenced in at least one component. A token that is defined but never used is dead weight and must be removed.

A request comes in for a two-page flyer with a specific layout, brand colours, and body text. Without the library, the designer opens a previous flyer file, duplicates it, and modifies the text. The previous flyer had mismatched margin settings, a separate baseline grid interval, and a font the previous designer had used that was not in the library. The new flyer looks similar but is not identical. The client notices the discrepancy.

With the library, the designer opens the template file, which is linked to the library components. The margin settings are locked. The baseline grid interval is set to 12 points and cannot be overridden. The font is embedded with a verified fsType bit. Change the text and export to PDF/X-4 per ISO 15930-7 with a Fogra 51 ICC profile. The file passes preflight on the first attempt. Total time from request to delivery: 45 minutes instead of 3 hours.

The difference is not speed. The difference is repeatability. A file produced without the library is a unique artefact. A file produced with the library is one instance of a reproducible system.

A library that is not maintained becomes a graveyard within six months. The maintenance rules are:

• Quarterly audit: every component and template in the library is reviewed for relevance. Any component that has not been used in three months is moved to the archive folder. Any component that has been overridden more than three times is redesigned.
• Preflight verification: every template in the library must pass a Ghent Workgroup preflight profile before it is published. A template that fails preflight is not a template. It is a draft.
• Font review: every font in the library is checked for license updates and fsType bit changes. A font whose license has changed is removed and replaced.
• Colour space verification: every template is checked for ICC profile embedding. A template that uses RGB colour for a print job is flagged and corrected. The correct ICC profile for coated offset in Europe is PSO Coated v3 (Fogra 51). For the US, it is GRACoL 2013.

The Audit Trap

The failure case is the library that passes the quarterly audit but still contains dead components because the audit checks for use, not for correctness. A component that is used but incorrect is worse than a component that is unused. The library rule is: every component must pass the preflight profile before it can be used, regardless of how many times it has been used in the past.

The most common failure mode is not a missing font or a wrong ICC profile. It is the designer who bypasses the library entirely because the library is too slow to load, too hard to navigate, or too restrictive to use. A library that adds friction to the design process will be abandoned within two weeks. The solution is not to make the library more restrictive. Make the library faster and easier to use than the alternative.

A library that is faster to use than the alternative lets the designer find the template, open it, and export in under five minutes. A library that is harder to use than the alternative forces the designer to spend ten minutes searching for the right file and then give up and duplicate a previous job. The library that wins is the one that respects the designer's time.