jobtrackingapp/automation/prompts/prompt 9 UI/prompt 9.1.txt

# JOBBJAKT — COMPLETE PRODUCT DESIGN, UX MODERNISATION & RELEASE MASTER PLAN

## YOUR ROLE

Act as an expert multidisciplinary team consisting of:

- Principal SaaS product designer
- UX researcher and information architect
- Senior visual and interaction designer
- Design-system architect
- React/TypeScript frontend engineer
- Accessibility specialist
- Mobile UX specialist
- .NET backend engineer
- Application security engineer
- QA and test automation engineer
- DevOps and release engineer

Your mission is to transform Jobbjakt into a modern, polished, intuitive, accessible and production-ready job-search SaaS product.

However, we are NOT ready to commit to a particular redesign.

You must first help me discover what I want through research, examples, questions, multiple visual mockups, component-level selection and repeated refinement.

This is a collaborative, iterative design process.

I am the final decision-maker.

**Do not implement a full production redesign until I explicitly approve the final design and implementation roadmap.**

---

# 1. PROJECT CONTEXT

Jobbjakt is a job-search management platform.

Its existing capabilities and planned areas include:

- Dashboard
- Job application tracking
- Job discovery
- Application lists and Kanban
- Application details and timelines
- Correspondence and email integrations
- Calendar and reminders
- CV creation, editing, importing and exporting
- Cover letters
- Career profile
- AI-assisted features
- Analytics
- Account settings
- Authentication and OAuth
- Administrative features
- English and Norwegian support
- Light and dark themes
- Mobile and desktop experiences

The existing technology stack includes React, TypeScript, MUI, Emotion, .NET, Entity Framework Core, MariaDB, Docker and additional supporting services.

Verify the actual implementation against the repository.

Do not assume that every planned feature is implemented.

Distinguish current functionality, partially implemented functionality and future proposals.

Review existing redesign documentation, FlowCV research, architecture decisions, test coverage and release-readiness work.

Preserve existing capabilities and previous accepted implementation work.

---

# 2. APPROVED PRODUCT VISION

These decisions have already been made.

Do not ask me to repeat them.

## Target audience

Jobbjakt is for EVERYONE looking for employment.

This includes:

- Students
- Graduates
- Experienced professionals
- Career changers
- People returning to employment
- Occasional job seekers
- People managing many applications
- Users with different technical abilities

Make the product approachable for beginners while remaining efficient for advanced users.

## Visual direction

The desired aesthetic is a hybrid of:

- Linear — precision, navigation, restraint and efficiency.
- Attio — data management, tables and contextual interaction.
- Notion — whitespace, typography and open content layouts.
- FlowCV — focused CV editing and preview workflows.
- Huntr and Teal — relevant job-search workflows.

Create Jobbjakt's own distinctive identity.

Do not clone existing products.

## Information density

Balanced.

Use information-dense layouts where appropriate, without making the experience cramped.

Allow breathing room where it improves clarity.

## Containers and visual grouping

I strongly dislike excessive use of cards, borders, panels, shadows and nested boxes.

Prefer:

- Typography
- Whitespace
- Alignment
- Subtle dividers
- Logical content grouping
- Restrained colour
- Meaningful contextual surfaces

Use cards and panels only when they genuinely improve usability.

Do not remove useful structure merely to reduce card counts.

## Navigation

You may completely reconsider navigation, sidebar organization, page headers and information architecture.

I want the best user experience, not necessarily the current structure.

## First-time user experience

New users should land on the dashboard after required authentication.

They should then have access to guided but OPTIONAL setup.

Onboarding must be:

- Skippable
- Resumable
- Non-blocking
- Helpful
- Accessible
- Appropriate for mobile and desktop

## Intelligent assistance

Jobbjakt should proactively help users understand their next actions.

Examples include:

- Suggested application follow-ups
- Upcoming interviews
- Unfinished applications
- CV improvements
- Application deadlines
- Relevant next tasks

Keep suggestions useful, accurate and dismissible.

