docs(redesign): record product brief and phased audit handoff

docs/redesign/DASHBOARDS.md

@@ -0,0 +1,180 @@
+# Dashboards
+
+## Personal dashboard
+
+The dashboard is the user's personal command centre.
+
+It should be information-rich while remaining easy to scan.
+
+## Customisation
+
+The dashboard should support per-user customisation:
+
+- show/hide widgets,
+- drag/reorder widgets,
+- resize widgets where practical,
+- remember layout per user,
+- reset to default layout,
+- provide a sensible default that initially shows all major information.
+
+Avoid allowing arbitrary styling that breaks consistency.
+
+## Candidate widget library
+
+### Headline metrics
+
+- Active applications
+- Total applications
+- Applications this week
+- Applications this month
+- Interviews
+- Upcoming interviews
+- Offers
+- Rejections
+- Response rate
+- Interview conversion rate
+- Offer conversion rate
+- Average match score
+
+### Funnel and status
+
+- Application funnel
+- Applications by status
+- Time in each stage
+- Average time to first response
+
+### Trends
+
+- Applications over time
+- Interviews over time
+- Offers over time
+- Response-rate trend
+- Match-score trend
+
+### Breakdown widgets
+
+- Applications by company
+- Applications by industry/sector
+- Applications by role
+- Applications by location
+- Applications by source
+- Applications by work mode
+
+### CV/document performance
+
+- CVs used
+- Applications per CV
+- Best-performing CV by interview conversion
+- Recently edited CVs
+
+Performance metrics must clearly state that they show correlation, not proof that a specific CV caused an outcome.
+
+### Action widgets
+
+- Upcoming deadlines
+- Upcoming interviews
+- Tasks due
+- Follow-ups due
+- Recent activity
+- Jobs needing attention
+
+### Opportunity widgets
+
+- Highest matching jobs
+- Recently added jobs
+- Jobs with approaching deadlines
+
+### Goal widgets
+
+Optional weekly application target.
+
+Example:
+
+`6 of 8 applications this week`
+
+Use supportive wording.
+
+Never imply that applying to a fixed number of jobs is inherently correct for every user or every week.
+
+### AI widgets
+
+- Recommended next actions
+- Jobs where the CV could be improved
+- Jobs with missing application material
+- Interview-preparation recommendations
+
+AI recommendations must remain grounded in known data.
+
+## Dashboard layout behaviour
+
+### Desktop
+
+Use a flexible grid with meaningful widget sizes.
+
+### Tablet
+
+Reduce available columns while preserving user priorities.
+
+### Mobile
+
+Convert the dashboard to a single-column ordered feed.
+
+Allow users to reorder/hide widgets on mobile, but complex resize controls may be desktop-only if necessary.
+
+## Empty state
+
+A new user's dashboard should not look broken or empty.
+
+Use guided empty states:
+
+- Add your first job
+- Import your CV
+- Complete your Career Profile
+
+## Admin dashboard
+
+Admins should receive a separate aggregate product dashboard.
+
+Do not mix personal job-search widgets with administrator analytics.
+
+### Suggested aggregate metrics
+
+- Registered users
+- Active users
+- New users
+- Trial users
+- Paid users when billing exists
+- Total tracked jobs
+- Applications created
+- Interviews recorded
+- Offers recorded
+- CVs created
+- Documents generated
+- AI actions/requests
+
+### Aggregate breakdowns
+
+- Popular sectors
+- Popular role families
+- Popular locations
+- Common technologies/skills
+- Job sources
+
+### Product metrics
+
+When available:
+
+- onboarding completion
+- registration conversion
+- trial conversion
+- paid conversion
+- churn
+- feature adoption
+
+## Privacy rule
+
+Admin analytics should default to aggregate/anonymised information.
+
+Individual user career data should not be exposed merely because an administrator can access the admin dashboard.
+
+Any support-oriented individual-data access should be separately justified, permission-controlled and auditable.