Figma AI Dashboard Redesign

The current dashboard redesign is not a normal iteration. Qpoint is pivoting toward an AI-ecosystem story, which changes the narrative, the information architecture, and the kinds of surfaces the dashboard needs to support.

At the same time, the implementation reality and the design reality have drifted apart:

• much of the real design work now happens directly in the Vue app
• the Figma files are valuable, but they are not in tight sync with q-nuxt-layer
• starting the redesign directly in code would repeat that drift

Because we are starting from scratch, this is the right moment to create a new Figma source of truth for the redesign. But that source of truth should not be a giant speculative library or a literal clone of every code prop. It should begin by modeling the visual API of the dashboard-relevant layer components that already exist, staying in broad parity with code most of the time while allowing pragmatic simplification where the full implementation API would slow design work down.

This cycle exists to define that plan, the file structure, the AI-assisted workflow, and the promotion rules that let us move quickly without turning the Figma library into a graveyard of half-proven experiments.

Companion execution artifacts created during commencement:

• execution-plan.md
• tier-1-component-ledger.md
• existing-pattern-inventory.md
• figma-source-inventory.md
• batch-01-figma-first-moves.md
• figma-design-system-rules.md

Important clarification:

• the near-term work is not a creativity cycle for inventing brand-new page patterns
• app.qpoint.io already contains many of the traffic, server, and dashboard patterns we expect to keep using
• the first job is to prep the pantry: capture those existing patterns and their component building blocks into a trustworthy Figma system so new pages can be assembled from known ingredients
• the existing Figma file is now also a direct pantry source, not just a loose reference

Define an execution plan for a Figma-first dashboard redesign that:

• creates a clean source-of-truth Figma component library for the dashboard
• models the relevant q-nuxt-layer component families as simplified but accurate visual contracts before inventing new ones
• prioritizes pattern replication from the existing app before any page-level invention
• uses Figma MCP and AI where they are strongest: repetitive setup, live UI capture, fast variation, and structured translation between code and design
• preserves a deliberate path for stabilizing successful experiments back into the design system

In:

• planning artifacts for a Figma-first dashboard redesign
• a recommended Figma file topology that keeps system, prototype, and AI scratch work separate
• a visual-API strategy for simplifying code components into accurate Figma design twins
• a replicate-first workflow for pulling existing dashboard patterns into Figma before designing new compositions
• a source-priority workflow for harvesting from the existing Figma library and mockup file before rebuilding assets manually
• guidance for where AI should and should not be used
• a promotion workflow for stabilizing successful experiments into the design system
• a recommended first execution order for the redesign

Out for now:

• rebuilding all layer components in Figma on day one
• reproducing every code prop or implementation detail in Figma
• implementing the redesigned dashboard in Vue during this cycle
• creative exploration of entirely new page patterns before the pantry is ready
• treating AI-generated layouts as canonical without review
• relying on Code Connect or branching as hard dependencies
• making Figma the source of truth for business logic or runtime behavior

• CYCLE.md
• execution-plan.md
• initial-prompt.md
• tier-1-component-ledger.md
• component-intake-template.md
• batch-01-intake.md
• existing-pattern-inventory.md
• figma-source-inventory.md
• batch-01-figma-first-moves.md

Likely follow-on deliverables once execution begins:

• a component parity matrix between q-nuxt-layer and the new Figma system
• a visual API ledger describing what each Figma component preserves, simplifies, or omits
• a tiny canonical mock-data kit for AI-ecosystem dashboard states
• new capture-oriented pages in the design app for dashboard components
• the initial Qpoint Design Library, Prototype, and AI Lab files

This cycle is now the planning container for a Figma-first redesign of the dashboard around the AI ecosystem. The recommended strategy is to prep the pantry first: model the dashboard-critical slice of the layer and the already-proven app patterns as a flexible visual API, isolate AI exploration in a dedicated scratch file, and only stabilize proven patterns into the system library after they survive real prototype use.

Observed in the local workspace:

• design/app/pages/figma/prose.vue already exists as a capture-oriented surface from c13
• c15.figma-to-vue-workflow already validated that Figma MCP can move real designs toward Vue/layer-compatible implementation
• q-nuxt-layer/components/ currently exposes a broad pantry, including:
  • ux (25 files)
  • icon (26 files)
  • data (10 files)
  • security (7 files)
  • health (4 files)
  • sentence (4 files)
  • form (4 files)
  • plus smaller alert, layout, typography, and prose families

