Dashboard UI Project

A dashboard usually starts with a few visual cards: revenue, users, orders, projects, traffic, or notifications. A common mistake is hardcoding every card directly inside the page component. This works for a static screenshot, but it becomes difficult to maintain when the number of cards grows, the labels change, or the same card style is reused across several dashboard pages.

A stronger approach is to create a reusable metric model and render cards from data. This keeps the UI consistent and makes it easier to add icons, trends, loading states, and comparison values later. In admin dashboards, many cards follow the same structure: title, value, trend, description, icon, and link to a deeper page. That repeated structure should become a component, not duplicated markup.

Problematic approach:

          function Dashboard() {
            return (
              <div className="dashboard-grid">
                <div className="card">
                  <h3>Users</h3>
                  <p>12,430</p>
                  <span>+12%</span>
                </div>

                <div className="card">
                  <h3>Revenue</h3>
                  <p>$48,900</p>
                  <span>+8%</span>
                </div>

                <div className="card">
                  <h3>Orders</h3>
                  <p>1,284</p>
                  <span>-3%</span>
                </div>
              </div>
            );
          }

This markup is repetitive. If the card layout changes, every card has to be edited manually.

Better data-driven model:

          type MetricTrend = "positive" | "negative" | "neutral";

          type DashboardMetric = {
            id: string;
            title: string;
            value: string;
            changeLabel: string;
            trend: MetricTrend;
            description: string;
          };

          const dashboardMetrics: DashboardMetric[] = [
            {
              id: "users",
              title: "Users",
              value: "12,430",
              changeLabel: "+12%",
              trend: "positive",
              description: "Compared with last month"
            },
            {
              id: "revenue",
              title: "Revenue",
              value: "$48,900",
              changeLabel: "+8%",
              trend: "positive",
              description: "Monthly recurring revenue"
            },
            {
              id: "orders",
              title: "Orders",
              value: "1,284",
              changeLabel: "-3%",
              trend: "negative",
              description: "Compared with last week"
            }
          ];

Reusable card component:

          function MetricCard({ metric }: { metric: DashboardMetric }) {
            return (
              <Card className="metric-card">
                <CardContent>
                  <Typography variant="body2" color="text.secondary">
                    {metric.title}
                  </Typography>

                  <Typography variant="h4">
                    {metric.value}
                  </Typography>

                  <span className={`metric-card__trend metric-card__trend--${metric.trend}`}>
                    {metric.changeLabel}
                  </span>

                  <Typography variant="caption" color="text.secondary">
                    {metric.description}
                  </Typography>
                </CardContent>
              </Card>
            );
          }

Rendering the grid:

          function DashboardMetricGrid() {
            return (
              <section className="dashboard-metrics" aria-label="Dashboard metrics">
                {dashboardMetrics.map((metric) => (
                  <MetricCard key={metric.id} metric={metric} />
                ))}
              </section>
            );
          }

Pay attention to: Dashboard cards are repeated UI patterns. Create a clear metric model and reusable card component instead of hardcoding every widget in the page.

Dashboards often depend on a sidebar for navigation. On desktop, the sidebar can stay visible. On tablets and phones, it usually needs to collapse into a drawer or overlay. A common mistake is building the sidebar as a fixed block with a fixed width and assuming the content area will always have enough space. This creates horizontal scrolling, hidden content, and poor mobile usability.

A good dashboard layout should treat navigation state as part of the UI architecture. The sidebar needs open and closed states, keyboard-accessible controls, clear active links, and responsive behavior. The main content area should adapt when the sidebar is collapsed. If you use Material UI, this is a strong place to practice combining AppBar, Drawer, Toolbar, routing, and theme-aware styling.

Problematic layout:

          .dashboard {
            display: flex;
          }

          .sidebar {
            width: 280px;
            height: 100vh;
            position: fixed;
          }

          .main {
            margin-left: 280px;
          }

This may work on a large screen, but on a small screen the sidebar can cover content or create horizontal overflow.

Better sidebar state:

          type LayoutState = {
            sidebarOpen: boolean;
          };

          function DashboardLayout() {
            const [sidebarOpen, setSidebarOpen] = useState(false);

            function toggleSidebar() {
              setSidebarOpen((isOpen) => !isOpen);
            }

            function closeSidebar() {
              setSidebarOpen(false);
            }

            return (
              <Box className="dashboard-layout">
                <AppBar position="sticky">
                  <Toolbar>
                    <IconButton
                      edge="start"
                      color="inherit"
                      onClick={toggleSidebar}
                      aria-label={sidebarOpen ? "Close navigation" : "Open navigation"}
                    >
                      <MenuIcon />
                    </IconButton>

                    <Typography variant="h6">Dashboard</Typography>
                  </Toolbar>
                </AppBar>

                <DashboardSidebar open={sidebarOpen} onClose={closeSidebar} />

                <Box component="main" className="dashboard-layout__content">
                  <Outlet />
                </Box>
              </Box>
            );
          }

