Use the vibe code prompt below to build a responsive dashboard shell in React, TypeScript, and Tailwind CSS. It covers the layout, mobile navigation, loading states, and keyboard behavior that shorter dashboard prompts tend to ignore.

Treat the first result as a draft. The follow-up prompts help you audit it, fix what breaks, and verify the result in a browser.

Build → inspect → improve → verify

If you want more implementation-ready components after this project, browse the frontend AI coding prompt library.

What this dashboard prompt builds

The original prompt asks for a dashboard shell with three main regions:

  • a collapsible navigation sidebar
  • a sticky top header with search and a user menu
  • a main content area with responsive stat cards

On desktop, the sidebar can collapse into an icon rail. On smaller screens, it becomes an overlay drawer controlled by a hamburger button. The stat cards move from four columns to two and then one as the available space shrinks.

It also asks for details that vague dashboard prompts normally miss:

  • semantic page landmarks
  • keyboard access and visible focus states
  • focus trapping and restoration for the mobile drawer
  • Escape-to-close behavior
  • persisted sidebar preference
  • skeletons that match the final card dimensions
  • no page-level horizontal scrolling
  • typed component props without any

This is a dashboard shell, not a finished product. Get the layout and interactions working first, then connect the data your application actually uses.

When to use this prompt

Use it when you are:

  • adding a dashboard shell to an existing React application
  • replacing a desktop-only admin layout
  • building the interface before real APIs are connected
  • creating a focused internal tool that does not need a large admin template

It is not a shortcut for a complete analytics product. Authentication, permissions, production data, logging, and backend behavior still need their own requirements and verification.

The original responsive dashboard prompt

Copy this into Claude Code, Cursor, Codex, ChatGPT, Copilot, or another AI coding tool working inside your project.

Build a responsive admin dashboard shell in React with TypeScript in strict mode and Tailwind CSS.

Before editing:
- Inspect the existing project structure, shared components, design tokens, routes, and package versions.
- Reuse existing components and conventions where they fit.
- Do not replace working data flow, authentication, routing, or business logic.
- Return a short implementation plan and list the files you expect to create or modify.

Build these three layout regions:

1. Left sidebar
- Product logo/name at the top.
- Primary navigation links with icons and text labels.
- Active-route state using aria-current="page".
- Collapsible on desktop: expanded sidebar or compact icon rail.
- Persist the desktop collapsed/expanded preference in localStorage.

2. Sticky top header
- Show a menu button whenever navigation is rendered as an overlay drawer.
- Search field with a real label or accessible name.
- Notification button with an accessible label.
- User-avatar menu with keyboard-operable open/close behavior.

3. Main content area
- Page heading and short context line.
- Responsive grid of four stat cards.
- A primary content panel and a secondary activity panel below the cards.
- Use realistic mock data kept separate from the layout components.

Responsive behavior:
- Desktop: expanded sidebar by default and four stat-card columns when space allows.
- Tablet: compact sidebar or icon rail and two stat-card columns.
- Mobile: sidebar becomes an overlay drawer and stat cards stack into one column.
- Treat the mobile drawer as a modal overlay with a backdrop, focus trapping while open, Escape to close, pointer activation of the backdrop to close, and focus restoration to the trigger.
- Test continuously from 320px to 1920px.
- No page-level horizontal scrolling.
- Long labels and dynamic values must not force overflow.

Layout and component rules:
- Use CSS Grid for the overall dashboard and stat-card layout.
- Use Flexbox for small alignment groups.
- Keep the component tree small and fully typed with explicit prop types and no any.
- Use semantic landmarks: header, nav, main, and aside where appropriate.
- Every interactive element must be keyboard reachable and have a visible focus-visible state.
- Respect prefers-reduced-motion.

Loading behavior:
- Add skeleton versions of the stat cards and main panels.
- Skeletons must reserve the same layout space as the expected content so the transition causes no noticeable layout shift.
- Expose loading state accessibly with aria-busy or an equivalent pattern without making assistive technology read decorative placeholder shapes.

Suggested components:
- DashboardShell
- Sidebar
- TopHeader
- StatGrid
- StatCard
- ContentPanel
- ActivityPanel
- DashboardSkeleton

