Skip to main content
New: Deck Doctor. Upload your deck, get CPO-level feedback. 7-day free trial.
TemplateFREE⏱️ 3-5 hours for initial plan

Component Library Template for Product Managers

A component library planning template for design and engineering teams. Covers component inventory, prioritization, API design, versioning strategy,...

Last updated 2026-03-05
Component Library Template for Product Managers preview

Component Library Template for Product Managers

Free Component Library Template for Product Managers — open and start using immediately

or use email

Instant access. No spam.

Get Template Pro — all templates, no gates, premium files

888+ templates without email gates, plus 30 premium Excel spreadsheets with formulas and professional slide decks. One payment, lifetime access.

Get Template Pro — $49

Need a custom version?

Forge AI generates PM documents customized to your product, team, and goals. Get a draft in seconds, then refine with AI chat.

Generate with Forge AI

What This Template Is For

Building a component library without a plan results in either of two failure modes: the team builds 60 components nobody uses, or the team builds 6 components that cover 10% of the product. Both outcomes waste months of engineering effort and erode trust in the design system initiative.

This template provides a structured planning process for component libraries. It covers the initial audit (what components exist today), prioritization (what to build first), API design standards (how components should behave), versioning (how to ship updates without breaking consumers), and adoption tracking (how to measure whether the library is actually being used).

The template is format-agnostic. It works for React, Vue, Svelte, or web components. It works whether your library lives in a monorepo or a standalone package.

This pairs with the design system documentation template for documenting each component after it is built. The color system template and design token template provide the token foundation that components consume. For teams evaluating where they stand, the AI Design Maturity Model benchmarks design system maturity across multiple dimensions. The glossary entry on design systems covers the core terminology.

How to Use This Template

  1. Run a component audit first. Screenshot every unique UI pattern in the product. Group duplicates. You will likely find 3-5 implementations of the same button, modal, or dropdown.
  2. Score each component on frequency (how often it appears) and inconsistency (how many variants exist across the product). High frequency + high inconsistency = build first.
  3. Define your API standards before writing code. Decide naming conventions, prop patterns, composition vs. configuration, and accessibility requirements. Changing these after 20 components exist is extremely expensive.
  4. Plan in waves of 8-12 components. Ship each wave, measure adoption, gather feedback, then plan the next wave.
  5. Track adoption with real numbers: percentage of product surfaces using library components vs. one-off implementations.

The Template

Component Audit

Audit scope: [Which products/surfaces were audited, e.g., "Dashboard, settings, onboarding flow, billing pages"]

Audit date: [Date]

Audit method: [How the audit was conducted, e.g., "Screenshots of every unique UI element, grouped by pattern, cross-referenced with Figma"]

PatternVariants FoundSurfaces UsedInconsistenciesPriority
[e.g., Button][e.g., 7][e.g., every page][e.g., 4 different border-radius values, 3 font sizes][High/Med/Low]
[e.g., Modal][e.g., 4][e.g., settings, onboarding][e.g., different close button placement, inconsistent padding][...]
[e.g., Data Table][e.g., 5][e.g., dashboard, reports, admin][e.g., different sort icons, varying row heights, mixed pagination][...]
[e.g., Form Input][e.g., 6][e.g., every form][e.g., different error states, inconsistent label positioning][...]

Audit summary:

  • Total unique patterns identified: [Number]
  • Patterns with 3+ inconsistent variants: [Number]
  • Estimated engineering hours wasted on duplicate implementations: [Number]

Component Prioritization Matrix

Score each component 1-5 on two dimensions, then multiply for a priority score.

Frequency (how often it appears):

  • 5: Every page/view
  • 4: Most pages
  • 3: Several key surfaces
  • 2: A few surfaces
  • 1: Rare or single-use

Inconsistency (how fragmented current implementations are):

  • 5: 5+ different implementations, no shared code
  • 4: 3-4 implementations, significant visual differences
  • 3: 2-3 implementations, minor differences
  • 2: Mostly consistent, small deviations
  • 1: Already consistent across the product
