@hegemonart/get-design-done 1.14.7 → 1.15.0

package/reference/design-system-guidance.md

@@ -0,0 +1,177 @@
+# Design System Guidance
+
+A design system is not a component library. A component library is a collection of UI building blocks. A design system is the governing architecture that makes those components consistent, maintainable, and scalable across teams, products, and time. The difference matters because design systems require governance, versioning, and documentation infrastructure that component libraries do not. This file provides the principles and practices for building, evolving, and governing a design system at any maturity level.
+
+---
+
+## Token Versioning and Deprecation Policy
+
+Design tokens are an API. Like any API, they must be versioned, because the components and applications that consume them will break if tokens are renamed or removed without notice. Treating tokens as implementation details — things that can be changed quietly — is the single most common cause of unexpected visual regressions in design systems.
+
+**Semantic versioning for token APIs:** Token changes should follow SemVer semantics. Adding a new token is a minor release. Changing a token's value (e.g., updating `--color-brand-primary` from `#1a73e8` to `#1557b0`) is a minor release if the semantic meaning is preserved, or a major release if it changes the intent. Renaming or removing a token is always a major release.
+
+**Deprecation warnings before removal:** A token should never be removed without a deprecation period of at least one major version. During the deprecation period, the old token continues to work but emits a warning in development mode (or in Figma via variable mode annotation). The deprecation notice must include the replacement token and a migration date. Consumers who are warned well in advance can migrate on their own timeline; consumers who are surprised by breakage lose trust in the system.
+
+**Migration guides required:** Every major release that removes or renames tokens must include a migration guide. The guide must list every changed token, its old name, its new name, and a search-and-replace pattern that can be applied programmatically. A migration that requires consumers to manually discover what changed is not a migration — it is a breakage.
+
+**Never rename without aliasing:** When a token must be renamed — because the original name violated naming conventions, was ambiguous, or referred to a value rather than a purpose — the old name must be preserved as an alias pointing to the new name. The alias is deprecated and removed in the next major release after a documented migration window. This rule exists because token names propagate into codebases at scale: a rename without aliasing breaks every downstream consumer simultaneously.
+
+---
+
+## Multi-Brand Token Architecture
+
+A multi-brand token architecture allows a single component library to support multiple brand expressions — different color palettes, typography scales, and spacing densities — without forking the component code. The architecture achieves this through three distinct token layers, each with a specific responsibility.
+
+### Base Layer (Primitives)
+
+The base layer contains raw values with no semantic meaning. These are the atoms from which all other tokens are composed. A primitive token describes what the value is, not what it means or where it is used.
+
+Examples:
+- `--color-blue-500: #1a73e8`
+- `--color-blue-600: #1557b0`
+- `--space-4: 4px`
+- `--space-8: 8px`
+- `--font-size-16: 16px`
+
+Primitive tokens should never be used directly in component code. They exist only to feed the semantic layer. This constraint is essential: if components reference primitive tokens directly, you lose the ability to theme them without modifying component code.
+
+### Semantic Layer (Roles)
+
+The semantic layer maps primitive values to design roles. These tokens describe what a value is *for*, not what it *is*. The semantic layer is the theming boundary: swapping this layer changes the brand without touching components.
+
+Examples:
+- `--color-brand-primary: var(--color-blue-500)`
+- `--color-interactive-default: var(--color-brand-primary)`
+- `--color-surface-default: var(--color-white)`
+- `--color-text-primary: var(--color-grey-900)`
+
+Theme switching works by replacing the semantic layer. In practice, each brand defines its own semantic-layer token file that references its own base-layer primitives. Components import only semantic tokens; they have no knowledge of which primitive values are currently active.
+
+### Component Layer (Scoped Tokens)
+
+The component layer scopes semantic tokens to specific component contexts. Component-layer tokens exist because some components need values that differ from their semantic parents in specific states, variants, or sizes — but those differences should still be expressed as token relationships, not hardcoded values.
+
+Examples:
+- `--button-bg-primary: var(--color-interactive-default)`
+- `--button-bg-primary-hover: var(--color-interactive-hover)`
+- `--button-radius: var(--radius-md)`
+- `--card-shadow: var(--shadow-sm)`
+
+The component layer allows per-component overrides without polluting the semantic layer. It also makes the relationship between a component's visual properties and the broader token system explicit and auditable.
+
+---
+
+## Platform Translation
+
+The token architecture is only valuable if it can be consumed by all the platforms where the design system is deployed. Token translation tools convert the source-of-truth token definitions into platform-native formats.
+
+**Style Dictionary** is the standard open-source tool for token transformation. It reads a JSON or YAML token definition and transforms it into CSS custom properties, iOS Swift constants, Android XML resources, or any other format through a configurable pipeline. Style Dictionary is the right choice for most organizations because it is well-documented, widely adopted, and extensible. The transform pipeline should be version-controlled alongside the token definitions.
+
+**Tokens Studio (Figma plugin)** enables the design-to-code handoff by syncing Figma variables and styles to a JSON format that Style Dictionary can consume. When Tokens Studio is integrated with the CI pipeline — so that token changes in Figma trigger a transform and publish cycle — the design-to-code gap closes. Designers change tokens in Figma; engineers receive the updated CSS variables in the next publish. Without this integration, token values diverge between design and code, which is the root cause of most "the design says one thing but the code does another" defects.
+
+**Terrazzo** provides advanced token transform capabilities for organizations with complex multi-platform, multi-brand requirements. It handles cases that Style Dictionary handles awkwardly: mathematically derived scales (e.g., a spacing scale generated from a base value), conditional token resolution (different values for different contexts), and schema validation at the token definition level.
+
+---
+
+## Semantic-Layer Design
+
+The semantic layer is the design system's most consequential architectural decision. Naming tokens by value — `--color-red`, `--color-blue-700`, `--font-size-14` — produces a token API that is fragile under theming and misleading to consumers. Naming tokens by purpose produces an API that survives brand evolution, makes component intent explicit, and is safe to search and audit.
+
+**The cardinal rule:** Name tokens by PURPOSE, not by VALUE.
+
+Wrong: `--color-red` (a value name — breaks if the brand switches to orange for danger)  
+Right: `--color-surface-danger` (a purpose name — survives any palette change)
+
+Wrong: `--font-size-14` (a value name — breaks if the scale changes)  
+Right: `--font-size-caption` (a purpose name — survives a scale adjustment)
+
+**Tokens should survive theme changes without rename.** A token that must be renamed every time the palette changes is not a semantic token — it is a named value. The test: if you change the value of `--color-surface-danger` from red to orange, does the name still accurately describe its purpose? If yes, the name is semantic. If no, the name was value-based.
+
+**Hierarchical naming:** Semantic tokens should follow a consistent naming convention that expresses category, role, and variant:
+
+```
+--[category]-[role]-[variant]
+
+--color-surface-default
+--color-surface-subtle
+--color-surface-danger
+--color-text-primary
+--color-text-secondary
+--color-text-on-danger
+--shadow-elevation-sm
+--shadow-elevation-md
+```
+
+This convention makes the token vocabulary predictable: anyone who knows the convention can guess token names without consulting the documentation.
+
+---
+
+## Component API Conventions
+
+Component APIs are the contract between the design system and its consumers. An inconsistent or poorly designed API creates confusion, increases adoption friction, and makes migration painful. These conventions should be enforced in code review and documented in every component's API reference.
+
+**The `size` prop:** Always use named sizes — `sm`, `md`, `lg` — never raw pixel values. Pixel values expose implementation details and break the abstraction. Named sizes allow the design system to change the underlying pixel values across a version without requiring component consumers to update their code. `xs` and `xl` are acceptable additions when genuinely needed; avoid open-ended numeric scales that invite inconsistency.
+
+**The `variant` prop:** Use a fixed vocabulary: `primary`, `secondary`, `ghost`, `destructive`. Additional variants should be exceptional and documented with rationale. Never create variants that duplicate semantic roles (e.g., `danger` alongside `destructive`) — this fragments the vocabulary and creates consumer confusion about which to use.
+
+**Never expose internal implementation details as props.** A component whose API includes `backgroundColor`, `borderRadius`, or `fontWeight` props is not a component — it is a styled div. Internal visual properties should be determined by the component's variant and size, expressed through tokens. If a consumer needs visual customization beyond the declared variants, the appropriate tool is either a new variant (with a contribution RFC) or composition, not an escape hatch prop.
+
+---
+
+## Governance and Contribution Model
+
+A design system without governance is a suggestion library. Governance is what transforms a collection of shared components into a system with a consistent, predictable trajectory that teams can plan around.
+
+**RFC process for new tokens:** Any new semantic token must go through a Request for Comment process before being added to the system. The RFC must specify the token's name, its value, its purpose, which components will consume it, and whether it can be derived from existing tokens. The RFC process exists because new tokens are permanent: removing them requires a deprecation cycle, and adding unnecessary tokens pollutes the vocabulary.
+
+**Voting quorum for breaking changes:** Changes that remove or rename tokens, alter component API signatures, or change default visual behavior require a minimum quorum of token stakeholders (typically design leads and engineering leads from all consuming products) to review and approve. The quorum threshold and voting period should be documented and consistent. This prevents one team's urgency from creating breakage for other teams.
+
+**Single-owner per component:** Every component must have a named owner — a person who is responsible for its API, its documentation, its accessibility compliance, and its migration support. Ownerless components decay: they accumulate inconsistencies, miss accessibility regressions, and fall behind the token system evolution. Ownership should transfer explicitly when team members change roles.
+
+**Design and engineering sign-off both required:** No component ships without explicit sign-off from both the design lead (verifying that it matches the designed spec and has appropriate variant coverage) and the engineering lead (verifying that the API is correct, the implementation is idiomatic, and the tests cover the declared states). This dual sign-off is not bureaucracy — it is the minimal process that prevents the design-code gap from re-opening on every release.
+
+---
+
+## Documentation Standard
+
+A design system component that lacks complete documentation is not ready to ship. "Work in progress" documentation creates more confusion than no documentation at all, because it implies incomplete information without flagging what is missing. Every component must meet the documentation standard before it is published.
+
+The documentation standard for every component requires all of the following:
+
+**Purpose:** One or two sentences explaining what problem the component solves and when to use it rather than a different component. This is the most important section because it guides correct component selection.
+
+**Anatomy:** A labeled diagram or description of every visual element within the component: the container, the label, the icon, the state indicator. Anatomy documentation prevents implementers from modifying internal structure and creating visual inconsistencies.
+
+**Variants:** A complete catalog of all `variant` prop values with rendered examples and usage guidance. This section should answer "which variant should I use for X?" explicitly, not by inference.
+
+**States:** All interactive and conditional states the component can occupy: default, hover, active, focus, disabled, loading, error. Each state must be documented with a rendered example. Missing state documentation is the primary cause of inconsistent state implementation across consuming applications.
+
+**Do/Don't:** Paired examples showing correct and incorrect usage. Do/Don't documentation makes best practices concrete and prevents the most common misuse patterns.
+
+**Code example:** A minimal, copy-paste-ready code example for the most common usage. Consumers should be able to get to a correct implementation in under two minutes.
+
+**Accessibility notes:** The ARIA role, relevant ARIA attributes, keyboard interaction pattern, and focus management behavior. This section is not optional — every interactive component has accessibility requirements that cannot be inferred from the visual design alone.
+
+---
+
+## Design System Maturity Rubric
+
+Design systems evolve through recognizable maturity stages. Understanding where a system currently sits determines what investments are most impactful, and prevents organizations from attempting Level 4 governance without first establishing Level 3 token infrastructure.
+
+### Level 0: Ad-Hoc
+Components are built per project with no shared library. Each application makes its own visual decisions about color, typography, and spacing. There is no coordination mechanism, no shared vocabulary, and no reuse. Visual inconsistency across products is structural, not accidental. The cost of this level is paid in designer and engineer time spent rediscovering the same decisions on every project.
+
+### Level 1: Shared UI Kit
+A Figma component library exists and is used by designers. Components have documented variants and states in Figma. There is no code counterpart — developers implement from designs directly. The design-to-code gap is the defining problem at this level: the Figma library and the code diverge over time because there is no synchronization mechanism.
+
+### Level 2: Component Library
+Coded components exist and are shared across applications as a package. The library has basic documentation. There are no design tokens — visual values are hardcoded in component styles. Theming is not possible without forking the library. The code-to-design gap is still present because Figma and code are not synchronized.
+
+### Level 3: Token-Driven
+Design tokens exist in both Figma and code, synchronized through an automated pipeline (Tokens Studio + Style Dictionary). A semantic layer separates component implementations from raw values. Basic theming is possible by swapping the semantic layer. This is the first level where multi-brand support becomes practical. Most organizations that have invested in a design system are at Level 2 or approaching Level 3.
+
+### Level 4: Governed
+The system has a documented contribution process, semantic versioning, a deprecation policy, and migration guides. Every component has a named owner and complete documentation meeting the standard described in this file. Design and engineering sign-off is required for all releases. The system is reliable enough that consuming teams plan roadmaps around it rather than working around it.
+
+### Level 5: Platform
+The system supports multiple brands, multiple platforms (web, iOS, Android, potentially desktop), and automated quality enforcement. Accessibility compliance is verified in CI (automated contrast checking, ARIA validation). Visual regression testing catches unintended changes before release. Token transforms produce platform-native output. The system is itself a product with a roadmap, a changelog, a support channel, and a measured adoption rate across consuming products.