Do not add charting, authentication, backend APIs, or a large component library unless the project already uses them. Keep this task focused on the dashboard shell.

Verification:
- Run the existing typecheck, lint, test, and production-build commands.
- Browser-check the dashboard at 320px, 360px, 768px, 1024px, 1440px, and 1920px.
- Confirm there is no page-level horizontal scroll.
- Confirm the drawer works by keyboard, traps focus while open, closes with Escape, and restores focus to the trigger.
- Confirm the desktop sidebar preference restores correctly after reload.
- Confirm loading skeletons do not shift the layout when replaced with content.
- Report console errors or warnings.
- Provide screenshots at 360px, 768px, and 1440px.

Done when the dashboard is usable by keyboard alone, remains readable across the full viewport range, preserves existing app behavior, passes the project checks, and has browser evidence for the responsive states.

Why the original prompt is structured this way

A weak prompt such as “build a modern admin dashboard” usually produces a screenshot-shaped result. It may look complete at one desktop width while hiding the problems that matter:

  • the sidebar never becomes usable on mobile
  • the drawer opens but does not manage focus
  • the card grid creates horizontal overflow
  • loading data moves the entire page
  • every component uses slightly different spacing
  • the AI adds charts, dependencies, and fake features you never requested

The prompt defines the job narrowly enough to review: build the shell, preserve the existing application, and prove the result works.

More importantly, it tells the agent to inspect the project before editing. A new dashboard should use the project’s router, components, design tokens, and commands instead of dropping a second design system into the repo.

If your project has stable build commands or component rules, put them in an AGENTS.md file or Cursor Rules. Keep the current dashboard goal and acceptance criteria in the active prompt.

Inspect the first result before asking for polish

Do not immediately say, “Looks good—make it prettier.”

Open the dashboard in a browser and check the first result. Resize it. Use the keyboard. Trigger loading. Open and close the drawer. Reload the page after changing the sidebar preference.

Look for these problems:

Hierarchy

  • Can you tell what the dashboard is for in a few seconds?
  • Do warnings, current status, and secondary history have different visual weight?
  • Are all four stat cards oversized and fighting for attention?
  • Does the page heading describe the user’s task, or does it just say “Dashboard”?

Responsive layout

  • Does the sidebar become a real drawer or simply disappear?
  • Can long labels force the page wider than the viewport?
  • Are card values clipped at 320px?
  • Does the sticky header cover content?
  • Do tablet widths feel intentional, or are they awkward desktop leftovers?

Interaction

  • Can you reach every control with Tab and Shift+Tab?
  • Does the drawer trap focus while open?
  • Does Escape close it?
  • Does focus return to the hamburger button?
  • Is the current route communicated with more than color?

States

  • What happens while data loads?
  • What happens when there are no stats or activities?
  • What happens when one request fails?
  • Can the page show stale data with a refresh warning?
  • Does retrying preserve the content that already loaded?

Run the follow-ups one at a time so each change remains easy to review. Start with an audit before asking for visual changes.

Follow-up prompt 1: audit the generated dashboard

Audit the responsive dashboard you just built. Do not edit files yet.

Evaluate:
- whether the page's primary purpose is obvious
- information hierarchy across the heading, stat cards, main panel, and activity panel
- spacing and alignment consistency
- duplicated styles or one-off component decisions
- responsive behavior at 320px, 360px, 768px, 1024px, and 1440px
- sidebar and mobile-drawer behavior
- page-level and container-level overflow
- loading, empty, error, stale-data, success, and retry states
- keyboard navigation, focus visibility, focus trapping/restoration, landmarks, labels, contrast, and reduced motion
- console errors, warnings, and failed requests

Return:
1. the five highest-impact findings, ranked
2. the exact component or file involved in each finding
3. what should stay unchanged
4. the smallest coherent improvement plan
5. checks that still require manual browser or screen-reader verification

Separate functional problems from optional visual polish. Do not make changes until the audit is complete.

The result should be a prioritized report, not a redesign pitch. If the AI recommends replacing the entire component system because one gap is inconsistent, push back.