Avoid excessive notifications or artificial urgency.

## Automations

I want useful automation capabilities.

Users must be able to control automations individually.

For example:

- Automatic job-detail extraction
- Follow-up suggestions
- Interview reminders
- AI-assisted CV suggestions
- Relevant next-action recommendations

Provide separate enable/disable controls and explain their consequences.

Distinguish suggestions from automatically executed actions.

External consequential actions require appropriate explicit authorization.

Never silently submit job applications or send emails.

## Mobile

Mobile is JUST AS IMPORTANT as desktop.

Important workflows must be fully usable on both.

Do not create a desktop-first product and simply shrink it for mobile.

## Accessibility

Target WCAG 2.2 AA throughout.

Accessibility must guide design decisions from the beginning.

---

# 3. NON-NEGOTIABLE WORKFLOW RULES

Follow this process:

DISCOVER → INTERVIEW → RESEARCH → GENERATE → COMPARE → SELECT → REFINE → APPROVE → PROTOTYPE → IMPLEMENT → TEST → RELEASE QUALIFICATION

Do not skip stages.

Important rules:

1. Ask me meaningful questions throughout the process.
2. Do not repeat questions I have already answered.
3. Present concrete alternatives rather than vague questions.
4. Recommend a default when appropriate.
5. Explain important tradeoffs.
6. Let me choose components from different designs.
7. Maintain a persistent record of my preferences.
8. Generate revised mockups based on my feedback.
9. Continue iterating without an arbitrary round limit.
10. Do not mistake a preference for final approval.
11. Stop at defined approval checkpoints.
12. Do not change production or merge into main/master without explicit authorization.
13. Do not push changes to remote repositories without my permission.
14. Use a dedicated development branch and isolated design workspace.
15. Never invent test results, research findings or application features.

You may create experimental frontend components inside the isolated design workspace without requiring full redesign approval.

Do not replace production UI components during the exploration stage.

---

# 4. PHASE 0 — REPOSITORY DISCOVERY

Begin by examining the entire repository.

Identify:

- Current frontend architecture
- Route inventory
- Navigation structure
- Design tokens
- Themes
- Shared components
- Layout patterns
- Localization
- Responsive behavior
- Accessibility implementation
- Existing browser tests
- Existing redesign documentation
- Previous UX research
- Important user journeys
- Current release blockers

If browser automation is available, inspect the rendered application.

Use realistic synthetic data for experimental work.

Capture screenshots of representative existing screens.

Identify:

- Major UX friction
- Excessive visual containers
- Inconsistent navigation
- Unclear primary actions
- Repetitive data entry
- Weak responsive layouts
- Missing interaction feedback
- Accessibility concerns
- Opportunities to simplify journeys

Produce an initial current-state assessment.

Do not immediately rewrite components.

---

# 5. PHASE 1 — INTERVIEW ME

Before creating the first visual design round, ask me targeted questions.

You are explicitly instructed to INTERVIEW ME as a product designer would interview a client.

Do not simply present a questionnaire and proceed without waiting for answers.

## Question rules

Ask approximately 3–5 related questions per batch.

Each question should include:

- What decision you need.
- Two or more meaningful options where appropriate.
- Examples from real SaaS products when useful.
- The advantages and disadvantages.
- Your recommended default, if you have one.
- An opportunity for me to give my own answer.

Use images, references or comparative mockups when possible.

Avoid overly technical terminology unless necessary.

## Possible unresolved topics

- Existing Jobbjakt branding to preserve.
- Preferred sidebar behavior.
- Dashboard content priority.
- Preferred navigation grouping.
- How prominent AI assistance should be.
- Preferred application detail layouts.
- How guided onboarding should be presented.
- Mobile navigation preferences.
- How much dashboard customization users need.
- Which existing screens I particularly dislike.
- Which existing features I want visually emphasized.

Only ask questions that remain genuinely unresolved after repository discovery.

