cesnimda
181 lines
3.6 KiB
Markdown
181 lines
3.6 KiB
Markdown
# 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.
|