Follow-up prompt 2: improve hierarchy without generic dashboard styling

Once the audit identifies the structural problems, use this prompt to fix their visual priority without turning the page into a generic admin template.

Improve the dashboard's information hierarchy without changing its data contracts, routes, or feature set.

Use the audit findings as the source of truth.

Requirements:
- Make the page's primary purpose and current status clear within a few seconds.
- Treat urgent warnings, current status, and historical detail as different priority levels.
- Do not make every metric a large card.
- Reduce decorative containers that do not improve grouping.
- Use spacing, typography, position, contrast, and grouping before adding decoration.
- Preserve the existing product identity and shared design tokens.
- Reuse the current components unless a small extraction removes real duplication.
- Keep stat labels short and values readable when numbers become longer than the mock data.
- Keep the primary content panel more prominent than the secondary activity panel.

Avoid:
- decorative gradients
- glassmorphism
- oversized rounded cards
- random accent colors
- animation on every section
- changing working behavior for visual polish

Before editing, show the proposed information order and explain what will become more or less prominent.

After editing:
- run the project checks
- compare before/after screenshots at 360px and 1440px
- report any behavior that changed

The dashboard does not need more visual noise. It needs a clearer answer to “What should I look at first?”

Follow-up prompt 3: fix the sidebar and mobile drawer

A desktop sidebar is easy. The mobile transition is where dashboard shells usually get sloppy.

Focus only on the dashboard navigation and its responsive behavior.

Desktop:
- Expanded sidebar shows icons and text labels.
- The collapsed desktop sidebar is the icon rail; give each icon an accessible name and a visible tooltip.
- Persist the user's explicit preference in localStorage.
- Read the saved preference in a hydration-safe way and avoid rendering different server and client markup.

Tablet:
- Use the available width to decide whether the compact rail or drawer is more usable.
- Keep the main content wide enough for its actual data.

Mobile:
- Sidebar becomes an overlay drawer controlled by a real button.
- The button exposes aria-expanded and aria-controls.
- Opening the drawer moves focus inside it.
- Focus is trapped while open.
- Escape and pointer activation of the backdrop close it.
- Closing restores focus to the trigger.
- The backdrop is not keyboard focusable.
- Body scroll is locked only while the drawer is open and is restored reliably.
- Current route uses aria-current.
- Motion respects prefers-reduced-motion.

Test at 320px, 360px, 390px, 768px, 1024px, and 1440px.

Check computed overflow styles and compare scrollWidth with clientWidth and scrollHeight with clientHeight for the page shell, header, navigation, and main content. Fix the source of overflow instead of hiding it with overflow-x: hidden.

Done when navigation works with mouse, touch, and keyboard; focus never gets lost; the drawer cannot trap the page after closing; and no viewport has page-level horizontal scroll.

That last overflow instruction matters. Hiding overflow can make the screenshot look fixed while content is still cut off.

Follow-up prompt 4: add the missing dashboard states

Dashboards look finished when mock data is present. Remove the mock data and reload. That is where blank panels and broken layouts show up.

Add a complete UI state contract to the existing dashboard without changing its API shape.

For the stat grid, primary panel, and activity panel, handle:
- initial loading
- loaded data
- empty data
- partial data
- stale data during a background refresh
- recoverable request error
- non-recoverable request error
- retry in progress
- permission denied, if the feature can return it

Requirements:
- Skeletons match the real component dimensions so swapping content causes no layout shift.
- Keep successfully loaded content visible if a background refresh fails.
- Empty states explain whether there is no data yet or no result for the active filters.
- Error states explain what failed and provide a retry action when recovery is possible.
- Do not use color as the only error, warning, or stale-data signal.
- Announce meaningful async status changes without stealing focus.
- Retry buttons must prevent duplicate requests while pending.
- Long error messages must not expand the page horizontally.
- Add focused tests for the state transitions.

Create a small state matrix before editing. Then implement one panel at a time.

Done when every async branch has a deliberate visual and accessible result and the user is never left with a blank card or unexplained spinner.

Follow-up prompt 5: run the accessibility pass

Automated checks help, but they do not prove the drawer, menus, and keyboard flow actually work.

