jobtrackingapp/docs/redesign/MASTER_REDESIGN_SPEC.md

Jobjakt — Master Redesign Specification

Consolidated source-of-truth specification for the planned full product redesign.

---

Product Vision

Vision

Jobjakt should be a modern career operating system for job seekers in Norway: a professional, supportive and highly usable SaaS product that combines job tracking, career profile management, CV creation, application support, interview preparation, analytics and contextual AI.

It should feel clean and easy to understand while still being information-rich enough that users can understand their job search at a glance.

The product should be suitable for everyone, not only technical users or experienced professionals.

Market focus

Primary market: Norway.

The product should use terminology, workflows and defaults that make sense for Norwegian job seekers. The architecture and design should not unnecessarily prevent international expansion, but Norway is the product's primary focus.

English and Norwegian localisation should remain first-class product capabilities.

Product positioning

Jobjakt should feel like:

• a professional career dashboard,
• a job-search command centre,
• a document and application workspace,
• an AI-assisted career tool,
• a personal analytics platform for the job-search process.

It should not feel like:

• a spreadsheet with a nicer UI,
• an AI chatbot with some job features,
• a cluttered ATS,
• an over-customisable design editor,
• a collection of unrelated pages.

Design inspiration

Useful reference products include:

• Huntr
• FlowCV
• Teal
• Prentus

The redesign should learn from their clarity, workflow organisation and SaaS polish without copying their visual identity.

Brand personality

The brand should be:

• professional,
• supportive,
• trustworthy,
• modern,
• calm,
• capable,
• encouraging without being childish or gamified.

AI should be visible as a capability, but it should not dominate the brand identity.

Core user promise

A user should be able to open Jobjakt and immediately understand:

• what they are currently applying for,
• what needs attention,
• what is happening next,
• how their job search is performing,
• which opportunities are the strongest matches,
• which CV/application materials are attached to each job,
• what Jobjakt recommends they do next.

Core product principles

1. Guide instead of overwhelm

The application should guide users toward sensible next actions rather than exposing every feature at once.

2. One source of truth

The Career Profile is the canonical source for the user's career information.

CVs, applications, cover letters and AI outputs should derive from it while allowing document-specific overrides.

3. Preserve user trust

User data must never be silently changed by AI.

4. Explainability over magic

AI recommendations should explain why they are being made and what source information they are based on.

5. High information value, low visual noise

The interface may be data-rich, but hierarchy, spacing, typography and grouping should keep it readable.

6. Customisable where it adds value

Users should be able to customise dashboards, density and relevant preferences.

The product should avoid offering unlimited styling controls that make the experience inconsistent or difficult to support.

7. Responsive by design

Mobile should be treated as a first-class experience, not merely a compressed desktop layout.

8. Existing functionality is protected

The redesign may restructure workflows, routes and UI components, but should not silently remove existing functionality.

Primary user journey

The intended default flow is:

Find/import job → Analyse job → Match against Career Profile → Tailor CV → Create/tailor application → Apply → Track progress → Prepare for interview → Record outcome → Learn from analytics

The product should surface the next logical action at each stage.

Success criteria

The redesign should be considered successful when:

• users can understand the main application structure without training,
• job details are clear rather than confusing,
• the CV builder is significantly easier to use,
• the application feels alive and polished without becoming visually noisy,
• users can scan meaningful job-search statistics quickly,
• AI feels native to the workflow,
• mobile workflows remain practical,
• existing functionality continues to work,
• light and dark modes both feel intentionally designed,
• spacing and component behaviour are consistent across the application.

---

Information Architecture

Navigation model

Use a collapsible left sidebar as the primary desktop navigation.

Navigation should be grouped into meaningful sections rather than presented as one flat list.

Recommended structure:

Home

• Dashboard

Job Search

• Jobs
• Analytics

Jobs should contain both table/list and Kanban/board views using a view switch. Kanban should not be a separate top-level navigation destination.

Career

• Career Profile
• CVs
• Documents
• Applications / Cover Letters if still required as a distinct workflow