package/reference/design-systems-catalog.md

@@ -0,0 +1,151 @@
+# Design Systems Catalog — Quick Reference
+
+An opinionated index of the 18 major design systems most relevant to digital product work. For each system, the entry covers core philosophy, distinctive strengths, canonical documentation URL, and the clearest signal for when to reach for it. This catalog is not exhaustive — it is a decision aid for the planning and research phases.
+
+---
+
+## 1. Material Design 3 (Google)
+
+Material Design 3 (M3) is Google's most expressive design system to date, built around dynamic color — an algorithm that generates a full 5-palette color scheme (primary, secondary, tertiary, error, neutral) from a single seed color, enabling personalization and accessibility without manual token work. M3 introduced the concept of "tonal surfaces," where elevation is communicated through color tint rather than shadow depth, producing designs that work well in both light and dark environments. The component library is built on tokens and roles rather than hardcoded values, making it straightforward to implement across Android, web, and Flutter from a single specification. Reach for M3 when building products that will ship on Android, need to feel native to the Google ecosystem, or require automatic dark mode with a systematic color science approach.
+
+**Canonical URL:** https://m3.material.io
+
+---
+
+## 2. Apple Human Interface Guidelines (HIG)
+
+The Apple HIG is the definitive authority for UI on iOS, macOS, watchOS, visionOS, and tvOS. Unlike most design systems, the HIG is primarily a platform-convention guide — it documents the standard behaviors, controls, and interaction patterns that users expect on Apple hardware, rather than providing a token-based component system. Its core philosophy is that software should feel native to the platform: tapping into system behaviors (swipe-to-go-back, live text, share sheets) creates immediate familiarity that no custom UI can replicate as efficiently. The HIG is essential reading for any team building native Swift applications, and it also informs the right abstraction level for cross-platform apps — understanding platform conventions before deciding which to override.
+
+**Canonical URL:** https://developer.apple.com/design/human-interface-guidelines
+
+---
+
+## 3. Radix UI + WAI-ARIA Authoring Practices Guide
+
+Radix UI is a headless React component library built on the principle that accessibility should be the floor, not a feature to add later. Every Radix primitive — Dialog, Dropdown Menu, Tooltip, Select, Combobox — implements the corresponding WAI-ARIA authoring pattern exactly, including full keyboard navigation, focus management, and ARIA attribute wiring. Because Radix is headless (no styles included), it gives design teams complete visual control while eliminating the most error-prone aspect of component development: the accessibility behavior layer. The WAI-ARIA Authoring Practices Guide (APG) from the W3C is the authoritative specification that Radix implements — reading both together gives the complete picture of why each interaction pattern is designed as it is. Reach for Radix when building a custom design system from scratch, adopting shadcn/ui, or needing confidence that interactive components will pass WCAG 2.1 AA audit without custom accessibility engineering.
+
+**Canonical URLs:** https://www.radix-ui.com / https://www.w3.org/WAI/ARIA/apg
+
+---
+
+## 4. shadcn/ui
+
+shadcn/ui is not a traditional component library — it is a collection of copy-paste components built on Radix UI primitives, styled with Tailwind CSS, and distributed as source files rather than npm packages. The key insight is ownership: when you install a shadcn component, you own the code and can modify it freely without forking a library. Components are pre-wired with Radix's accessible behaviors and follow a consistent theming system using CSS custom properties for color tokens. The default aesthetic is clean, modern, and neutral — intentionally generic so that a brand layer can be applied on top. It has become the de facto starting point for new React applications that need accessible, customizable components quickly. Reach for shadcn/ui for SaaS products, dashboards, and admin interfaces where Tailwind is already in use and rapid iteration on component behavior is needed.
+
+**Canonical URL:** https://ui.shadcn.com
+
+---
+
+## 5. Polaris (Shopify)
+
+Polaris is Shopify's design system for merchant-facing admin interfaces. Its core philosophy is that merchant clarity always wins over visual novelty — Polaris components are deliberately conservative in style to ensure that merchants can focus on their tasks rather than learning a new UI language. The system has deep expertise in e-commerce-specific patterns: product data tables with bulk actions, multi-step onboarding flows, fee and pricing displays, order status timelines, and multi-currency number formatting. Polaris's React components have granular TypeScript props that encode business logic (e.g., `criticalAction`, `destructive`, `loading`) as semantic variants rather than styling choices. Reach for Polaris when building Shopify apps or when the product domain is merchant-facing e-commerce operations — its patterns encode years of learnings about how merchants process information and make decisions.
+
+**Canonical URL:** https://polaris.shopify.com
+
+---
+
+## 6. Carbon Design System (IBM)
+
+Carbon is IBM's enterprise design system, optimized for data-heavy, information-dense interfaces in business, analytics, and scientific computing contexts. Its defining strength is the data table — Carbon's data table component supports sorting, filtering, batch actions, inline editing, pagination, and nested rows with a level of completeness that other systems do not approach. The system is built on a strict 8-column responsive grid and a precise 4px base-8 spacing scale, which makes pixel-perfect implementation across breakpoints reliable. Carbon has comprehensive dark theme support and strong accessibility compliance across its entire component set. Reach for Carbon when building enterprise dashboards, admin consoles, analytics platforms, or any interface where users will spend hours per day working with structured data at high information density.
+
+**Canonical URL:** https://carbondesignsystem.com
+
+---
+
+## 7. Fluent 2 (Microsoft)
+
+Fluent 2 is Microsoft's design language for Office 365, Windows 11, and cross-platform Microsoft products. It represents the evolution of the Fluent Design System toward a more expressive, accessible, and motion-rich visual language — particularly notable for its implementation of "emotional design" through subtle depth, layering, and light effects. Fluent 2's component library covers the full complexity of Office-class applications: ribbon toolbars, multi-pane layouts, collaborative presence indicators, and right-to-left language support. It ships implementations for React, Web Components, Blazor, iOS, and Android. Reach for Fluent 2 when building Microsoft Teams extensions, Office Add-ins, Microsoft 365 integrations, or Windows application software where visual alignment with the Microsoft ecosystem creates credibility and user familiarity.
+
+**Canonical URL:** https://fluent2.microsoft.design
+
+---
+
+## 8. Primer (GitHub)
+
+Primer is GitHub's design system, optimized for developer tools, code review interfaces, and markdown-heavy content rendering. Its core philosophy is density with clarity — GitHub's users are experts who value information density and resent unnecessary visual chrome, so Primer components lean toward compact spacing and minimal decoration. Primer has particularly strong implementations of code-related components: syntax-highlighted code blocks, diff views, commit graphs, and inline comment threads. The markdown rendering system is comprehensive and well-tested across edge cases that arise in developer content. Primer also has deep investment in color accessibility — its color system was designed to meet WCAG AA across all combinations. Reach for Primer when building developer tools, code hosting features, documentation systems, or any product whose primary users are software engineers.
+
+**Canonical URL:** https://primer.style
+
+---
+
+## 9. Atlassian Design System
+
+The Atlassian Design System governs the visual and interaction language of JIRA, Confluence, Trello, and Bitbucket — a family of products built around complex project management and collaborative workflows. Its defining expertise is in high-complexity form patterns: multi-step wizards, permission matrices, workflow configuration editors, and nested task hierarchies. The system provides comprehensive guidance on progressive disclosure — how to surface advanced configuration options without overwhelming occasional users — as well as patterns for collaborative real-time interfaces where multiple users edit the same content simultaneously. Atlassian's design tokens are production-ready and cover light and dark modes. Reach for the Atlassian system when designing products with JIRA-like complexity: multiple user roles, configurable workflows, permission systems, and nested content hierarchies.
+
+**Canonical URL:** https://atlassian.design
+
+---
+
+## 10. Ant Design
+
+Ant Design is China's most widely deployed enterprise React component library, produced by Alibaba's Ant Group. It is extraordinarily feature-complete — the component library contains over 60 components covering every conceivable enterprise UI pattern, from complex data pickers and cascader inputs to statistical charts and map integrations. The visual language is formal and structured, with a consistent use of gray, blue, and red that reads as professional in enterprise business software contexts. Ant Design has dedicated design guidance for Chinese business conventions (date formats, number systems, address fields, bank card inputs) that is not available in Western-focused systems. Reach for Ant Design when building enterprise SaaS for business users, when the development team is comfortable with a mature but opinionated React API, or when the product targets Chinese markets where Ant Design patterns carry high recognition.
+
+**Canonical URL:** https://ant.design
+
+---
+
+## 11. Mantine
+
+Mantine is a full-featured React component and hooks library notable for the quality and breadth of its custom hooks alongside its component library. Beyond standard UI components, Mantine provides production-ready hooks for form management, clipboard access, scroll state, viewport detection, and OS-level preferences detection — hooks that typically require separate libraries. The component library has strong TypeScript support, a flexible theming system based on CSS custom properties, and first-class dark mode. Mantine's Form library is one of its differentiators: type-safe, nested form support with async validation without the boilerplate of React Hook Form or Formik. Reach for Mantine when building complex form-driven applications or data entry tools where the hook ecosystem adds as much value as the component library.
+
+**Canonical URL:** https://mantine.dev
+
+---
+
+## 12. Chakra UI
+
+Chakra UI is a modular, accessible React component library built on the constraint-based styling principle: every layout and spacing prop maps to a design token, making it difficult to use arbitrary values that break the system. Its style props API (`mt`, `px`, `bg`, `color`) creates a tight coupling between design tokens and component props that enforces consistency at the implementation layer without requiring linter rules. Chakra has strong accessibility defaults across its component set and a straightforward theme extension system. Its dark mode implementation is one of the simplest in the ecosystem — toggling color mode is a one-line API call. Reach for Chakra UI when the design system's token enforcement needs to happen at the component-API level rather than in a separate linting layer, or when rapid prototyping with token-constrained styling is the priority.
+
+**Canonical URL:** https://chakra-ui.com
+
+---
+
+## 13. Base Web (Uber)
+
+Base Web is Uber's open-source React component library, built for applications that prioritize data density, table-heavy interfaces, and complex form patterns at production scale. Its defining architectural feature is the "Overrides" pattern — every component exposes an override prop that allows any internal sub-component to be replaced or styled without forking the library. This makes Base Web uniquely flexible for organizations that need a coherent component system but have strict visual requirements that differ from any library's defaults. The data grid component is particularly capable, supporting row virtualization, column pinning, inline editing, and multi-sort. Reach for Base Web when building operations dashboards, logistics interfaces, or any data-intensive application where table density and performance at 10,000+ rows are primary requirements.
+
+**Canonical URL:** https://baseweb.design
+
+---
+
+## 14. Nord (Trivago)
+
+Nord is Trivago's clean, minimal design system for travel and hospitality product interfaces. It is characterized by a restrained visual palette (predominantly white, light gray, and a single accent color), generous whitespace, and a focus on content legibility — appropriate for interfaces where the primary job is helping users compare options and make decisions. Nord's component documentation is exceptionally clear and includes detailed usage rationale and anti-pattern guidance alongside component specs. The system is smaller than enterprise-scale alternatives but is well-suited to consumer-facing products where visual sophistication and content clarity are more important than component count. Reach for Nord when building consumer products in travel, hospitality, or marketplace contexts where the brand aesthetic is premium, minimal, and content-forward.
+
+**Canonical URL:** https://norddesignsystem.com
+
+---
+
+## 15. Spectrum (Adobe)
+
+Spectrum is Adobe's design system for Creative Cloud applications — Photoshop, Illustrator, Acrobat, XD, and the broader Adobe ecosystem. Its core philosophy is "density over decoration" — creative tool users need maximum canvas space and minimal chrome, so Spectrum components are compact, keyboard-navigable, and optimized for expert-user workflows rather than onboarding. Spectrum has particularly strong guidance for non-destructive editing patterns, panel layouts, property inspector interfaces, and contextual toolbars — patterns that rarely appear in general-purpose design systems. The Web Components implementation allows Spectrum to work across frameworks. Reach for Spectrum when building creative tools, editing interfaces, or professional applications where users are domain experts who value speed and control over visual novelty.
+
+**Canonical URL:** https://spectrum.adobe.com
+
+---
+
+## 16. Lightning Design System (Salesforce)
+
+The Salesforce Lightning Design System governs the visual and behavioral language of Salesforce CRM and the Force.com platform. It is purpose-built for complex CRM patterns: record detail layouts, activity timelines, relationship panels, approval workflows, and configurable page builders. The system has deep guidance on form layout for dense data entry, which is the core user task in CRM — entering leads, logging calls, updating opportunity stages. Lightning's component implementations are available for Aura (Salesforce's older component model), LWC (Lightning Web Components), and React. Reach for Lightning when building Salesforce AppExchange products, Salesforce platform integrations, or CRM-adjacent applications where users switch between Salesforce and your product and visual consistency reduces cognitive switching cost.
+
+**Canonical URL:** https://lightningdesignsystem.com
+
+---
+
+## 17. Evergreen (Segment)
+
+Evergreen is Segment's React UI framework for building B2B SaaS products. It was built to serve the Segment customer data platform — a product used by technical users (engineers and data analysts) who need to configure data pipelines, schema mappings, and integrations. Evergreen's components have a clean, professional aesthetic that signals "serious business tool" without the heaviness of traditional enterprise systems like Carbon or Lightning. The library is smaller and more focused than many alternatives, which makes it easier to learn completely and extend systematically. Reach for Evergreen when building developer-adjacent B2B SaaS — products used by technical business users who want a professional, efficient interface without the complexity of a full enterprise framework.
+
+**Canonical URL:** https://evergreen.segment.com
+
+---
+
+## 18. Gestalt (Pinterest)
+
+Gestalt is Pinterest's design system, purpose-built for visual discovery and image-heavy content interfaces. Its defining expertise is in masonry grid layouts, image card components, and the interaction patterns around visual content — save, collection, board management, and visual search. Gestalt's pin component and board grid are among the most refined implementations of image-based browsing patterns in any open-source design system. The system also has strong documentation of hover and focus states in image-grid contexts, which are notoriously difficult to implement accessibly without disrupting visual flow. Reach for Gestalt when building visual discovery products, mood board tools, image collection managers, or any interface where the primary content unit is an image in a variable-height masonry grid.
+
+**Canonical URL:** https://gestalt.pinterest.systems
+
+---
+
+*Use this catalog during the research phase to identify precedent, adapt established patterns, and avoid reinventing solutions that major organizations have already refined at scale.*