Run an accessibility pass on the existing dashboard. Do not redesign it unless a verified issue requires a visual change.

Check:
- one logical H1 and a correct heading hierarchy
- header, nav, main, and aside landmarks
- skip-link behavior if the app shell needs one
- keyboard order through sidebar, header, stat cards, panels, and menus
- visible focus-visible indicators
- mobile-drawer focus trap and focus restoration
- user-menu keyboard behavior and Escape handling
- aria-current for the active navigation item
- accessible names for icon-only buttons
- search-field label, placeholder, and any required input instructions
- contrast for text, borders, focus rings, warnings, and disabled states
- status information that does not rely only on color
- reduced-motion handling
- text reflow at 200% zoom and at a 320 CSS-pixel viewport equivalent
- touch targets at least 24 by 24 CSS pixels unless a documented exception applies; aim for 44 by 44 pixels on primary mobile controls
- loading and error announcements

Use automated accessibility checks where available, then perform a manual keyboard walkthrough.

Return findings grouped as:
1. blockers
2. high-impact issues
3. polish
4. manual screen-reader checks still required

For each finding, name the element and file, explain the user impact, and apply the smallest fix. Run the project checks again after editing.

The agent should say what it could not verify. “No automated violations” is not the same as “accessible.”

Follow-up prompt 6: final browser QA and regression check

The final pass collects command output, screenshots, and browser evidence instead of adding more polish.

Run final QA on the responsive admin dashboard.

Do not make broad design changes. Fix only verified defects found during this pass.

Project checks:
- run the existing typecheck
- run lint
- run focused tests
- run the production build
- report the exact command and exit status for each

Browser checks at 320px, 360px, 390px, 768px, 1024px, 1440px, and 1920px:
- no page-level horizontal scroll
- no clipped labels, values, menus, or controls
- sticky header does not cover content
- sidebar and drawer states behave correctly
- drawer closes with Escape and restores focus
- desktop collapsed preference survives reload
- stat cards move through the intended column counts
- loading skeletons match final content dimensions
- empty, error, stale, and retry states render correctly
- user menu and search remain keyboard operable
- reduced-motion mode removes nonessential animation
- browser console contains no relevant errors or warnings

Capture screenshots at 360px, 768px, and 1440px.

Report:
1. checks that passed
2. defects found and fixed
3. checks that could not be completed
4. remaining manual verification
5. files changed during QA

Do not claim completion without real command output and browser evidence.

If the tool cannot open a browser or run the project, that is a blocker—not a reason to invent a passing result.

Expected component structure

The exact structure should follow the existing repo, but a small dashboard shell often lands near this shape:

src/
  components/
    dashboard/
      DashboardShell.tsx
      Sidebar.tsx
      TopHeader.tsx
      StatGrid.tsx
      StatCard.tsx
      ContentPanel.tsx
      ActivityPanel.tsx
      DashboardSkeleton.tsx
  data/
    dashboardMockData.ts
  pages/ or app/
    dashboard/

Do not force this structure into a project that already has a component convention. The prompt asks the AI to inspect first for that reason.

Separate the shell and navigation from data display and UI-state handling. Keep mock data outside the component markup so real data can replace it later.

Keep the first build small. A dashboard does not need a chart library, state-management library, animation library, and component framework just because those tools exist.

Common dashboard prompt failures

The AI builds a screenshot, not an interface

It looks finished at 1440px, but the keyboard flow, loading states, and mobile navigation do not exist. Audit those behaviors before adding features.

The sidebar disappears on mobile

A hidden sidebar without an accessible replacement removes navigation. Require a real drawer, focus management, Escape handling, and focus restoration.

Every metric becomes a giant card

Four oversized cards can consume the entire first screen while saying very little. Use hierarchy based on the dashboard’s job, not the default admin-template layout.

The grid overflows at narrow widths

Long values, fixed minimum widths, and unbreakable labels can defeat a responsive grid. Test real edge-case content at 320px instead of trusting the framework breakpoint.

Loading causes layout shift

A row of tiny gray bars does not help if the final cards are twice as tall. Skeletons should reserve the same layout space and use the same sizing tokens as the content they replace.