Where possible, document-related features should converge under a clearer Documents area rather than creating many disconnected top-level pages.

Account

• Notifications
• Settings

Admin

Visible only to authorised administrators.

• Admin Dashboard
• Users / support tools if required
• Product analytics / operational controls if required

Global interaction areas

The application shell should include:

• global search / command palette,
• notifications,
• user/account menu,
• language control,
• appearance/theme control where appropriate,
• contextual AI entry point.

Command palette

Provide a global Ctrl+K / Cmd+K command palette.

It should be able to:

• search jobs,
• search companies,
• search CVs,
• search documents,
• navigate to pages,
• create a job,
• create a CV,
• open Career Profile,
• toggle appearance,
• change language,
• invoke context-relevant commands.

Page hierarchy

Dashboard

Personal overview of the user's job search, goals, tasks, deadlines, activity and analytics.

Jobs

Single consolidated workspace with:

• Table view
• Board/Kanban view
• Search
• Filters
• Saved view preferences
• Add/import job

Desktop default: table.

Mobile default: card/list representation.

Job Detail

Use a dedicated page for full job detail.

Recommended top-level structure:

• Overview
• Match
• Application
• Documents
• Timeline
• Notes / Tasks

Exact grouping may change during UX implementation, but all information should feel like parts of one job workspace rather than unrelated pages.

Optional enhancement: a quick-preview side drawer from the Jobs page with a clear action to open the full job page.

Career Profile

The canonical user career dataset.

Suggested sections:

• Personal information
• Professional summary
• Work history
• Education
• Skills
• Technologies
• Languages
• Certifications
• Projects
• Achievements
• Preferences
• Desired roles
• Location preferences
• Remote preferences
• Salary expectations where applicable

CVs

Library of CV variants generated from the Career Profile.

CV-specific content overrides must not silently modify the master Career Profile.

Documents

Unified document workspace containing, where applicable:

• CVs
• Cover letters
• Application answers
• References
• Certificates
• Other attachments

Documents should show relationships to jobs where relevant, e.g. "Used for Kongsberg — Software Developer".

Analytics

Deeper job-search analytics beyond the dashboard.

Notifications

In-app notification centre with links back to relevant jobs, tasks, deadlines, interviews and documents.

Settings

Suggested sections:

• Account
• Profile preferences
• Language
• Appearance
• Dashboard preferences
• Notification preferences
• Email preferences
• Privacy / data
• Subscription / billing if applicable

Avoid unnecessary top-level pages

The redesign should actively identify pages that can be merged into coherent workspaces.

A feature should not receive a top-level route merely because it currently has one.

---

UX Flows

Core philosophy

The user should usually know what to do next.

Jobjakt should not simply display information. It should guide users through a sensible career workflow while allowing experienced users to move freely.

Primary job workflow

Step 1 — Add or import job

User can:

• add manually,
• import from a supported URL,
• paste job content where appropriate.

After import, Jobjakt should confirm what was captured and show any fields that need review.

Step 2 — Analyse job

System extracts and structures useful job information such as:

• role,
• employer,
• location,
• employment type,
• salary where available,
• deadline,
• requirements,
• desired skills,
• responsibilities,
• useful keywords.

Step 3 — Compare with Career Profile

Present:

• overall match,
• strong matches,
• partial matches,
• missing or unverified requirements,
• relevant experience,
• suggested areas to emphasise.

Never convert an unknown or missing skill into a claimed skill.

Step 4 — Suggested next action

Example:

82% profile match

Recommended next step:

Tailor your CV for this role

Provide a clear CTA while allowing users to ignore it.

Step 5 — Tailor CV

User selects an existing CV or creates a job-specific variant.

AI can suggest:

• reordering skills,
• emphasising relevant experience,
• shortening irrelevant material,
• rewriting content using only known facts.

All AI changes require preview/review before application.

Step 6 — Application material

User creates or edits:

• cover letter,
• application answers,
• supporting documents.

Step 7 — Apply

When status changes to Applied, Jobjakt should be able to record:

