v0 prompt to build a dashboard UI
Give v0 this layout-and-states spec and it produces a working dashboard: sidebar shell, stat cards with period deltas, a range-driven chart, and a sortable activity table. Because every widget carries its own loading, error, and empty state, the result survives contact with a real API instead of assuming perfect data.
Last updated
Build an admin dashboard for {{resource}} data in Next.js with shadcn/ui and Tailwind.
Layout: collapsible left sidebar with logo and nav (Overview, {{resource}}, Reports, Settings), a top bar holding a date-range picker and user menu, content on a 12-column grid.
Overview screen:
- Four stat cards: total count, active this week, conversion rate, errors. Each shows the delta versus the previous period with an up or down arrow.
- A line chart of daily counts for the selected range.
- A recent activity table: name, status badge, owner, updated time. Column-header sorting, 10 rows per page.
Behaviors: changing the date range refetches every widget and writes the range to the URL query string, so refresh and back button both preserve it. Clicking a table row opens a detail drawer from the right with the full record and an edit form.
States, per widget rather than global: loading shows a skeleton matching the widget's dimensions; error shows an inline message with a retry button rather than a blank card; empty shows a short explanation and a create action. A missing metric renders a placeholder character, never NaN or undefined.
Data: everything comes from a single getDashboardData(range) function returning mocked values derived from the range, so switching ranges visibly changes the numbers. I will replace this function with a real API call later.
Styling: neutral surface, one accent color, roomy spacing, no gradients. At 375px the sidebar collapses to icons and the stat cards stack vertically.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Build an admin dashboard for users data in Next.js with shadcn/ui and Tailwind. Layout: collapsible left sidebar with logo and nav (Overview, users, Reports, Settings), a top bar holding a date-range picker and user menu, content on a 12-column grid. Overview screen: - Four stat cards: total count, active this week, conversion rate, errors. Each shows the delta versus the previous period with an up or down arrow. - A line chart of daily counts for the selected range. - A recent activity table: name, status badge, owner, updated time. Column-header sorting, 10 rows per page. Behaviors: changing the date range refetches every widget and writes the range to the URL query string, so refresh and back button both preserve it. Clicking a table row opens a detail drawer from the right with the full record and an edit form. States, per widget rather than global: loading shows a skeleton matching the widget's dimensions; error shows an inline message with a retry button rather than a blank card; empty shows a short explanation and a create action. A missing metric renders a placeholder character, never NaN or undefined. Data: everything comes from a single getDashboardData(range) function returning mocked values derived from the range, so switching ranges visibly changes the numbers. I will replace this function with a real API call later. Styling: neutral surface, one accent color, roomy spacing, no gradients. At 375px the sidebar collapses to icons and the stat cards stack vertically.
Same task in other tools
Questions about this prompt
Which chart library will v0 use?
Usually the shadcn/ui chart components built on Recharts. If your repo standardizes on something else, name it in the prompt's chart line; asking after the fact forces a rewrite of the chart wrapper and its loading skeleton.
How do I connect real data?
Keep the getDashboardData(range) signature and replace its body with your fetch. The prompt pins every widget to that one function precisely so wiring a backend is a single-file change once you push the generation to a Vercel project or export the code.
The numbers do not change when I pick a new range. Is that a bug?
It is the most common miss on this task: v0 sometimes hardcodes mock values instead of deriving them from the range argument. Reply with "make getDashboardData compute values from the range so every widget changes when the range does" and re-test.