262 lines
4.6 KiB
Markdown
262 lines
4.6 KiB
Markdown
# 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.
|