• application date,
• CV used,
• cover letter used,
• source,
• optional notes.

Step 8 — Track

Job page should become the ongoing source of truth for:

• status,
• tasks,
• deadlines,
• contacts,
• notes,
• events,
• interviews,
• documents,
• timeline.

Step 9 — Interview preparation

When a job reaches an interview stage, surface relevant actions such as:

• prepare likely questions,
• research company,
• review job requirements,
• review personal examples,
• create preparation notes,
• add interview event.

Step 10 — Outcome

Record:

• offer,
• rejection,
• withdrawal,
• acceptance,
• other final status.

Use outcome data for personal analytics without shaming or gamifying the user.

Job detail UX

Use a dedicated page with a clear hierarchy.

Suggested header:

• Role title
• Company
• Location / work mode
• Current status
• Priority / favourite
• Match score
• Deadline
• Key actions

Suggested tab or section model:

Overview

• description summary,
• role details,
• important requirements,
• salary/deadline/location,
• next recommended action.

Match

• overall score,
• matched requirements,
• gaps,
• supporting evidence from Career Profile,
• suggested CV emphasis.

Application

• current application status,
• application date,
• application material,
• answers / cover letter,
• submission information.

Documents

• CV used,
• cover letter,
• attachments,
• generated variants.

Timeline

Chronological history of:

• status changes,
• notes,
• messages,
• interviews,
• tasks,
• document generation,
• relevant events.

Tasks / Notes

May be a dedicated section or integrated into Overview/Timeline depending on final usability testing.

Status model

Provide sensible default statuses, with user-configurable custom statuses.

Suggested defaults:

• Interested
• Preparing
• Applied
• Screening
• Interview
• Final Interview
• Offer
• Accepted
• Rejected
• Withdrawn

Customisation should preserve analytics by mapping custom statuses to broader system categories where needed.

Tasks and reminders

Users should be able to attach tasks to jobs.

Examples:

• Follow up with recruiter
• Prepare interview examples
• Submit application before deadline
• Update CV

Tasks should support due dates and notifications.

Events

Jobs may be linked to events such as:

• interview,
• recruiter call,
• deadline,
• follow-up,
• networking event,
• career fair.

A future calendar integration should be possible without requiring it in the first redesign phase.

Onboarding

New user flow:

1. What are you looking for?
2. Import/upload an existing CV if available.
3. Build/review Career Profile.
4. Add first job.
5. Arrive at personalised dashboard.

The first question may also support aggregate analytics, but it should still provide user value where possible.

Goals

Allow optional weekly goals, but avoid language that makes the user feel they have failed.

Better framing:

• "Weekly target"
• "Your pace"
• "Application goal"

Avoid aggressive streak mechanics or punitive red states.

Goals should be optional and editable.

---

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.

---

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.

---

AI Principles

Non-negotiable rule

AI MUST NOT INVENT USER FACTS.

It must never fabricate or silently imply:

• skills,
• technologies,
• qualifications,
• education,
• certifications,
• work history,
• job titles,
• responsibilities,
• achievements,
• metrics,
• projects,
• languages,
• dates,
• salary history,
• personal details,
• experience the user has not provided.

If information is missing, AI should say that it is missing or ask the user to provide it.

Source of truth

The Career Profile is the canonical source of user career information.

AI may also use information explicitly supplied in the current workflow, such as:

• a job description,
• user-entered notes,
• an uploaded document,
• a CV-specific override.

AI must preserve provenance wherever practical.

Example

Bad:

Added Kubernetes experience because the job requires it.

Good:

Kubernetes appears in the job requirements, but it is not present in your Career Profile. I have not added it to your CV.

AI interaction model

Use a hybrid model:

1. Contextual actions beside content.
2. A persistent or easily opened contextual assistant.
3. Command-palette AI actions where useful.

Avoid creating a disconnected AI area that forces users to leave their workflow.

Contextual awareness

The AI assistant should understand what the user is currently working on.

Examples:

On a Job page