Important consequences:

• the first Figma pass should not try to recreate every layer component or every code prop
• the first pass should focus on the dashboard-critical slice of that pantry
• each Figma component should capture the visual interface of the component, not its full runtime API

Based on the provided Figma file:

• 🌟 - Library — primary source for existing components and pantry harvesting
• 🟢 - AI Ecosystem — primary source for strong ecosystem, policy, and detail-page compositions
• 🌞 - CORE — fallback reference only; useful for coverage but explicitly outdated and somewhat broken

Recommended source order for commencement:

1. harvest component structure from 🌟 - Library
2. validate page assembly and composition patterns against 🟢 - AI Ecosystem
3. consult 🌞 - CORE only when it fills a real gap that the first two do not cover

The current Figma connection is live and authenticated for the Qpoint team, and Figma's current documentation confirms that:

• the Figma MCP server supports Codex and can write to canvas, extract design context, and capture live UI into editable Figma layers
• First Draft is strongest for common app/site patterns, not highly novel product structures
• Code Connect and branching are documented as Organization/Enterprise features

Because the connected Qpoint team is currently on a Pro tier, this cycle should not depend on Code Connect or Figma branching being available. If either feature is enabled anyway, treat that as bonus leverage rather than a requirement.

To keep the workspace clean, use separate files with explicit authority:

1. Qpoint Design Library

Published library file for stable foundations and components.

Recommended pages:

• 00 Foundations
• 10 Primitives
• 20 Data + Status
• 30 AI Ecosystem Domain
• 90 Docs + Usage

2. Qpoint Dashboard Prototype

Product composition file where real dashboard flows, page layouts, and prototype links live.

Recommended pages:

• 00 Shell
• 10 Overview
• 20 Agent Detail
• 30 Inventory / Ecosystem
• 40 Trust / Provenance / Explainability
• 90 Graveyard

3. Qpoint Dashboard AI Lab

Disposable scratch file for AI-driven exploration, UI capture, and fast concept bursts.

Purpose:

• absorb noisy MCP/AI experiments
• keep speculative frames out of the system library
• manually promote wins into the system or prototype only after review

This file effectively replaces branching as the safe experimentation zone if the current plan does not include Figma branches.

Before broad library work begins, lock the first two required prototype targets:

• dashboard shell
• AI ecosystem overview

These are the two proving grounds for the first-pass system. Other surfaces can follow, but the library should earn its breadth by supporting these first.

Recommended stance for those targets:

• use them mainly as assembly tests for existing patterns
• avoid treating them as greenfield creative canvases
• only introduce new patterns when the existing pantry genuinely fails to cover the need
• prefer harvesting from the existing Figma sources before rebuilding a component or pattern manually

Phase A: Define The Authority Model

Start by being explicit about ownership:

• q-nuxt-layer remains the implementation truth for shipped component behavior
• Qpoint Design Library becomes the redesign truth for visual/system composition
• anything that exists only in AI Lab is non-canonical until promoted

Each mirrored component should carry one status:

• mirrored — matches layer intent closely
• visual simplification — preserves the important visual API while collapsing implementation detail
• diverged intentionally — Figma redesign has a deliberate departure
• figma-only experiment — not yet accepted into the system

Phase B: Audit And Tier The Layer Pantry

Do not mirror the whole pantry first.

Recommended tiers:

• Tier 1: ux, data, health, security, sentence, alert, layout, and only the icons actually used in the dashboard shell
• Tier 2: supporting form and typography components that affect dashboard editing or settings flows
• Tier 3: backlog families like prose, dev, and unused icon variants

The goal is to get enough system coverage to build the new dashboard, not to finish an abstract library migration.

Before building new components, also audit the existing app patterns that already express:

• traffic moving among servers
• dashboard cards and side panels
• status and trust summaries
• list, table, and detail compositions

Those patterns should become the first reference material for the Figma pantry.

In parallel, create a Figma source inventory for Tier 1:

