Set system roadmap
- Owner
- Maintainers
- Contributors
- Adopters
Design Governance
HikeOn Design System
This document outlines the governance structure, roles, and processes that guide the development and maintenance of our design system.
Structure
Governance Model
Model Type
Hybrid
Core team owns foundations; product teams contribute components. This balances consistency at the base layer with flexibility where products need it most.
People
Roles & Responsibilities
Click a role to see expanded responsibilities.
Process
Contribution Workflow
Click each step to expand details.
- Document the gap — what component or pattern is missing?
- Note where inconsistency appears across products.
- Check if an existing component can be extended before proposing new work.
- Fill out the proposal template with context, use cases, and mockups.
- Attach Figma explorations or link to a Notion doc.
- Include accessibility considerations from the start.
- Share your proposal in the #design-system Slack channel.
- Add the item to the "Pending Review" Kanban board.
- Tag relevant maintainers if the work is time-sensitive.
- Usability: Does it solve the stated problem cleanly?
- Accessibility: WCAG AA contrast, keyboard nav, screen reader labels.
- Naming: Consistent with existing component vocabulary.
- Responsiveness: Works at common breakpoints.
- Approved: Component added to Figma library and code repo.
- Revise: Specific feedback returned; contributor iterates.
- Rejected: Rationale documented; alternative path suggested if possible.
Token Governance
PrimitivesSemanticComponent
Not directly consumable in design — only referenced by other tokens.
Adding a primitive or semantic token requires owner approval. Component tokens go through the standard contribution review.
Accountability
RACI Matrix
Click a cell to see what each assignment means for that activity.
RResponsible — Does the work to complete the activity.
AAccountable — Ultimately answerable; only one A per activity.
CConsulted — Provides input and expertise before decisions.
IInformed — Kept up to date on progress and outcomes.
| Activity | Owner | Maintainers | Contributors | Adopters |
|---|---|---|---|---|
| Set system roadmap | ||||
| Propose a new component | ||||
| Review and approve contributions | ||||
| Publish a release | ||||
| Deprecate a component | ||||
| Report a bug or gap | ||||
| Update design tokens | ||||
| Run office hours |
Propose a new component
- Owner
- Maintainers
- Contributors
- Adopters
Review and approve contributions
- Owner
- Maintainers
- Contributors
- Adopters
Publish a release
- Owner
- Maintainers
- Contributors
- Adopters
Deprecate a component
- Owner
- Maintainers
- Contributors
- Adopters
Report a bug or gap
- Owner
- Maintainers
- Contributors
- Adopters
Update design tokens
- Owner
- Maintainers
- Contributors
- Adopters
Run office hours
- Owner
- Maintainers
- Contributors
- Adopters
Getting Started
Templates
Click a template to expand its outline. Copy or open the full template.
- Problem statement — what gap does this fill?
- Affected products and use cases
- Proposed API and variant structure
- Figma explorations or wireframes
- Accessibility considerations
- Alternatives considered
- Component name and category
- Anatomy and sub-components
- Props / attributes and defaults
- States: default, hover, focus, disabled, error
- Responsive behavior at breakpoints
- Figma component structure
- Storybook story requirements
- Matches approved spec and Figma design
- Passes accessibility checklist
- Unit and visual regression tests included
- Storybook stories cover all variants
- No breaking changes without migration guide
- Documentation updated
- Changelog entry added
- Component being deprecated and reason
- Recommended replacement
- Migration steps with code examples
- Timeline: notice period and removal date
- Affected products to audit
- Support channel for migration questions
Status
Component Lifecycle
Select a status to see what it means for adopters.
Draft
In exploration, not ready for adoption
For adopters
Do not use in production. Draft components may change significantly or be removed without notice.
Metrics
System Health
How we measure whether the design system is actually working.
Adoption / CoveragePrimary metric
% of product UI built from the design system vs one-off work. This is the primary success metric.
Detach Rate
Tracked per component via Figma Library Analytics. A rising detach rate is a health signal — it means the component is failing real use.
Review threshold
Components exceeding 15% detachment are flagged for redesign.
Adoption and detach rate are how the system proves it's working — not component count.
Direction
Roadmap
Quarterly priorities and initiative status. Click an initiative for details.
Change Management
Versioning & Change Management
Version Format
MAJOR.MINOR.PATCHe.g. 2.4.1
Breaking changes require
- Migration guide
- 2-week notice before removal
- Announcement in Slack + email
Stay Connected
Communication
Monthly Design System Update
Posted in #design-system-updates
Office Hours
Biweekly drop-in for questions + proposals
Feedback Form
Anonymous feedback — link in Resources section
Quality Gate
Accessibility & Compliance Checklist
Before approving a component, verify each item. Progress is saved in your browser.
0 of 5 complete
History
Decision Log
Architecture decision records for key governance and technical choices.
Tooling
Tooling & Resources
Quick links to design system assets. Edit URLs to match your team.
- Figma Library (team-specific — redacted)
Component library and design tokens
- Storybook / Component Repo (team-specific — redacted)
Live component documentation and source code
- Design Tokens (team-specific — redacted)
Color, typography, spacing, and motion tokens
- Bug or Enhancement Tracker (team-specific — redacted)
JIRA, Linear, or Notion backlog
- Anonymous Feedback Form (team-specific — redacted)
Share suggestions without attribution