Do not ask whether I want mobile support, guided optional onboarding, balanced density, automation controls or a complete UX review. Those preferences are already established.

## Interview checkpoint

After asking a batch of questions:

STOP.

Wait for my answers.

Update the design decision log.

Then proceed to the next necessary batch or first design round.

Do not automatically invent answers.

---

# 6. PHASE 2 — SAAS DESIGN RESEARCH

Research useful design patterns from:

- Linear
- Attio
- Notion
- FlowCV
- Huntr
- Teal

Research additional relevant products where beneficial.

Focus on:

- Navigation
- Dashboards
- Data tables
- Kanban boards
- Application details
- Onboarding
- CV/document editors
- Contextual actions
- Mobile interaction
- Settings
- Automation preferences
- Accessible interaction design

For each reference, explain:

1. What the product does well.
2. What specific pattern is relevant.
3. Which Jobbjakt feature could benefit.
4. Why the pattern works.
5. Potential disadvantages.
6. Accessibility considerations.
7. How it could be adapted into an original Jobbjakt design.

Use verifiable sources and actual product references where available.

Do not fabricate product behavior or claim to have inspected interfaces you could not access.

Research should inform design decisions, not dictate them.

---

# 7. PHASE 3 — BUILD A VISUAL DESIGN LAB

Create an isolated development-only design workshop.

Preferred route:

/design-lab

Use the existing React/TypeScript/MUI/Emotion stack where practical.

The design lab must not alter the existing production UI.

It should support:

- Concept gallery
- Full-screen preview
- Side-by-side comparison
- Desktop preview
- Mobile preview
- Light/dark mode switching
- English/Norwegian switching
- Example user-data states
- Individual component comparisons
- Design-selection controls
- Notes and feedback
- Iteration history
- Previously selected components
- Approved/rejected design decisions

Use realistic Jobbjakt data.

Mockups should be rendered as real UI whenever practical, not just images.

Provide screenshots as supplementary evidence.

Clearly label simulated functionality.

Keep experiments isolated from production data and services.

If the existing application cannot safely host a design lab, propose an isolated local alternative.

Do not expose design-lab routes in production.

---

# 8. PHASE 4 — GENERATE FIVE INITIAL DESIGNS

Create FIVE genuinely distinct visual design concepts.

Use stable IDs.

A1 — Refined Minimal
B1 — Data-Focused Professional
C1 — Open and Spacious
D1 — Premium Balanced
E1 — Creative Wildcard

These must differ meaningfully in layout, typography, navigation, information hierarchy, spacing and interaction patterns.

Do not simply change colours.

## Initial scope

For each design, create:

1. Main application navigation and shell.
2. Dashboard with realistic populated data.
3. New-user dashboard with optional onboarding.
4. Mobile dashboard and navigation.
5. Light and dark theme variants.

Keep the same underlying sample data across designs so comparisons are fair.

Include at least one important task-oriented interaction in each design.

Make the designs sufficiently realistic to judge how the actual application might feel.

## Evaluate each design

For every concept, explain:

- Its overall design philosophy.
- What makes it different.
- Its strengths.
- Its weaknesses.
- Suitability for Jobbjakt.
- Accessibility implications.
- Mobile implications.
- Estimated implementation complexity.

## Mandatory checkpoint

After generating the five concepts:

STOP.

Show me how to access them.

Ask what I like and dislike.

Do not begin the next iteration until I respond.

---

# 9. PHASE 5 — COMPONENT-LEVEL DESIGN SELECTION

Allow me to select individual aspects from different concepts.

I may prefer:

- Sidebar from B1
- Typography from C1
- Dashboard structure from D1
- Buttons from A1
- Mobile navigation from E1

These selections must be combinable.

Support comparisons and selections for:

- Application shell
- Sidebar
- Mobile navigation
- Page header
- Typography
- Colour palette
- Spacing
- Buttons
- Forms
- Tables
- Lists
- Kanban cards
- Dashboard metrics
- Next-action section
- Icons
- Dialogs
- Drawers
- Empty states
- Loading states
- Settings
- CV editor patterns

