697 lines
13 KiB
Markdown
697 lines
13 KiB
Markdown
# Design System Task for Car Dashcam Website
|
|
|
|
For: Designer + Frontend Design System Implementation Engineer
|
|
Stack: React + Next.js + Tailwind CSS
|
|
Architecture: Atomic Design + Design Tokens + Component-Driven Development
|
|
|
|
---
|
|
|
|
# Product Context
|
|
|
|
The website is focused on car video registrators (dashcams), accessories, comparisons, reviews, installation guides, and purchase flows.
|
|
|
|
The product positioning is:
|
|
|
|
* technologically advanced
|
|
* reliable in emergencies
|
|
* automotive premium feel
|
|
* minimal cognitive overload
|
|
* optimized for mobile-first browsing
|
|
* fast perceived loading
|
|
* visually trustworthy for expensive electronics
|
|
|
|
The visual language should combine:
|
|
|
|
* modern automotive UI
|
|
* Japanese/Korean automotive electronics aesthetics
|
|
* dashboard HUD inspiration
|
|
* premium marketplace clarity
|
|
* clean editorial layouts
|
|
|
|
Avoid:
|
|
|
|
* aggressive gaming aesthetics
|
|
* neon cyberpunk overload
|
|
* cheap AliExpress visual style
|
|
* overly corporate SaaS look
|
|
* generic ecommerce templates
|
|
|
|
The design should feel somewhere between:
|
|
|
|
* Tesla interface
|
|
* Blackmagic Design product pages
|
|
* Sony camera product pages
|
|
* premium automotive accessories catalog
|
|
* modern editorial tech magazine
|
|
|
|
---
|
|
|
|
# Resolved Direction
|
|
|
|
## Product Strategy
|
|
|
|
Phase 1 should optimize for editorial trust and comparison-first decision making, not direct ecommerce conversion.
|
|
|
|
The first proof artifact is a visual direction brief for a “Best Dashcams 2026” comparison page. Code implementation comes later, after the visual language is approved.
|
|
|
|
The page should use:
|
|
|
|
* one overall winner
|
|
* use-case winners for different buyer needs
|
|
* transparent scoring
|
|
* editorial override notes when real-world testing contradicts a raw score
|
|
|
|
Default score dimensions:
|
|
|
|
* video
|
|
* night
|
|
* parking
|
|
* reliability
|
|
* usability
|
|
* value
|
|
|
|
Use the same six dimensions across categories, but allow category-specific weights.
|
|
|
|
## Trust Model
|
|
|
|
Product facts and claims must expose three public trust states:
|
|
|
|
* verified
|
|
* claimed
|
|
* unknown
|
|
|
|
The public UI should stay simple, but the internal data model should preserve verification method, for example:
|
|
|
|
* measured in review
|
|
* confirmed from firmware docs
|
|
* confirmed from teardown
|
|
* confirmed by multiple sources
|
|
|
|
Trust labels should be quiet evidence chips with an icon and short label. Details such as method, source, and date should live in tooltips, detail panels, or source notes.
|
|
|
|
## Visual Anchor
|
|
|
|
The primary visual anchor is premium camera/product editorial, with automotive HUD cues used secondarily.
|
|
|
|
Real product and media photography should dominate. UI, HUD, and camera-interface details should appear only as restrained overlays or supporting metadata.
|
|
|
|
The default theme is light-first titanium brochure with dark product/media modules and full dark-mode parity.
|
|
|
|
## First Viewport
|
|
|
|
The first viewport of “Best Dashcams 2026” should prioritize trust and decision shortcuts:
|
|
|
|
* overall pick
|
|
* 3-5 use-case winners
|
|
* methodology access
|
|
* evidence labels
|
|
* concise scoring context
|
|
|
|
Avoid leading with a purely cinematic product hero if it delays comparison intent.
|
|
|
|
## Comparison UX
|
|
|
|
Mobile comparison should use stacked winner cards first, followed by a horizontal comparison table with sticky spec labels.
|
|
|
|
The comparison table should lead with a compact hardware block before outcome rows.
|
|
|
|
Core first rows:
|
|
|
|
* sensor
|
|
* resolution/FPS
|
|
* bitrate
|
|
* HDR
|
|
* lens/FOV
|
|
* storage
|
|
* capacitor/battery
|
|
* channels
|
|
|
|
Then show verdict, score dimensions, known issues, price, and seller information.
|
|
|
|
## Ecommerce Role
|
|
|
|
Purchase CTAs should be secondary and evidence-adjacent. They should sit near price and seller information, but must not dominate winner cards or turn the page into an affiliate marketplace.
|
|
|
|
## Visual Taste Guardrails
|
|
|
|
Use muted, pastel, old-money color behavior. Avoid raw bright, screaming, neon, or cheap saturated colors.
|
|
|
|
The lead accent family is desaturated petrol blue / steel blue.
|
|
|
|
Keep semantic amber and recording red, but make them muted and low-chroma.
|
|
|
|
Use tight geometry:
|
|
|
|
* 4-8px radii
|
|
* hairline borders
|
|
* mostly flat surfaces
|
|
* subtle tonal layering
|
|
* restrained shadows
|
|
|
|
Do not use:
|
|
|
|
* neon accents
|
|
* heavy glassmorphism
|
|
* big rounded SaaS cards
|
|
* stock gradients
|
|
* loud affiliate blocks
|
|
* crypto-dashboard styling
|
|
* gaming HUD overload
|
|
* generic ecommerce templates
|
|
|
|
## Typography Decision
|
|
|
|
Use an editorial sans for reading and UI, with technical monospace reserved for specs.
|
|
|
|
Name concrete font candidates in the spec:
|
|
|
|
* UI/editorial: Geist or Inter, with system sans fallback
|
|
* technical fragments: IBM Plex Mono or Iosevka, with system monospace fallback
|
|
|
|
---
|
|
|
|
# Primary Goals
|
|
|
|
## UX Goals
|
|
|
|
1. Make product comparison extremely easy
|
|
2. Build trust quickly
|
|
3. Reduce noise in specification-heavy interfaces
|
|
4. Support long-form technical reading
|
|
5. Make mobile usage first-class
|
|
6. Allow users to scan specs very fast
|
|
7. Visually separate verified information from marketing claims
|
|
8. Create reusable layouts for:
|
|
|
|
* reviews
|
|
* comparisons
|
|
* guides
|
|
* catalogs
|
|
* landing pages
|
|
* product detail pages
|
|
|
|
---
|
|
|
|
# Design Principles
|
|
|
|
## 1. Information Density Without Chaos
|
|
|
|
The system should support large amounts of technical data while remaining readable.
|
|
|
|
Dashcam users compare:
|
|
|
|
* bitrate
|
|
* sensor model
|
|
* HDR support
|
|
* parking mode
|
|
* CPL filters
|
|
* heat resistance
|
|
* night quality
|
|
* codecs
|
|
* Wi-Fi support
|
|
* cloud integrations
|
|
|
|
The UI must help scanning.
|
|
|
|
---
|
|
|
|
## 2. Automotive Precision
|
|
|
|
Spacing, typography, borders, and interactions should feel engineered rather than decorative.
|
|
|
|
Use:
|
|
|
|
* precise spacing scales
|
|
* subtle contrast
|
|
* restrained shadows
|
|
* clean hierarchy
|
|
* predictable interaction patterns
|
|
|
|
Avoid random rounded cards everywhere.
|
|
|
|
---
|
|
|
|
## 3. “Camera Hardware” Visual Language
|
|
|
|
Visual references:
|
|
|
|
* camera UI
|
|
* automotive instrument clusters
|
|
* photography gear
|
|
* black anodized aluminum
|
|
* dark matte surfaces
|
|
* glass reflections
|
|
* OLED dashboard typography
|
|
|
|
---
|
|
|
|
# Technical Requirements
|
|
|
|
## Stack
|
|
|
|
Implementation must use:
|
|
|
|
* Tailwind CSS
|
|
* CSS variables for tokens
|
|
* React compound components
|
|
* atomic architecture
|
|
* accessibility-first approach
|
|
* responsive-first approach
|
|
* light-first default with full dark-mode parity
|
|
* SSR-safe patterns for Next.js
|
|
|
|
---
|
|
|
|
# Atomic Architecture Structure
|
|
|
|
## Atoms
|
|
|
|
Examples:
|
|
|
|
* Button
|
|
* Badge
|
|
* Chip
|
|
* Tag
|
|
* Typography
|
|
* PriceLabel
|
|
* RatingStars
|
|
* Divider
|
|
* Input
|
|
* Select
|
|
* Checkbox
|
|
* IconButton
|
|
* Tooltip
|
|
* StatusIndicator
|
|
* BatteryIndicator
|
|
* SensorLabel
|
|
* RecordingQualityBadge
|
|
|
|
Requirements:
|
|
|
|
* variants
|
|
* sizes
|
|
* semantic states
|
|
* keyboard accessibility
|
|
* token-driven styling only
|
|
|
|
---
|
|
|
|
## Molecules
|
|
|
|
Examples:
|
|
|
|
* ProductCard
|
|
* ReviewCard
|
|
* SpecRow
|
|
* ComparisonRow
|
|
* VideoPreview
|
|
* PriceBlock
|
|
* SellerBadge
|
|
* NavigationItem
|
|
* Breadcrumbs
|
|
* SearchInput
|
|
* FilterDropdown
|
|
* StickyBuyPanel
|
|
|
|
---
|
|
|
|
## Organisms
|
|
|
|
Examples:
|
|
|
|
* ProductComparisonTable
|
|
* ReviewHero
|
|
* ProductGallery
|
|
* SpecificationSection
|
|
* VideoSamplesCarousel
|
|
* ReviewSummary
|
|
* InstallationGuide
|
|
* ProductGrid
|
|
* RecommendationRail
|
|
* StickyMobileActions
|
|
* ReviewTOC
|
|
* Header
|
|
* Footer
|
|
|
|
---
|
|
|
|
## Templates
|
|
|
|
Examples:
|
|
|
|
* Product Page
|
|
* Review Article
|
|
* Comparison Page
|
|
* Category Catalog
|
|
* Brand Page
|
|
* Landing Page
|
|
* Blog Article
|
|
* Search Results
|
|
* “Best Dashcams 2026” page
|
|
|
|
---
|
|
|
|
# Visual Direction
|
|
|
|
## Color System
|
|
|
|
### Base Palette
|
|
|
|
Primary colors should feel:
|
|
|
|
* automotive
|
|
* metallic
|
|
* technical
|
|
* trustworthy
|
|
|
|
Suggested direction:
|
|
|
|
* graphite
|
|
* gunmetal
|
|
* matte black
|
|
* titanium gray
|
|
* cold white
|
|
* deep navy accents
|
|
|
|
Accent colors:
|
|
|
|
* desaturated petrol blue / steel blue as the lead accent family
|
|
* muted low-chroma amber for warnings, heat, caution, and parking-related states
|
|
* muted low-chroma red for recording and critical states
|
|
* success green only where meaningful
|
|
|
|
Avoid rainbow interfaces and raw bright accents.
|
|
|
|
---
|
|
|
|
## Surface System
|
|
|
|
Need layered surfaces:
|
|
|
|
| Level | Usage |
|
|
| -------------- | -------------------------- |
|
|
| Surface 0 | Light titanium app background |
|
|
| Surface 1 | Main editorial cards and comparison blocks |
|
|
| Surface 2 | Elevated product/media modules |
|
|
| Surface 3 | Interactive hover surfaces |
|
|
| Surface Accent | Dark product/media blocks and premium highlights |
|
|
|
|
Light mode is the primary default.
|
|
|
|
Light mode should feel like:
|
|
|
|
* premium automotive brochure
|
|
* not plain white SaaS
|
|
|
|
Dark mode must have full parity and should preserve the same hierarchy, contrast, and trust labeling.
|
|
|
|
---
|
|
|
|
# Typography System
|
|
|
|
Typography is extremely important.
|
|
|
|
The interface must support:
|
|
|
|
* long-form reading
|
|
* technical specs
|
|
* comparisons
|
|
* editorial content
|
|
* ecommerce CTAs
|
|
|
|
Recommended direction:
|
|
|
|
Headings:
|
|
|
|
* geometric sans
|
|
* condensed possible for large titles
|
|
|
|
Body:
|
|
|
|
* highly readable
|
|
* neutral
|
|
* strong numeric clarity
|
|
|
|
Monospace:
|
|
|
|
* used for technical specs
|
|
* bitrate
|
|
* firmware
|
|
* codecs
|
|
|
|
Potential inspirations:
|
|
|
|
* Inter
|
|
* Geist
|
|
* IBM Plex Sans
|
|
* Iosevka for technical fragments
|
|
|
|
Resolved direction:
|
|
|
|
* UI/editorial: Geist or Inter, with system sans fallback
|
|
* technical fragments: IBM Plex Mono or Iosevka, with system monospace fallback
|
|
* monospace should be reserved for specs, firmware, codecs, bitrate, and compact technical metadata
|
|
|
|
---
|
|
|
|
# Layout System
|
|
|
|
## Grid
|
|
|
|
Need:
|
|
|
|
* 4px spacing base
|
|
* predictable responsive grid
|
|
* container system
|
|
* content widths for:
|
|
|
|
* article reading
|
|
* comparison tables
|
|
* dense catalogs
|
|
|
|
---
|
|
|
|
## Responsive Targets
|
|
|
|
Must support:
|
|
|
|
| Device | Priority |
|
|
| ----------------- | -------- |
|
|
| Mobile portrait | Highest |
|
|
| Mobile landscape | High |
|
|
| Tablet portrait | High |
|
|
| Desktop ultrawide | Medium |
|
|
|
|
Special focus:
|
|
|
|
* sticky bottom actions on mobile
|
|
* comparison tables on narrow screens
|
|
* thumb-friendly navigation
|
|
|
|
---
|
|
|
|
# Motion System
|
|
|
|
Motion should feel:
|
|
|
|
* mechanical
|
|
* precise
|
|
* responsive
|
|
|
|
Avoid:
|
|
|
|
* playful animations
|
|
* bouncing
|
|
* exaggerated easing
|
|
|
|
Allowed:
|
|
|
|
* subtle fades
|
|
* sliding panels
|
|
* controlled transitions
|
|
* progressive disclosure
|
|
|
|
---
|
|
|
|
# Icons
|
|
|
|
Need unified icon language.
|
|
|
|
Possible direction:
|
|
|
|
* outline icons
|
|
* automotive dashboard inspiration
|
|
* camera hardware icons
|
|
* signal indicators
|
|
* storage/media indicators
|
|
|
|
---
|
|
|
|
# Content Components
|
|
|
|
Must support:
|
|
|
|
## Review Components
|
|
|
|
* pros/cons
|
|
* verdict block
|
|
* sample footage embeds
|
|
* firmware history
|
|
* heat test results
|
|
* night comparison sliders
|
|
* speed readability examples
|
|
|
|
---
|
|
|
|
## Comparison Components
|
|
|
|
Need highly optimized comparison UX:
|
|
|
|
* sticky headers
|
|
* horizontal scroll with snap
|
|
* column pinning
|
|
* spec highlighting
|
|
* “best value” indicators
|
|
|
|
Resolved Phase 1 behavior:
|
|
|
|
* stacked winner cards first on mobile
|
|
* horizontal comparison table after cards
|
|
* sticky spec labels on narrow screens
|
|
* first visible table rows should be the compact hardware block: sensor, resolution/FPS, bitrate, HDR, lens/FOV, storage, capacitor/battery, channels
|
|
* outcome rows should follow the hardware block
|
|
|
|
---
|
|
|
|
# Ecommerce Components
|
|
|
|
Need:
|
|
|
|
* affiliate blocks
|
|
* seller comparison
|
|
* availability indicators
|
|
* price history blocks
|
|
* CTA hierarchy
|
|
* coupon presentation
|
|
|
|
Must avoid spammy affiliate aesthetics.
|
|
|
|
---
|
|
|
|
# Accessibility Requirements
|
|
|
|
Minimum:
|
|
|
|
* WCAG AA
|
|
* keyboard navigation
|
|
* visible focus states
|
|
* semantic HTML
|
|
* proper contrast
|
|
* reduced motion support
|
|
|
|
---
|
|
|
|
# Tailwind Requirements
|
|
|
|
## Must Produce
|
|
|
|
1. Tailwind token structure
|
|
2. Design token naming convention
|
|
3. Component API documentation
|
|
4. Variant strategy
|
|
5. Responsive rules
|
|
6. Dark/light theming system
|
|
7. Atomic folder structure
|
|
8. Figma component parity with React components
|
|
|
|
---
|
|
|
|
# Deliverables
|
|
|
|
## Design Deliverables
|
|
|
|
* Figma design system
|
|
* typography scale
|
|
* spacing system
|
|
* icon system
|
|
* color tokens
|
|
* component library
|
|
* responsive examples
|
|
* interaction states
|
|
* accessibility annotations
|
|
|
|
---
|
|
|
|
## Frontend Deliverables
|
|
|
|
Implementation in:
|
|
|
|
* React
|
|
* Next.js
|
|
* Tailwind CSS
|
|
|
|
Including:
|
|
|
|
* token-based theme
|
|
* reusable atomic components
|
|
* Storybook
|
|
* dark/light support
|
|
* mobile-first responsiveness
|
|
* typed component APIs
|
|
* zero hardcoded colors in components
|
|
|
|
---
|
|
|
|
# Important Constraints
|
|
|
|
The final result must NOT look like:
|
|
|
|
* generic Tailwind template
|
|
* Bootstrap ecommerce
|
|
* crypto dashboard
|
|
* gaming UI
|
|
* cheap gadget marketplace
|
|
|
|
The interface should feel:
|
|
|
|
* premium
|
|
* calm
|
|
* technical
|
|
* engineered
|
|
* trustworthy
|
|
* fast
|
|
|
|
Users should subconsciously feel:
|
|
“This is a serious automotive electronics platform.”
|
|
|
|
---
|
|
|
|
# Suggested Initial Priority
|
|
|
|
Phase 1:
|
|
|
|
* typography
|
|
* colors
|
|
* spacing
|
|
* visual direction brief for “Best Dashcams 2026”
|
|
* buttons
|
|
* cards
|
|
* navigation
|
|
* product cards
|
|
* comparison table
|
|
|
|
Phase 2:
|
|
|
|
* article system
|
|
* review system
|
|
* ecommerce modules
|
|
* filtering system
|
|
|
|
Phase 3:
|
|
|
|
* motion
|
|
* advanced comparison UX
|
|
* personalization
|
|
* saved comparisons
|
|
* dashboard-like features
|