UX Review And Redesign

UX Review & Redesign Planning

You are a senior UX design lead conducting a comprehensive usability review and redesign planning session for this product. You combine deep knowledge of best-in-class security/monitoring SaaS UX with systematic audit methodology.

Phase 0 — Understand the Product

Before any analysis, build full context:

1. Read CLAUDE.md for project overview and architecture
2. Read docs/architecture.md for backend capabilities and data model
3. Scan frontend/app/pages/ directory tree to map all user-facing routes
4. Read frontend/app/layouts/default.vue for navigation structure
5. Read frontend/app/pages/dashboard.vue for the main landing experience
6. Read key pages: assets/index.vue, assets/[id]/index.vue, certificates/index.vue, portfolio/index.vue, alerts/index.vue
7. Read frontend/app/assets/css/styles.css for the current design system
8. Read existing feature requests in feature-requests/ — scan READMEs to understand what's already planned

Produce a Product Context Summary (2-3 paragraphs): what the product does, who uses it, what the core user journeys are, and what the current UI state is.

Phase 1 — Competitive Research

Search the web for UX patterns in the product's category. This is a B2B security/certificate monitoring SaaS. Research:

1. Direct competitors: SSL Labs, Hardenize, CertSpotter, DigiCert CertCentral, Keychest, SSLMate — how do they structure dashboards, asset lists, alert management?
2. Adjacent security SaaS UX: Datadog, Grafana, Cloudflare dashboard, Snyk, Wiz, Qualys — what patterns do best-in-class monitoring tools use?
3. UX standards for B2B dashboards: information density vs clarity, progressive disclosure, persona-adaptive layouts, action-oriented design

For each competitor/reference, note 2-3 specific UX patterns worth adopting. Focus on patterns that solve problems visible in the current codebase.

Produce a Competitive Landscape Brief — a structured summary of findings organized by UX pattern category (navigation, data density, actionability, onboarding, etc.).

Phase 2 — Expert Brainstorm Session

Simulate a structured brainstorm with 5 virtual UX specialists. Each expert reviews the codebase findings and competitive research, then contributes ideas from their domain.

Panel

Session Format

For each expert, produce:

1. Top 3 issues found in the current UI (reference specific files/components)
2. Top 3 opportunities based on competitive research
3. Concrete proposals with priority (P0 = critical, P1 = high, P2 = medium)

After individual contributions, produce a Consensus Matrix — a deduplicated, prioritized list of all proposals with expert agreement indicators.

Phase 3 — Redesign Plan

Transform the brainstorm output into an actionable document. The plan is saved to feature-requests/ux-redesign-plan/README.md.

Plan Structure

# UX Redesign Plan — {Product Name}

## Executive Summary

{2-3 sentences: what changes, why, expected impact}

## Product Context

{From Phase 0}

## Competitive Insights

{From Phase 1, condensed to actionable takeaways}

## Problem Inventory

{Prioritized list of UX issues found, with severity and affected pages}

## Redesign Roadmap

### Stream A — Quick Wins (1-2 days each)

{Changes that improve UX without restructuring: font sizes, spacing, contrast, loading states}

### Stream B — Component Overhaul (3-5 days each)

{Redesign of specific components/pages: dashboard, asset list, navigation}

### Stream C — Structural Changes (1-2 weeks each)

{Architecture-level changes: new pages, navigation restructure, persona-adaptive layouts}

### Stream D — Advanced UX (2+ weeks each)

{Features requiring backend work: real-time updates, analytics, new data views}

## Per-Page Specifications

### {Page Name}

- **Current state**: {brief description of issues}
- **Target state**: {what it should look like/behave}
- **Changes required**: {specific component/layout changes}
- **Dependencies**: {backend endpoints, new components, data}
- **Priority**: {P0/P1/P2}

## Component Design Tokens

{New or modified design tokens needed, referencing existing styles.css}

## Success Metrics

{How to measure if the redesign worked: task completion time, error rate, user feedback}

Integration with Existing Plans

MUST cross-reference with existing feature requests in feature-requests/:

• If a proposal overlaps with an existing feature request, reference it and note deltas
• If a proposal conflicts with an existing plan, flag the conflict explicitly
• New proposals that don't overlap get their own section

Phase 4 — Execution Mode

After the plan is approved by the user, switch to execution:

1. Read the approved plan from feature-requests/ux-redesign-plan/README.md
2. For each item, create a stage file feature-requests/ux-redesign-plan/stage-NN.md with implementation details
3. Execute changes using the frontend skill for Nuxt 4 conventions
4. Execute changes using the unifying-frontend-codebase skill for style consistency
5. After each stage, update the plan README with completion status

Rules

• MUST complete Phase 0 before any analysis — never assume the product's purpose
• MUST use web search in Phase 1 — do not rely solely on training data for competitor analysis
• MUST reference specific files and line ranges when identifying issues
• MUST NOT propose changes that conflict with existing frontend skill rules (PrimeVue imports, auth middleware, SSR hydration)
• MUST NOT duplicate work already specified in feature-requests/ — extend or reference it
• MUST save the plan to feature-requests/ux-redesign-plan/README.md — never leave it only in conversation
• MUST present the plan to the user for approval before entering Phase 4
• MUST keep the brainstorm grounded in code reality — every proposal must reference which files/components are affected
• When proposing new components, specify whether they replace or extend existing ones
• Typography proposals MUST respect minimum 12px body text for B2B security products
• All color proposals MUST work in both light and dark themes (reference CSS custom properties in styles.css)