docs(redesign): record product brief and phased audit handoff
This commit is contained in:
@@ -0,0 +1,261 @@
|
||||
# Design System
|
||||
|
||||
## Visual direction
|
||||
|
||||
Modern SaaS with Scandinavian restraint.
|
||||
|
||||
The interface should feel:
|
||||
|
||||
- clean,
|
||||
- professional,
|
||||
- informative,
|
||||
- calm,
|
||||
- polished,
|
||||
- alive without being flashy.
|
||||
|
||||
Avoid both extremes:
|
||||
|
||||
- sterile all-white minimalism,
|
||||
- overly colourful startup dashboards full of gradients and decoration.
|
||||
|
||||
## Colour
|
||||
|
||||
Use one primary brand colour.
|
||||
|
||||
The exact colour is intentionally not yet locked.
|
||||
|
||||
Support:
|
||||
|
||||
- semantic success,
|
||||
- warning,
|
||||
- error,
|
||||
- neutral/information colours,
|
||||
|
||||
but these should not compete with the primary brand colour.
|
||||
|
||||
Dark mode must have its own thoughtfully designed surface hierarchy rather than simply inverting the light theme.
|
||||
|
||||
## Typography
|
||||
|
||||
Typography should prioritise readability in data-heavy screens.
|
||||
|
||||
Use a modern UI typeface with:
|
||||
|
||||
- strong numeral readability,
|
||||
- clear differentiation between headings and body copy,
|
||||
- good support for Norwegian characters,
|
||||
- robust rendering at small UI sizes.
|
||||
|
||||
Avoid excessive font-size variation.
|
||||
|
||||
## Spacing
|
||||
|
||||
Introduce a consistent spacing scale.
|
||||
|
||||
Current spacing inconsistencies should be treated as a redesign defect, not patched page by page.
|
||||
|
||||
Use spacing to communicate hierarchy:
|
||||
|
||||
- tighter within related controls,
|
||||
- moderate between fields/components,
|
||||
- generous between page sections.
|
||||
|
||||
## Density
|
||||
|
||||
Default density: comfortable.
|
||||
|
||||
Provide a user preference for at least:
|
||||
|
||||
- Comfortable
|
||||
- Compact
|
||||
|
||||
This should affect tables and other dense data surfaces without making every part of the app arbitrarily configurable.
|
||||
|
||||
## Surfaces
|
||||
|
||||
Use restrained cards/panels.
|
||||
|
||||
Not every section needs a card border.
|
||||
|
||||
Prefer hierarchy through:
|
||||
|
||||
- spacing,
|
||||
- subtle backgrounds,
|
||||
- typography,
|
||||
- dividers,
|
||||
- grouped surfaces.
|
||||
|
||||
Avoid excessive nested cards.
|
||||
|
||||
## Navigation
|
||||
|
||||
Desktop:
|
||||
|
||||
- collapsible left sidebar,
|
||||
- grouped sections,
|
||||
- clear active state,
|
||||
- icon + label,
|
||||
- tooltips when collapsed.
|
||||
|
||||
Mobile:
|
||||
|
||||
Use a mobile-specific navigation pattern, likely a bottom navigation for the most important destinations plus a secondary menu for the remainder.
|
||||
|
||||
Final mobile navigation should be determined during implementation testing.
|
||||
|
||||
## Components
|
||||
|
||||
Build or standardise a shared component system for at least:
|
||||
|
||||
- Button
|
||||
- IconButton
|
||||
- Input
|
||||
- Textarea
|
||||
- Select
|
||||
- Combobox
|
||||
- Checkbox
|
||||
- Radio
|
||||
- Switch
|
||||
- Date/time control
|
||||
- Search field
|
||||
- Form field
|
||||
- Form validation state
|
||||
- Card / surface
|
||||
- Metric card
|
||||
- Table
|
||||
- Mobile data card
|
||||
- Tabs
|
||||
- Segmented control
|
||||
- Status badge
|
||||
- Tag/chip
|
||||
- Tooltip
|
||||
- Popover
|
||||
- Dropdown menu
|
||||
- Dialog
|
||||
- Drawer
|
||||
- Sheet
|
||||
- Toast
|
||||
- Banner
|
||||
- Empty state
|
||||
- Skeleton
|
||||
- Loading indicator
|
||||
- Pagination
|
||||
- Command palette
|
||||
- Breadcrumb where genuinely useful
|
||||
- Page header
|
||||
- Section header
|
||||
- Chart container
|
||||
- Timeline
|
||||
- Task row
|
||||
- Notification row
|
||||
- AI suggestion / AI action component
|
||||
- Diff/review component
|
||||
|
||||
## Tables
|
||||
|
||||
Use tables as the default desktop presentation for Jobs because they support fast scanning and comparison.
|
||||
|
||||
Tables should support where useful:
|
||||
|
||||
- sorting,
|
||||
- filtering,
|
||||
- column visibility,
|
||||
- clear status badges,
|
||||
- keyboard accessibility,
|
||||
- responsive transformation.
|
||||
|
||||
Do not horizontally squeeze desktop tables into unusable mobile layouts.
|
||||
|
||||
## Cards
|
||||
|
||||
Use cards where they add value:
|
||||
|
||||
- dashboard metrics,
|
||||
- mobile job representation,
|
||||
- summary information,
|
||||
- documents/templates,
|
||||
- contextual recommendations.
|
||||
|
||||
Do not replace all tables with cards merely to look modern.
|
||||
|
||||
## Job view switch
|
||||
|
||||
Jobs page should provide a clear switch between:
|
||||
|
||||
- Table
|
||||
- Board
|
||||
|
||||
This should not feel like navigating to another feature.
|
||||
|
||||
## CV builder
|
||||
|
||||
Desktop preferred structure:
|
||||
|
||||
- editor/settings area,
|
||||
- live document preview.
|
||||
|
||||
The redesign should make this cleaner and more discoverable.
|
||||
|
||||
Recommended capabilities:
|
||||
|
||||
- drag/drop sections,
|
||||
- live pagination,
|
||||
- page boundaries,
|
||||
- zoom,
|
||||
- undo/redo,
|
||||
- version history where practical,
|
||||
- inline AI suggestions,
|
||||
- limited document styling,
|
||||
- easy template switching.
|
||||
|
||||
### CV visual controls
|
||||
|
||||
Keep customisation intentionally bounded:
|
||||
|
||||
- template,
|
||||
- accent colour,
|
||||
- font,
|
||||
- font size,
|
||||
- margins,
|
||||
- section spacing,
|
||||
- section order.
|
||||
|
||||
Avoid turning the builder into a general-purpose word processor.
|
||||
|
||||
## Motion
|
||||
|
||||
Target subtle-to-polished motion.
|
||||
|
||||
Use animation for:
|
||||
|
||||
- drawers,
|
||||
- dialogs,
|
||||
- view transitions,
|
||||
- hover/focus feedback,
|
||||
- Kanban movement,
|
||||
- skeleton/loading transitions,
|
||||
- expandable sections.
|
||||
|
||||
Typical interaction motion should be restrained and fast.
|
||||
|
||||
Respect `prefers-reduced-motion`.
|
||||
|
||||
## Icons
|
||||
|
||||
Use one consistent icon family.
|
||||
|
||||
Avoid mixing multiple visual icon styles.
|
||||
|
||||
## Branding and logo
|
||||
|
||||
A new logo is required.
|
||||
|
||||
The logo should work in:
|
||||
|
||||
- full wordmark,
|
||||
- compact sidebar mark,
|
||||
- favicon/app icon,
|
||||
- light mode,
|
||||
- dark mode.
|
||||
|
||||
Avoid a generic "AI sparkle" logo as the primary identity.
|
||||
Reference in New Issue
Block a user