Provide a simple component-selection board if feasible.

Do not require me to select a single complete design.

## Feedback types

Support:

- Keep
- Change
- Reject
- Show alternatives
- Combine with another concept
- Provisionally prefer
- Approve

Treat these as different decisions.

Never treat "I like this" as approval of everything else in the concept.

---

# 10. PHASE 6 — ITERATIVE DESIGN REFINEMENT

After each feedback round:

1. Read my latest feedback.
2. Read the existing design decision register.
3. Preserve approved or preferred elements where appropriate.
4. Identify conflicting selections.
5. Explain conflicts briefly.
6. Generate THREE refined concepts by default.
7. Show side-by-side comparisons.
8. Provide updated mobile and desktop variants.
9. Ask 3–5 focused follow-up questions.
10. STOP for feedback.

Use stable version identifiers:

A2, B2, C2, etc.

Maintain design history.

Do not overwrite old concepts.

If I request five additional variations of one component, generate them without changing unrelated approved elements.

If I reject a particular design property, do not repeatedly reintroduce it without a good reason.

Do not force convergence prematurely.

Continue until I explicitly approve a coherent design direction.

---

# 11. PHASE 7 — COMPLETE APPLICATION DESIGN

After provisional approval of the visual foundation, expand the design across all existing major Jobbjakt interfaces.

Include where implemented:

- Dashboard
- Navigation
- Authentication
- Registration
- Onboarding
- Application lists
- Kanban
- Application details
- Job discovery
- Calendar
- Reminders
- Correspondence
- CV management
- CV editor
- CV import
- CV export
- Cover letters
- Career profile
- Analytics
- AI-assisted workflows
- Settings
- Automation Centre
- Administration
- Public/marketing interfaces

Do not assume approving the dashboard means all other pages are approved.

For major screens, show multiple layout alternatives where useful.

Continue asking me questions and refining each area.

Maintain one coherent design language.

Avoid unnecessary boxed layouts.

Ensure each major experience works on mobile and desktop.

---

# 12. PHASE 8 — REDESIGN COMPLETE USER JOURNEYS

Do not modernise pages in isolation.

Evaluate complete user journeys.

## Journey A — First-time onboarding

Registration → Dashboard → Optional setup → CV/profile → First application → Normal dashboard.

Provide:

- Clear first-use guidance
- Optional checklist
- Skip/resume controls
- Progress preservation
- Useful empty states
- Non-blocking setup
- Smooth transition into regular usage

## Journey B — Application management

Discover/add job → Save details → Create application → Prepare documents → Track application → Follow-up → Interview → Outcome.

Provide:

- Minimal unnecessary data entry
- Contextual record details
- Search/filter/sort
- List and Kanban views
- Clear status changes
- Reminders
- Next actions
- Useful error recovery

## Journey C — CV and career tools

Import/create CV → Edit → Preview → Tailor for a job → Review AI suggestions → Export → Reuse for applications.

Provide:

- Focused editing
- Responsive layouts
- Live preview where feasible
- Clear saving feedback
- Accessible section navigation
- User-controlled AI assistance
- Reliable export workflow

## Journey D — Everyday return visit

Login → Review next actions → Handle priorities → Update progress → Continue job search.

The dashboard should proactively surface meaningful, actionable information.

## Journey E — Automation management

View available automations → Understand consequences → Enable/disable individually → Configure notifications → Review results → Correct errors.

Distinguish suggestions, internal automatic actions and externally consequential actions.

Do not perform external actions without appropriate authorization.

## Other journeys

Discover and evaluate additional meaningful workflows in the repository.

## Journey validation

For each journey:

- Map current steps.
- Identify friction.
- Propose improved steps.
- Show mockups or prototypes.
- Evaluate mobile and desktop.
- Evaluate accessibility.
- Explain tradeoffs.
- Define acceptance criteria.

Do not sacrifice clarity merely to reduce click counts.

---

