Source:
ocean/docs/adr/050-design-system-cleanup-monochrome.md| ✏️ Edit on GitHub
ADR-050: Design System Cleanup and Monochrome Transition
Date: 2025-01-03
Status
Accepted
Context
The Ocean platform previously implemented a complex multi-theme design system with:
- Design tokens stored in JSON files
- Style Dictionary for CSS generation
- Multiple color palettes (neutral, stone, zinc, gray, slate)
- Dynamic theme switching via React Context
- Contrast checking and validation tools
- Pre-commit hooks for design validation
- Build-time token generation
This system added significant complexity:
- Multiple build steps required before development
- Maintenance overhead for token files
- Unnecessary abstraction for a single-product platform
- Performance impact from dynamic theme switching
- Complex tooling dependencies
The platform had already transitioned to a shadcn-inspired monochrome design system, but legacy infrastructure remained in the codebase.
Decision
We will complete the transition to a simple monochrome design system by:
-
Removing all design token infrastructure
- Delete
/design-tokens/directory - Remove Style Dictionary configuration and dependency
- Remove all token-related build scripts
- Delete
-
Simplifying the color system
- Use direct CSS variables in
/src/styles.css - OKLCH color space for all colors
- Single grayscale palette with light/dark modes
- No runtime theme switching
- Use direct CSS variables in
-
Cleaning up tooling
- Remove contrast checking tools (no longer needed for monochrome)
- Remove token generation from pre-commit hooks
- Remove all token-related scripts from package.json
-
Maintaining shadcn compatibility
- Keep CSS variable naming compatible with shadcn/ui
- Preserve light/dark mode switching
- Use standard Tailwind CSS classes
Consequences
Positive
- Reduced complexity: No build-time token generation or complex tooling
- Faster development: No pre-build steps, immediate development start
- Smaller bundle: No theme switching logic or multiple color sets
- Easier maintenance: Colors defined in one place, no abstraction layers
- Better performance: No runtime theme calculations
- Cleaner codebase: ~15 fewer files and tools to maintain
Negative
- Less flexibility: Adding new color themes would require more work
- No design tokens: Loss of potential Figma integration (not currently used)
- Manual updates: Color changes must be made directly in CSS
Neutral
- shadcn alignment: Maintains compatibility while simplifying implementation
- Accessibility: Monochrome design inherently has good contrast
- Developer experience: Simpler but less "enterprise" feel
Implementation
The cleanup involved:
-
Removed files:
/design-tokens/
/style-dictionary.config.js
/tools/check-contrast.ts
/tools/fix-contrast.ts
/tools/build-tokens.js
/tools/convert-palettes-to-tokens.js
/tools/sync-design-tokens.js
/tools/validate-tokens.js
/tools/codemod-replace-raw-colors.ts
/.github/workflows/contrast-check.yml -
Updated package.json:
- Removed all
tokens:*scripts - Removed
predevandprebuildhooks - Removed
design:codemodscript - Removed
style-dictionarydependency
- Removed all
-
Updated code comments:
- Fixed outdated references to
useColorThemehook - Updated to reference new CSS-based approach
- Fixed outdated references to
Notes
- The monochrome design was chosen for its simplicity and professional appearance
- This aligns with the "foundation-stage" nature of the project
- Future theme requirements can be met with CSS custom properties
- The cleanup reduces the codebase by approximately 2,000 lines of configuration and tooling
References
- ADR-041: Diverging from shadcn contrast for accessibility
- Original design system implementation (removed in this cleanup)
- shadcn/ui documentation: https://ui.shadcn.com/docs/theming