The AI adds features you did not ask for

Charts, authentication, settings pages, API routes, and fake CRUD flows make the change harder to review. The original prompt explicitly keeps them out of scope.

The dashboard passes lint but fails in the browser

Typecheck and lint cannot prove the drawer traps focus or the sticky header behaves at 390px. Require browser evidence.

Adapting the prompt to other stacks

The prompt uses React, TypeScript, and Tailwind, but most of its requirements are framework-independent. Change the component vocabulary and preserve the responsive, state, accessibility, and verification requirements.

Next.js

Tell the agent whether the dashboard belongs in the App Router, whether the shell should be a layout, and where server/client boundaries already exist. Do not let it mark the entire dashboard as a client component without a reason.

Vue

Replace React component terminology with Vue Single-File Components and typed props.

Svelte

Use Svelte components and avoid introducing a store for drawer state unless that state is genuinely shared.

Astro

Use Astro for the shell and static content where possible. Add client islands only for interactive navigation, menus, or live data. Do not hydrate the whole page for one drawer button.

Plain HTML, CSS, and JavaScript

Remove framework-specific component language. A dashboard shell does not require React to be responsive or keyboard accessible.

Dashboard build checklist

Before calling the project done, confirm:

  • The dashboard purpose is obvious.
  • Sidebar, header, and main content use semantic landmarks.
  • Desktop collapse and mobile drawer are separate, deliberate behaviors.
  • Sidebar preference restores safely after reload.
  • The mobile drawer manages focus correctly.
  • Every interactive element has a visible focus state.
  • Stat cards do not all compete at the same priority.
  • Loading skeletons match final dimensions.
  • Empty, error, stale, success, and retry states exist.
  • No viewport has page-level horizontal scrolling.
  • Long labels and values have been tested.
  • Reduced motion is respected.
  • Typecheck, lint, tests, and production build pass.
  • Screenshots exist for mobile, tablet, and desktop.
  • Console errors and remaining manual checks are reported.

FAQ

What should I include in a vibe code prompt for a responsive admin dashboard?

Include the target stack, sidebar and header behavior, responsive grid rules, mobile-drawer interactions, semantic landmarks, keyboard requirements, loading states, component boundaries, out-of-scope features, and verification steps. The agent should know both what to build and how you will prove it works.

Can I use this prompt with Cursor or Claude Code?

Yes. It works best when the tool can inspect your existing repository. Let it read the project’s component conventions, router, design tokens, and commands before it edits files. The same prompt can also work in ChatGPT or another tool if you provide the missing project context.

Why use follow-up prompts instead of putting everything in the first prompt?

The first prompt establishes the shell. The follow-ups respond to what the tool actually built, keeping each audit or fix small enough to review.

Should the AI add charts to the dashboard?

Only if charts are part of your actual product requirement. A chart library adds bundle weight, styling decisions, responsive behavior, accessibility concerns, and data-shape requirements. Build the shell first, then add one chart with a separate focused prompt if the dashboard needs it.

How do I know the dashboard is truly responsive?

Resize it across the full range, test named viewport widths, use long content, open every menu and drawer, inspect page and container overflow, and capture browser screenshots. “The Tailwind classes look responsive” is not evidence.

Is this dashboard ready for production after the prompts are complete?

Not automatically. The prompts improve the frontend shell, but production readiness also depends on authentication, authorization, real data handling, error logging, security, deployment, and monitoring. Run the AI-coded app launch audit before real users or sensitive data touch it.

Build the dashboard, then make it survive reality

A generated dashboard is only a first pass.

Audit the first result before polishing it. Fix the hierarchy before adding decoration. Test the sidebar where it actually changes behavior. Remove the mock data and see what breaks. Use the keyboard. Resize the page until the layout has nowhere left to hide.

Finish with command output, screenshots, and any checks you could not complete.

For more component-level starting points, browse the frontend prompt library. Use the UI/UX prompt library when the problem is primarily hierarchy, interaction design, or visual review. For the broader mechanics behind writing effective instructions, read Vibe Coding Prompts That Actually Work and How to Write Better AI Coding Prompts.