Responsive CSS idea:

          .dashboard-layout {
            min-height: 100vh;
            display: grid;
            grid-template-rows: auto 1fr;
          }

          .dashboard-layout__content {
            padding: 24px;
            min-width: 0;
          }

          @media (min-width: 1024px) {
            .dashboard-layout {
              grid-template-columns: 280px minmax(0, 1fr);
            }

            .dashboard-layout__content {
              grid-column: 2;
            }
          }

Pay attention to: A dashboard sidebar is not just a visual column. It needs responsive behavior, active route states, accessible toggle controls, and a main content area that does not overflow on smaller screens.

Charts are one of the main reasons dashboards exist, but they are often implemented too quickly. A common mistake is passing raw API data directly into a chart component and hoping the chart library will handle everything. This can produce wrong labels, broken tooltips, inconsistent date ordering, or charts that fail when a value is missing.

Chart components should receive prepared chart data, not raw business records. For example, if the dashboard has revenue records, the chart should receive clean labels and numeric values. Dates should be sorted. Missing values should be normalized. Display formatting should happen in tooltips or axis formatters, not inside the source numbers. This is especially important when using libraries such as Recharts, where small data-shape mistakes can lead to confusing visuals.

Problematic approach:

          const revenue = [
            { date: "2026-06-10", total: "$1,250" },
            { date: "2026-06-09", total: "$980" }
          ];

          <LineChart data={revenue}>
            <Line dataKey="total" />
          </LineChart>

The chart receives formatted strings instead of numeric values. It may not render correctly, and the dates are not sorted.

Better chart data model:

          type RevenueRecord = {
            date: string;
            totalCents: number;
          };

          type RevenueChartPoint = {
            label: string;
            revenue: number;
          };

          function createRevenueChartData(
            records: RevenueRecord[]
          ): RevenueChartPoint[] {
            return [...records]
              .sort((first, second) => {
                return new Date(first.date).getTime() - new Date(second.date).getTime();
              })
              .map((record) => {
                return {
                  label: formatShortDate(record.date),
                  revenue: record.totalCents / 100
                };
              });
          }

Chart rendering:

          const chartData = createRevenueChartData(revenueRecords);

          <ResponsiveContainer width="100%" height={320}>
            <LineChart data={chartData}>
              <CartesianGrid strokeDasharray="3 3" />
              <XAxis dataKey="label" />
              <YAxis />
              <Tooltip
                formatter={(value) => {
                  return formatCurrency(Number(value));
                }}
              />
              <Line
                type="monotone"
                dataKey="revenue"
                strokeWidth={2}
                dot={false}
              />
            </LineChart>
          </ResponsiveContainer>

Empty chart state:

          if (!chartData.length) {
            return (
              <Card>
                <CardContent>
                  <Typography>No revenue data available yet.</Typography>
                </CardContent>
              </Card>
            );
          }

Pay attention to: Prepare chart data before rendering. Sort dates, keep values numeric, format only at display time, and add empty states for charts with no data.

Admin dashboards usually include tables for users, projects, invoices, logs, orders, or contacts. A common mistake is rendering a table only for the perfect case where data exists and loads instantly. Real dashboards need loading states, empty states, error states, filters, sorting, and pagination. Without these states, the table feels broken as soon as data is delayed or the user applies a filter that returns no records.

A good dashboard table should communicate what is happening. If data is loading, show skeleton rows or a loading indicator. If there are no users, show a helpful empty state. If a search filter returns no matches, explain that the filter is the reason. If data fails to load, show an error and a retry action. This makes the UI feel like a real admin tool instead of a static template.

Problematic table:

          function UsersTable({ users }) {
            return (
              <Table>
                <TableBody>
                  {users.map((user) => (
                    <TableRow key={user.id}>
                      <TableCell>{user.name}</TableCell>
                      <TableCell>{user.email}</TableCell>
                      <TableCell>{user.role}</TableCell>
                    </TableRow>
                  ))}
                </TableBody>
              </Table>
            );
          }

This assumes users is always ready and never empty. It also does not support filtering or pagination.

Better table state model:

          type TableState<T> =
            | { status: "loading" }
            | { status: "success"; data: T[] }
            | { status: "empty" }
            | { status: "error"; message: string };

          type UserFilters = {
            search: string;
            role: "all" | "admin" | "editor" | "viewer";
          };

Filtered data:

          function filterUsers(users: User[], filters: UserFilters): User[] {
            return users.filter((user) => {
              const matchesSearch =
                user.name.toLowerCase().includes(filters.search.toLowerCase()) ||
                user.email.toLowerCase().includes(filters.search.toLowerCase());

              const matchesRole =
                filters.role === "all" || user.role === filters.role;

              return matchesSearch && matchesRole;
            });
          }

State-aware rendering:

          function UsersTable({ state, filters }: {
            state: TableState<User>;
            filters: UserFilters;
          }) {
            if (state.status === "loading") {
              return <TableSkeleton rows={6} />;
            }

            if (state.status === "error") {
              return <ErrorState message={state.message} />;
            }

            if (state.status === "empty") {
              return <EmptyState title="No users yet" />;
            }

            const visibleUsers = filterUsers(state.data, filters);

            if (!visibleUsers.length) {
              return <EmptyState title="No users match these filters" />;
            }

            return <UserRows users={visibleUsers} />;
          }