• How good a match am I?
• What requirements am I missing?
• What should I emphasise on my CV?
• Prepare interview questions.
• Help me research this role/company.
• Draft a follow-up message.

In a CV

• Make this shorter.
• Make this more natural.
• Tailor this to the selected job.
• Check for unsupported claims.
• Improve readability.

In Career Profile

• Suggest missing details to add.
• Improve wording without changing facts.
• Identify duplicate information.

Review before apply

AI-generated modifications to user-owned content must not be applied silently.

Show a preview or diff before committing changes.

Minimum actions:

• Accept
• Reject

Where practical:

• Accept individual change
• Accept all
• Edit before applying

Evidence

For match analysis, AI should make it clear which Career Profile item supports a claim.

Example:

Strong match: C# / .NET

Evidence:

Work history → Analyst Programmer → C#/.NET backend development

Match scoring

If a numeric match score is shown:

• explain major contributors,
• distinguish required vs preferred criteria where possible,
• do not imply mathematical precision beyond the underlying method,
• do not penalise unknown information as though it were definitely absent unless the product logic explicitly chooses to do so.

User control

Users should be able to:

• disable or ignore suggestions,
• review AI output,
• edit output,
• understand whether content was AI-assisted.

Tone

AI should be:

• professional,
• supportive,
• concise,
• practical,
• non-judgmental.

Avoid exaggerated motivational language.

Privacy and logging

AI-related data handling should be explicitly documented during implementation.

Do not assume that all user content may be retained indefinitely.

Any future analytics about AI usage should prefer aggregate product metrics and avoid exposing private career content to administrators unless required and authorised.

---

Responsive Design and Accessibility

Principle

Mobile should be as capable as reasonably possible, but it does not need to visually imitate desktop.

Responsive design should transform workflows when necessary rather than simply shrinking them.

Breakpoint strategy

Use content-driven breakpoints based on when layouts stop working effectively.

Do not design around a single desktop resolution.

Test at minimum:

• small mobile,
• large mobile,
• tablet portrait,
• tablet landscape,
• laptop,
• desktop,
• wide desktop.

Mobile navigation

Desktop sidebar should transform into a mobile-specific navigation pattern.

Likely options:

• bottom navigation for major destinations,
• a secondary menu for less frequent destinations,
• contextual top bar actions.

Final decision should be validated against the number of important destinations.

Jobs

Desktop:

• table by default,
• board available.

Mobile:

• cards or structured list,
• essential job information visible immediately,
• filters in a mobile sheet/drawer,
• board may remain available if usable, but should not be forced if it becomes cumbersome.

Job detail

Use stacked mobile sections with a sticky or easy-to-access action area.

Avoid tiny multi-column layouts.

Dashboard

Desktop:

• resizable/reorderable grid.

Mobile:

• single-column widget feed,
• reorder/hide still supported where practical,
• resize controls may be omitted if they do not make sense.

CV builder

Desktop can use editor + live preview side by side.

Mobile should use an alternate workflow, for example:

• Edit mode
• Preview mode

Do not force a two-pane desktop editor onto a phone.

Forms

• clear labels,
• adequate touch targets,
• errors close to fields,
• preserve entered data on validation failure,
• avoid unnecessary modal nesting,
• support browser autofill where appropriate.

Keyboard accessibility

Desktop users should be able to:

• navigate controls with keyboard,
• operate menus/dialogs,
• use command palette,
• dismiss dialogs with Escape where appropriate,
• understand visible focus state.

Screen readers

Use semantic HTML and correct ARIA only where needed.

Do not use ARIA as a substitute for semantic structure.

Contrast

Light and dark modes must meet appropriate contrast requirements for:

• text,
• icons,
• buttons,
• status indicators,
• focus states,
• disabled states.

Colour independence

Status must not rely on colour alone.

Use text/icon/shape cues as well.

Motion

Respect reduced-motion settings.

Essential state changes should remain understandable without animation.

Localisation

Test both English and Norwegian throughout the responsive UI.