• map each Batch 01 asset to the best source page in the existing Figma file
• mark whether it should be reuse directly, simplify, or rebuild cleanly
• default to 🌟 - Library first, then check 🟢 - AI Ecosystem

Phase C: Model The Visual API In Figma

For each Tier 1 component:

1. inspect the live code implementation and local demo surface
2. identify which parts of its API actually affect visual composition
3. capture or recreate the component in Figma
4. encode only the variants, states, slots, and toggles the redesign genuinely needs
5. document the intended mapping back to q-nuxt-layer

Recommended rule:

• replicate first, optimize later

That means the first component pass should favor fidelity to visual behavior over polishing new abstractions too early.

Recommended modeling rule:

• code component = full runtime API
• figma component = simplified visual API
• default to parity where it helps clarity and speed
• allow deliberate simplification where strict parity adds noise without improving design decisions

The Figma version should usually preserve:

• meaningful size, state, tone, and density shifts
• visible slot and content regions
• structural variants that change hierarchy or composition

The Figma version should usually omit:

• business-logic flags
• data formatting rules
• internal implementation switches
• one-off app wiring concerns

Parity rule of thumb:

• most of the time, the Figma API should track the code API closely enough that the mapping feels obvious
• it does not need to be religious about parity when a lighter visual contract makes the system easier to use for mockups and exploration

Phase D: Build The Dashboard Prototype From The System

Once the Tier 1 set exists, compose the new dashboard in the prototype file.

Priority prototype surfaces:

• dashboard shell / navigation
• AI ecosystem overview
• agent/session or actor detail view
• inventory/index view
• trust, provenance, or explainability side panels

The prototype should prove the product story and component gaps at the same time.

Phase E: Stabilize Wins

A pattern graduates from prototype or AI Lab into the system only when it is:

• reused in at least two meaningful prototype contexts
• understandable as a stable component or variant model
• not dependent on one-off frame overrides
• clearly nameable in the same mental model as the layer pantry

When promoted:

• update the system component
• note whether the layer will eventually need a matching implementation change
• record intentional divergence instead of silently drifting

Tier 1 acceptance rule:

• a component enters the system only if it is reusable in at least two meaningful frames
• its name feels stable
• its visual API is clearer than a raw frame override
• it helps the first two prototype targets move faster

AI is a strong fit for this cycle when it is used as acceleration, not authority.

Best fits:

• capturing live UI from localhost/staging into editable Figma layers as a starting point
• writing repetitive canvas structure: frames, sections, starter component sets, and documentation blocks
• generating multiple page-level layout directions after the core component kit exists
• translating selected Figma frames back into implementation context later through MCP design extraction
• helping with naming, labeling, and organizing repetitive system metadata

Weak fits:

• final judgment about what is canonical in the design system
• subtle product IA tradeoffs
• deciding the right component boundary without human review
• generating novel high-level dashboard concepts without first grounding them in the AI-ecosystem product story

The workflow this cycle recommends is:

1. explore rashly in AI Lab
2. compose seriously in Prototype
3. promote carefully into System

Guardrails:

• never publish directly from an AI scratch file
• never let page-specific overrides define the component API
• prefer adding a variant only after repeated evidence, not on first need
• keep a simple parity ledger between Figma and q-nuxt-layer
• prefer simplified visual accuracy over false completeness
• review every 5 to 8 promoted assets and classify each as keep, simplify further, or defer

Recommended promotion test:

• has this pattern repeated enough to deserve a name?
• can it be described as props, slots, or variants rather than one frame?
• would we be comfortable implementing it in the layer later?
• does the Figma API help us mock interfaces faster, rather than simply echoing code complexity?

Recommended invention test:

• does the existing app already contain a pattern that solves this well enough?

If yes, replicate it first. If no, then consider a new pattern.

If the answer is no, keep it in prototype space longer.

1. Which exact dashboard surfaces are the first prototype targets for the AI-ecosystem pivot?
2. Which q-nuxt-layer components and existing app patterns are essential for a Tier 1 visual-API pass?
3. Where does the existing app already give us enough pattern coverage to avoid inventing anything new?
4. Which AI-generated outputs are promotion candidates versus disposable exploration?
5. What is the lightweight ledger that keeps Figma and the layer aligned as the redesign evolves?