ComponentFrequency (1-5)Inconsistency (1-5)ScoreWave
[e.g., Button][5][4][20]1
[e.g., Input][5][4][20]1
[e.g., Modal][4][5][20]1
[e.g., Data Table][4][4][16]1
[e.g., Dropdown/Select][4][3][12]2
[e.g., Toast/Notification][3][4][12]2
[e.g., Tabs][3][3][9]2
[e.g., Avatar][3][2][6]3

Wave Plan

Wave 1: Foundation (Weeks 1-4)

ComponentOwnerStatusDependenciesEst. Days
[Component][Engineer]Not started / In progress / Done[Token layer, icon system][Days]
[Component][Engineer][...][...][...]
[Component][Engineer][...][...][...]

Wave 1 success criteria:

  • ☐ All components pass accessibility audit (WCAG 2.1 AA)
  • ☐ All components have Storybook documentation
  • ☐ At least 2 product surfaces migrated to library components
  • ☐ Design tokens are the single source of truth for colors, spacing, typography

Wave 2: Core Patterns (Weeks 5-8)

ComponentOwnerStatusDependenciesEst. Days
[Component][Engineer][...][...][...]

Wave 3: Advanced (Weeks 9-12)

ComponentOwnerStatusDependenciesEst. Days
[Component][Engineer][...][...][...]

API Design Standards

Define these conventions before building any component. Consistency across 50 components matters more than perfection on any single one.

Naming conventions:

ConventionRuleExample
Component names[e.g., PascalCase, noun-first]Button, DataTable, NavigationMenu
Prop names[e.g., camelCase, adjective for booleans]isOpen, variant, onClose
Event handlers[e.g., on prefix + verb]onClick, onChange, onDismiss
Size prop values[e.g., t-shirt sizing]sm, md, lg, xl
Variant prop values[e.g., semantic names]primary, secondary, destructive, ghost

Composition vs. configuration:

PatternWhen to UseExample
Single component with propsSimple components with few variants
Compound componentsComplex components with multiple sub-parts
Render props / slotsWhen consumers need control over inner content ...} />

Required standards for every component:

  • ☐ Supports className or style prop for escape-hatch customization
  • ☐ Forwards ref to the root DOM element
  • ☐ Spreads remaining props to the root element (...rest)
  • ☐ Has TypeScript types exported for all props
  • ☐ Includes data-testid prop for testing
  • ☐ Handles all keyboard interactions per WAI-ARIA patterns
  • ☐ Respects prefers-reduced-motion for animations
  • ☐ Works in SSR environments (no window access at import time)

Versioning Strategy

Version TypeWhenExample
Patch (0.0.x)Bug fixes, visual tweaks, no API changesFix button focus ring in Safari
Minor (0.x.0)New components, new props, backward-compatibleAdd loading prop to Button
Major (x.0.0)Breaking prop changes, removed componentsRename isOpen to open across all components

Breaking change policy:

  1. Announce in changelog 2 releases before removal
  2. Add deprecation warnings (console.warn) in the intermediate release
  3. Provide a codemod or migration script for major version bumps
  4. Support the previous major version with security patches for 6 months

Adoption Tracking

MetricHow to MeasureTargetCurrent
Library coverage% of UI surfaces using library components[e.g., 80%][e.g., 15%]
One-off component countNumber of custom implementations that duplicate library components[e.g., < 10][e.g., 47]
Bundle sizeTotal library size (gzipped)[e.g., < 50KB][e.g., N/A]
Storybook doc coverage% of components with full Storybook docs100%[e.g., 0%]
Accessibility pass rate% of components passing axe-core audit100%[e.g., N/A]
Consumer satisfactionSurvey: "How easy is it to use the component library?" (1-5)> 4.0[e.g., N/A]

Monthly adoption report template:

  • Components shipped this month: [Number]
  • Product surfaces migrated: [Number]
  • Open bugs: [Number]
  • Feature requests: [Number]
  • Consumer satisfaction score: [Score]

Dependency and Tooling Decisions