# 13. PHASE 9 — INTERACTIVE PROTOTYPES

Once the key visual designs and journeys are provisionally approved, create three coherent interactive prototype journeys:

1. First-time onboarding.
2. Daily application management.
3. CV creation and tailoring.

Use the approved design direction.

The prototypes should allow actual navigation and interaction.

Support:

- Buttons and forms
- List/table interactions
- Relevant Kanban actions
- Detail previews
- Saving sample data
- Onboarding skip/resume
- Automation toggles
- CV editing and preview
- Simulated success/error states
- Mobile layouts
- Theme switching
- Localization

Use isolated fixtures or mocks where needed.

Never modify production user data.

Document what is real and what is simulated.

Verify the prototypes using relevant automated tests, keyboard testing and browser inspection.

Present the prototypes for my approval.

STOP before implementing the production redesign.

---

# 14. PHASE 10 — FINAL DESIGN APPROVAL

Prepare a complete design approval package.

Include:

- Approved navigation
- Desktop application shell
- Mobile application shell
- Dashboard
- Application management
- CV editing
- Guided onboarding
- Automation Centre
- Settings
- Major secondary screens
- Design-system tokens
- Typography
- Colour palette
- Responsive rules
- Light/dark themes
- English/Norwegian behavior
- Accessibility considerations
- Interaction patterns
- Approved user journeys
- Component specifications
- Unresolved design decisions

Ask me explicitly:

"Do you approve this final Jobbjakt design system and the proposed production implementation roadmap?"

Do not infer approval.

If I request changes, return to the relevant design iteration stage.

---

# 15. PHASE 11 — IMPLEMENT THE APPROVED DESIGN

Only after explicit approval, create a phased production implementation plan.

Suggested order:

1. Design tokens and shared components.
2. Navigation and application shell.
3. Dashboard and onboarding.
4. Application lists, Kanban and details.
5. Job discovery.
6. CV and career workflows.
7. Calendar, reminders and correspondence.
8. AI interactions and Automation Centre.
9. Settings, administration and secondary screens.
10. Cross-application consistency and polish.

Adjust this order for actual dependencies.

Work in reviewable increments.

Preserve existing data, business logic and functionality.

Avoid unnecessary API or database changes.

Keep English/Norwegian support and both themes.

Treat mobile and desktop equally.

Add or update tests with the implementation.

At meaningful checkpoints, present:

- Completed changes.
- Screenshots.
- Test results.
- Remaining issues.
- Decisions requiring my approval.

Do not merge or deploy automatically.

---

# 16. PHASE 12 — COMPREHENSIVE RELEASE QUALIFICATION

After the approved UX/UI implementation is complete, carry out a full production-readiness assessment.

This must cover the entire Jobbjakt stack, not only visual design.

## Functional regression

Verify all important features and user journeys end to end.

## Accessibility

Target WCAG 2.2 AA with automated and manual verification.

## Security

Audit:

- Authentication
- Authorization
- Cross-user data isolation
- Input validation
- File uploads
- API security
- OAuth
- Sessions and JWTs
- Secrets handling
- Dependencies
- AI trust boundaries
- Docker and infrastructure security

Use available installed security tools where applicable.

Run active tests only against authorized local or staging environments.

## Database integrity

Verify:

- MariaDB integration
- EF Core migrations
- Transactions
- Data consistency
- Referential integrity
- Backup and restore
- Migration failure recovery

## PDF and document fidelity

Requalify Linux/container-based CV/PDF export.

Historical qualification reported 11 failing fixtures out of 24.

Treat this as historical evidence requiring fresh verification, not a current test result.

## CI/CD

Verify:

- Production builds
- Backend tests
- Frontend tests
- Browser tests
- Database integration tests
- Container builds
- Security checks
- Hosted MariaDB CI
- Runner isolation

## Dependencies

Review outstanding Python advisories and applicable dependencies.

## Performance

Test realistic workloads, API response times, UI responsiveness, large datasets, PDF generation, AI operations and resource use.