Pay attention to: Tables need real states. Loading, empty, error, filtering, sorting, and pagination are not optional details in a dashboard UI.

Many dashboard templates include light and dark mode. A common mistake is adding dark-mode styles as scattered CSS overrides across every component. This works at first, but it becomes difficult to maintain because each new page needs another set of manual color fixes. In a Material UI dashboard, theme values should be centralized in the MUI theme configuration, not repeated across random components.

A clean theme system should define palette values, background colors, text colors, card surfaces, border colors, and chart colors in one place. The theme mode should be stored in a predictable state and optionally persisted in localStorage. Components should use theme tokens instead of hardcoded colors. This keeps the dashboard consistent and makes future customization easier.

Problematic approach:

          function DashboardCard() {
            const darkMode = useDarkMode();

            return (
              <div
                style={{
                  background: darkMode ? "#111" : "#fff",
                  color: darkMode ? "#fff" : "#222",
                  border: darkMode ? "1px solid #333" : "1px solid #ddd"
                }}
              >
                Card content
              </div>
            );
          }

This forces every component to know the theme logic and repeat color values manually.

Better MUI theme setup:

          function createAppTheme(mode: "light" | "dark") {
            return createTheme({
              palette: {
                mode,
                background: {
                  default: mode === "dark" ? "#0f172a" : "#f8fafc",
                  paper: mode === "dark" ? "#111827" : "#ffffff"
                },
                text: {
                  primary: mode === "dark" ? "#f9fafb" : "#111827",
                  secondary: mode === "dark" ? "#cbd5e1" : "#64748b"
                }
              },
              shape: {
                borderRadius: 14
              }
            });
          }

Theme provider:

          function AppThemeProvider({ children }: { children: React.ReactNode }) {
            const [mode, setMode] = useState<"light" | "dark">(() => {
              return localStorage.getItem("dashboard-theme") === "dark"
                ? "dark"
                : "light";
            });

            const theme = useMemo(() => {
              return createAppTheme(mode);
            }, [mode]);

            useEffect(() => {
              localStorage.setItem("dashboard-theme", mode);
            }, [mode]);

            return (
              <ThemeProvider theme={theme}>
                <CssBaseline />
                <ThemeModeContext.Provider value={{ mode, setMode }}>
                  {children}
                </ThemeModeContext.Provider>
              </ThemeProvider>
            );
          }

Component using theme tokens:

          <Card
            sx={{
              bgcolor: "background.paper",
              color: "text.primary"
            }}
          >
            <CardContent>
              <Typography color="text.secondary">
                Total sales
              </Typography>
            </CardContent>
          </Card>

Pay attention to: Centralize theme logic. Use MUI theme tokens, persist the selected mode, and avoid scattering dark-mode colors across every component.

Many admin dashboard projects include login, signup, forgot password, or profile screens. A common mistake is designing those screens only as static pages without thinking about the workflow. Even in a frontend-only demo, the UI should still model useful states: submitting, invalid credentials, forgotten password, authenticated layout, unauthenticated layout, and redirect after login.

If the project uses Firebase, this becomes even more important because authentication and real-time data can affect what users see. A dashboard should not show admin pages before auth state is known. It should show a loading state while checking the session, then route users either to the dashboard or to the login page. Even for a portfolio project, this makes the app feel more realistic.

Problematic approach:

          function App() {
            return (
              <Routes>
                <Route path="/login" element={<LoginPage />} />
                <Route path="/dashboard" element={<Dashboard />} />
              </Routes>
            );
          }

This allows the dashboard route to render directly. There is no session check, no loading state, and no protected layout.

Better auth state model:

          type AuthState =
            | { status: "checking" }
            | { status: "authenticated"; user: DashboardUser }
            | { status: "unauthenticated" };

          function ProtectedRoute({ authState, children }: {
            authState: AuthState;
            children: React.ReactNode;
          }) {
            if (authState.status === "checking") {
              return <FullPageLoader label="Checking session..." />;
            }

            if (authState.status === "unauthenticated") {
              return <Navigate to="/login" replace />;
            }

            return <>{children}</>;
          }

Protected dashboard route:

          <Routes>
            <Route path="/login" element={<LoginPage />} />

            <Route
              path="/dashboard"
              element={
                <ProtectedRoute authState={authState}>
                  <DashboardLayout />
                </ProtectedRoute>
              }
            />
          </Routes>

Login form state:

          type LoginFormState =
            | { status: "idle" }
            | { status: "submitting" }
            | { status: "error"; message: string };

          <Button
            type="submit"
            disabled={loginState.status === "submitting"}
            variant="contained"
          >
            {loginState.status === "submitting" ? "Signing in..." : "Sign in"}
          </Button>

Pay attention to: Authentication screens should represent real workflow states. Even if the project is mostly UI, model protected routes, loading states, form errors, and redirects clearly.