Norwegian text may be longer than English in some areas; layouts must tolerate this.

Avoid hard-coded control widths that only fit English labels.

Content stress testing

Test with:

• very long company names,
• long job titles,
• long Norwegian labels,
• missing data,
• large numbers of jobs,
• zero jobs,
• many status values,
• long CV content,
• multiple-page CVs.

---

Functional Guardrails

Purpose

The redesign must preserve existing functionality while allowing the UX and frontend architecture to change substantially.

Rule 1 — Inventory before redesign

Before major implementation work begins, create an explicit inventory of:

• routes,
• pages,
• dialogs,
• forms,
• workflows,
• API calls,
• state transitions,
• authentication flows,
• localisation behaviour,
• permissions,
• user settings,
• admin capabilities,
• document workflows,
• AI actions,
• mobile/responsive behaviour,
• tests.

Rule 2 — No silent feature removal

A feature discovered during the inventory must not disappear merely because it does not fit the new design.

It must be one of:

• preserved,
• relocated,
• merged into another workflow,
• intentionally deprecated with an explicit documented decision.

Rule 3 — Protect backend contracts

Do not change backend/API contracts purely to make frontend work easier unless there is a clear architectural reason.

Any required contract change must be documented and tested.

Rule 4 — Add regression protection

Before replacing high-risk UI flows, add or strengthen tests around their functional behaviour.

Prioritise:

• authentication,
• registration,
• Career Profile,
• job creation/import/edit/status,
• CV creation/edit/export,
• document relationships,
• AI review/apply flow,
• localisation,
• permissions/admin boundaries.

Rule 5 — Preserve user data

Frontend redesign work must not change the meaning or ownership of stored user data without an explicit migration.

Rule 6 — Career Profile remains canonical

Any redesign of CV/application flows must preserve the distinction between:

• Career Profile source data,
• CV-specific overrides,
• generated output.

Rule 7 — AI cannot bypass review

No redesign may introduce an AI action that silently writes career claims into user data.

Rule 8 — Maintain localisation

New components and screens must support both English and Norwegian.

Do not hard-code user-facing strings in new components if the current architecture supports localisation.

Rule 9 — Maintain access controls

Admin-only features must remain permission-gated.

User-level dashboard customisation and job/document data must remain tenant/user scoped.

Rule 10 — Visual QA is part of completion

A feature is not complete when tests pass but the responsive UI is broken.

Each migrated area should be inspected in:

• light mode,
• dark mode,
• desktop,
• mobile,
• English,
• Norwegian.

Pre-redesign checkpoint

Before full redesign implementation:

1. Finish current functional work.
2. Run tests.
3. Resolve known critical regressions.
4. Commit a stable baseline.
5. Create a tag or branch checkpoint such as pre-ui-redesign.
6. Create a redesign branch such as feature/ui-redesign.

---

Implementation Plan

Strategy

Do not rewrite the entire frontend in one uncontrolled change.

Use a phased migration with explicit checkpoints.

Phase 0 — Finish product functionality

Before the visual/UX redesign begins:

• finish current functional changes,
• avoid spending excessive time polishing legacy visual styling,
• stabilise backend/data-model behaviour,
• run tests,
• create a pre-redesign checkpoint.

Phase 1 — Audit

No broad design changes.

Inspect and document:

• frontend framework and build setup,
• current styling solution,
• component libraries,
• routing,
• state management,
• authentication,
• localisation,
• API integration,
• test setup,
• every current feature and workflow.

Deliverables:

• technical frontend audit,
• functionality inventory,
• route/page map,
• component inventory,
• risk list,
• proposed migration approach.

Phase 2 — Functional baseline

Add or improve regression coverage around critical workflows before changing them.

Deliverables:

• stable baseline tests,
• known failing tests documented,
• explicit protected-functionality checklist.

Phase 3 — UX architecture

Define the target product shell and information architecture.

Deliverables:

• sidebar structure,
• page hierarchy,
• route migration plan,
• job workflow,
• Career Profile workflow,
• CV workflow,
• dashboard architecture,
• contextual AI pattern,
• responsive interaction model.