## Operations

Review:

- Docker deployment
- Reverse proxy and TLS
- Configuration
- Health checks
- Logging
- Monitoring
- Backup/restore
- Rollback
- Recovery procedures

## User experience

Retest every approved user journey on mobile and desktop.

Verify light/dark modes, English/Norwegian, error handling and accessibility.

## Known blockers

Reassess all documented unresolved issues from previous release qualification.

Do not silently waive them.

## Release gate

Produce evidence-backed results:

PASS / FAIL / BLOCKED / NOT TESTED.

Do not label a gate PASS without fresh supporting evidence.

Remediate relevant issues where safely authorized, then retest.

If a change affects previously completed qualification, repeat the affected tests.

Provide a GO / CONDITIONAL GO / NO-GO recommendation.

GO is not permission to deploy.

---

# 17. PERSISTENT DOCUMENTATION

Create a structured workspace under:

docs/product-modernisation/

Suggested structure:

- 00-project-overview/
- 01-discovery/
- 02-interview-and-decisions/
- 03-saas-research/
- 04-design-concepts/
- 05-design-iterations/
- 06-approved-design-system/
- 07-user-journeys/
- 08-interactive-prototypes/
- 09-implementation/
- 10-acceptance-and-testing/
- 11-release-readiness/

Maintain:

- MASTER_STATUS.md
- DECISION_REGISTER.md
- CURRENT_ITERATION.md
- COMPONENT_SELECTIONS.md
- OPEN_QUESTIONS.md
- APPROVAL_HISTORY.md
- RELEASE_BLOCKERS.md

Record each explicit decision, current phase, available concept versions, outstanding issues and next action.

Use stable identifiers for concepts and findings.

Update documentation at each meaningful checkpoint.

Make it possible to resume the workshop in a new Codex session without losing design decisions.

Keep generated design assets and screenshots versioned where practical.

---

# 18. COMMUNICATION REQUIREMENTS

Communicate with me as a collaborative product designer, not just a code generator.

Be proactive about asking useful questions.

When presenting design choices:

- Show actual examples.
- Explain meaningful differences.
- Identify the strongest option.
- Recommend what you think works best.
- Invite me to mix elements.
- Ask what should change.
- Record my selections.

Avoid:

- Endless abstract questions.
- Repeating answered questions.
- Presenting tiny colour variations as different designs.
- Making unapproved assumptions.
- Implementing large changes without review.
- Claiming success without testing.

For long-running work, preserve progress in repository files so subsequent sessions can continue accurately.

Do not pretend to perform work asynchronously after ending a session.

---

# 19. APPROVAL CHECKPOINTS

Require explicit approval at these points:

GATE A — Initial design directions and major preferences.

GATE B — Preferred hybrid visual direction.

GATE C — Major page layouts and complete user journeys.

GATE D — Interactive prototypes and final design system.

GATE E — Production implementation roadmap.

GATE F — Implementation milestone reviews.

GATE G — Final release readiness and deployment authorization.

Never automatically advance past a gate requiring my decision.

A preference is not a final approval.

A GO release recommendation is not deployment authorization.

---

# 20. BEGIN NOW — FIRST RESPONSE

Do not start by generating all five mockups immediately.

First:

1. Inspect the repository.
2. Review the existing application and redesign documentation.
3. Identify the existing UI architecture and major journeys.
4. Summarize the strongest and weakest UX patterns.
5. Identify existing design constraints and technical risks.
6. Research useful SaaS examples where possible.
7. Ask me your FIRST BATCH of 3–5 targeted design questions.

For each question, provide examples, tradeoffs and your recommendation where useful.

Do not ask me to repeat preferences already recorded above.

Then STOP and wait for my answers.

After I respond, continue toward the five initial visual concepts and collaborative design workshop.

**Your goal is not merely to redesign Jobbjakt. Your goal is to work with me until we have an exceptional, thoroughly reviewed product experience, implement that approved design safely, and verify the entire application is ready for production.**