DecisionChoiceRationale
Framework[React / Vue / Web Components / etc.][Why]
Styling[CSS Modules / Tailwind / CSS-in-JS / etc.][Why]
Documentation[Storybook / Docusaurus / Custom][Why]
Testing[Jest + RTL / Vitest / Playwright CT][Why]
Build tool[tsup / Vite / Rollup / etc.][Why]
Package registry[npm / internal registry / monorepo][Why]
Icon system[SVG sprites / React components / icon font][Why]

Filled Example: B2B SaaS Dashboard

Audit Summary

Audited: Dashboard, Settings, Billing, Onboarding, Admin panel.

PatternVariantsPriority Score
Button720 (Wave 1)
Text Input620 (Wave 1)
Modal/Dialog420 (Wave 1)
Data Table516 (Wave 1)
Select/Dropdown412 (Wave 2)
Toast312 (Wave 2)
Tabs39 (Wave 2)
Badge48 (Wave 3)
Avatar26 (Wave 3)
Tooltip36 (Wave 3)

Wave 1 Plan

ComponentOwnerEst. DaysDependencies
ButtonAlex R.3Token layer
TextInputSam T.4Token layer
ModalAlex R.5Button, focus trap
DataTableJordan L.8Button, TextInput, sorting logic

Timeline: 4 weeks. Success: 3 product surfaces migrated, 100% a11y pass.

API Standard (excerpt)

All components: PascalCase names, camelCase props, on prefix for events, t-shirt sizing for size, semantic names for variant. Compound pattern used for Select, Modal, DataTable. Single-component pattern for Button, Input, Badge.

Key Takeaways

  • Audit existing components before planning. Data on inconsistency and duplication drives prioritization
  • Ship in waves of 8-12 components. Measure adoption after each wave before planning the next
  • Define API conventions once and apply them consistently across every component
  • Track adoption with real metrics: coverage percentage, one-off count, consumer satisfaction
  • Use headless libraries for complex interactive patterns. Build simple components from scratch

About This Template

Created by: Tim Adair

Last Updated: 3/5/2026

Version: 1.0.0

License: Free for personal and commercial use

Frequently Asked Questions

How many components should Wave 1 include?+
Start with 6-10 components that cover the highest-frequency, highest-inconsistency patterns. Shipping fewer components faster builds momentum and demonstrates value to stakeholders. If Wave 1 takes longer than 6 weeks, you have too many components in it. Cut scope and move components to Wave 2.
Should we build from scratch or use a headless library?+
Headless libraries like Radix UI, Headless UI, or React Aria provide accessible behavior without styling. They handle keyboard navigation, focus management, and ARIA attributes for complex components (select, combobox, dialog, popover). Building these from scratch takes 3-5x longer and introduces accessibility bugs. Use headless libraries for complex interactive components and build simple components (button, badge, avatar) from scratch.
How do we convince teams to adopt the library instead of building their own components?+
Adoption is driven by developer experience, not mandates. The library must be easier to use than building from scratch. That means excellent documentation, copy-pasteable examples, fast install times, and responsive bug fixes. Track adoption with metrics (one-off count, coverage %) and share them monthly. When a team builds a one-off that the library already covers, ask why. The answer reveals gaps in documentation, API design, or missing variants.
What is the right level of customization to allow?+
Allow theming through tokens (colors, spacing, typography). Allow structural customization through composition (compound components, render props). Avoid allowing arbitrary style overrides through `className` injection for core visual properties. The more you allow consumers to customize, the less visual consistency you get. The escape hatch (`className` prop) should be available for edge cases but not the primary customization mechanism.
How do we handle breaking changes?+
Follow semantic versioning strictly. Announce breaking changes 2 releases in advance. Provide automated codemods where possible (tools like jscodeshift). Support the previous major version with security fixes for 6 months. Ship a migration guide that covers every breaking change with before/after code examples. Never merge a breaking change without a corresponding migration path. ---

Explore More Templates

Browse our full library of PM templates, or generate a custom version with AI.

All TemplatesTemplate VaultGenerate with AIRoadmap Templates
Free PDF

Like This Template?

Subscribe to get new templates, frameworks, and PM strategies delivered to your inbox.

or use email

Join 10,000+ product leaders. Instant PDF download.

Want full SaaS idea playbooks with market research?

Explore Ideas Pro →