improve-dashboard-ui

name

improve-dashboard-ui

description

Audit, review, and improve dashboard, admin, analytics, CRM, finance, ops, and other dense data interfaces. Use this skill whenever the user wants to review or critique a dashboard, make one look more professional, improve tables / cards / charts / activity logs / data grids, design onboarding for dashboard workflows, or fix a data interface that feels generic, cluttered, flat, or beginner-made — even when they never say the word "dashboard" (admin panels, internal tools, data tables, reporting screens, metrics views, and back-office UIs all count).

Improve Dashboard UI

Overview

Use this skill to make dashboards feel built around real data and real workflows, not decoration. Favor the smallest UI change that makes the data easier to scan, compare, act on, or understand.

Keep the trigger file lean; load the references only when the task needs that depth.

Workflow

1. Inspect the actual data shape before changing layout.
2. Let each data type choose its visual form.
3. Rank actions by importance and frequency before deciding what stays visible.
4. Add the hidden UI states and affordances that make the interface usable.
5. Verify with realistic data density, long values, empty states, and edge cases.

References

• Read references/source-principles.md when you need the full reasoning behind the skill or want to explain the three dashboard failure modes.
• Read references/dashboard-patterns.md when implementing tables, timelines, charts, contextual surfaces, onboarding, or hidden interaction states.
• Read references/audit-playbook.md when reviewing an existing dashboard, producing recommendations, or planning a focused improvement pass.

Data Drives Form

Start by listing the fields, cardinality, units, ranges, and time dimensions. Then choose the UI treatment from the data:

• Finite categories: use compact chips, badges, or segmented labels.
• Status and urgency: use semantic color only when it comes from the data.
• Numbers and money: right-align values, use tabular numerals where available, and keep units consistent.
• Long text: truncate in dense views and expose the full value on hover, focus, drawer, or detail view.
• Time-based records: consider a timeline, activity feed, trend chart, or grouped date sections instead of a plain timestamp table.
• People and ownership: use avatars or initials only when recognition helps scanning faster than names alone.
• Inactive, archived, failed, or deactivated records: visually de-emphasize without hiding them unless the workflow calls for filtering.

Avoid color, icons, charts, or cards that do not explain a property of the data or speed up a user decision.

Progressive Disclosure

Place every action on a spectrum of explicitness:

• Always visible: primary workflow actions, critical filters, destructive warnings, and high-frequency controls.
• Visible in a popover, drawer, or row expansion: useful secondary workflows that should not send the user to a new page.
• Visible on hover, focus, swipe, or row selection: low-frequency row actions such as copy, quick comment, remove, share, or more details.
• Sequenced over time: onboarding, empty-state guidance, checklists, and first-run tooltips.

Do not explain the whole product in one modal. Sequence the next useful action, then reveal the next layer after the user engages.

To place an action quickly, weigh three things: how often it is used, how important it is to the core workflow, and how reversible it is. Frequent and important earns persistent visibility. Rare and reversible (copy a cell, view details) belongs on hover, focus, or in an overflow menu. Rare but destructive (delete, revoke access) stays discoverable but guarded by confirmation or undo — low frequency does not justify hiding something dangerous. When space is tight, the deciding factor is usually frequency: the dashboard should feel calm for the action the user takes a hundred times a day.

Hidden UI Checklist

Beginner dashboards usually miss the UI that is not visible at first glance. Add only the pieces needed by the actual workflow:

• Tooltips for ambiguous icons, metric labels, abbreviations, and disabled actions.
• Hover and focus states for dense interactive rows, cells, icons, charts, and chips.
• Copy affordances for IDs, emails, URLs, codes, and table cells users will reuse elsewhere.
• Row expansion, side drawers, or popovers for details that would overload the main table.
• Empty, loading, error, disabled, selected, edited, unsaved, and permission-denied states.
• Filter, search, sort, pagination, and density behavior for realistic record counts.
• Keyboard focus and accessible names for icon-only controls.
• Confirmation or undo for destructive actions.

Dashboard Review Pass

When reviewing an existing dashboard, report changes in this order:

1. Data-form mismatches: fields shown in the wrong shape, weak alignment, unnecessary columns, missing summaries, or tables that should be timelines/charts.
2. Disclosure mistakes: actions that are too visible, too hidden, sent to unnecessary pages, or not sequenced for first-time users.
3. Missing invisible UI: states, tooltips, hover/focus affordances, detail surfaces, and workflow feedback.
4. Visual polish only after the above: spacing, sizing, contrast, hierarchy, and icon consistency.

Prefer concrete edits over abstract advice. Lead with the finding that costs the user the most scanning or clicking, not the easiest cosmetic fix. Write each finding so the reader can act without a second conversation:

• What — the specific element, column, or interaction.
• Why — the data property or workflow that the current form ignores.
• Change — the concrete edit, named in the app's own components.
• Payoff — what the user can now do faster, compare more easily, or stop missing.

A worked finding, so the shape is concrete:

Employment-status column reads as plain text. The field has only three values (Active, On leave, Terminated), so it is a category, not free text — yet it renders like a name, forcing the eye to read each cell. Replace the text with status chips and de-emphasize terminated rows (reduced contrast, not hidden). The user can now scan who is active in one pass instead of reading every row.

The fuller worked review in references/audit-playbook.md shows this format applied across a whole screen.

Implementation Rules

• Reuse the app's existing design system, table components, charts, icon set, and spacing tokens.
• Prefer native controls and existing dependencies over new UI libraries.
• Keep dashboards quiet and operational: dense enough to scan, restrained enough to use repeatedly.
• Do not add decorative color, gradients, oversized cards, or landing-page composition to operational dashboards.
• Test with at least one dense row/table state, one empty/loading/error state if changed, and one mobile or narrow viewport when the dashboard is responsive.