Avoid large implementation until this architecture is coherent.

Phase 4 — Design system foundation

Implement shared tokens/components:

• colour tokens,
• typography,
• spacing,
• radii,
• shadows,
• motion,
• light/dark themes,
• form controls,
• buttons,
• tables,
• dialogs/drawers,
• empty/loading/error states,
• page layout primitives.

The agent may replace the current UI/component layer if doing so materially improves maintainability and consistency.

Phase 5 — Representative screens

Implement only the most representative areas first:

1. App shell/sidebar
2. Dashboard
3. Jobs workspace
4. Job detail
5. CV builder

Use these to validate the design language before migrating the entire application.

Phase 6 — Review checkpoint

Before broad rollout, inspect:

• consistency,
• usability,
• density,
• dark mode,
• mobile,
• Norwegian localisation,
• AI patterns,
• component reuse,
• performance.

Fix system-level issues now rather than replicating them across every page.

Phase 7 — Full migration

Migrate remaining areas, including:

• authentication,
• onboarding,
• Career Profile,
• CV library,
• Documents,
• application/cover-letter workflows,
• Analytics,
• Notifications,
• Settings,
• Admin,
• error pages,
• empty states,
• remaining dialogs and forms.

Phase 8 — Dashboard customisation

Implement per-user dashboard configuration:

• visibility,
• ordering,
• resizing where supported,
• reset defaults,
• persistence.

Admin dashboard remains separate.

Phase 9 — QA

Run:

• automated regression tests,
• visual inspection,
• responsive inspection,
• keyboard/accessibility checks,
• English/Norwegian checks,
• light/dark checks,
• empty/large-data edge cases,
• document/CV pagination checks.

Phase 10 — Cleanup

Remove only genuinely obsolete legacy UI code after:

• confirming no route still uses it,
• confirming tests pass,
• confirming functionality inventory is satisfied.

Branching recommendation

Suggested:

• stable branch/tag: pre-ui-redesign
• working branch: feature/ui-redesign

Use smaller commits grouped by system/component or migrated workflow.

---

Open Decisions

These items are intentionally not locked yet.

1. Product name

Current name: Jobjakt.

Desired direction:

• Norwegian or Scandinavian identity,
• professional,
• supportive,
• suitable for a commercial SaaS,
• capable of representing more than job tracking alone.

Potential naming direction:

• Norwegian-first name,
• Scandinavian-sounding name that is internationally usable.

Do not rename the product during the redesign without an explicit decision.

2. Logo

A new logo is required.

Requirements:

• works as wordmark and compact icon,
• works in light/dark modes,
• professional rather than playful,
• not a generic AI sparkle mark.

3. Primary brand colour

One primary brand colour should anchor the UI.

Exact colour is not yet chosen.

4. Default language

English and Norwegian should remain first-class.

The exact default language behaviour should be confirmed before final launch if the current application does not already define it.

5. Email delivery service

Required capability:

• secure transactional email from the application/server,
• notification emails,
• account/verification emails where applicable.

Provider and infrastructure choice should be made separately based on security, deliverability, cost and operational requirements.

Do not build an ad-hoc unauthenticated SMTP relay.

6. Calendar integration

Desired future direction:

Allow job-related events such as interviews, deadlines and follow-ups to connect to calendar events.

The initial redesign should model events cleanly enough that calendar integration can be added later.

7. Job-goal defaults

Weekly goals should be optional and supportive.

Do not hard-code a universal "correct" number of applications per week without a separate product decision.

8. Job quick preview

Preferred direction:

• full dedicated Job Detail page,
• optional quick-preview drawer from Jobs.

The preview drawer should only be implemented if it improves scanning without duplicating excessive UI.

9. Frontend component/styling stack

The coding agent should first identify the current stack.

It may recommend replacing or standardising the UI layer, but the choice should be justified by:

• maintainability,
• accessibility,
• consistency,
• migration cost,
• bundle/runtime impact,
• developer ergonomics.