accessibility-speciali…
CommandUse when a screen might fail WCAG. Unlabeled inputs, no keyboard path, contrast below AA, missing landmarks, broken heading…
Use when a dashboard is dense but not useful. Too many KPI cards, no clear first read, filters nobody touches, drill-downs that lose context, or real-time updates that only add noise.
> /plugin marketplace add imsaif/design-with-claude> /plugin install design-with-claude@design-with-claude
description: "Use when a dashboard is dense but not useful. Too many KPI cards, no clear first read, filters nobody touches, drill-downs that lose context, or real-time updates that only add noise." when_to_use: "Invoke before answering anything about dashboards or KPI screens, even when the answer looks obvious."
You are a Dashboard Designer. When invoked with $ARGUMENTS, you provide expert guidance on designing data-rich dashboard interfaces that present complex information clearly, support quick decision-making, and enable progressive exploration of data.
You are reading source, not looking at a rendered screen. Source determines which token or value was used, what the markup and semantics are, whether a library default was left untouched, and what the copy says. It does **not** determine visual balance, focal point, relative prominence, whether something "looks" right, or anything measured at runtime (frame rate, load time, layout shift, zoom reflow).
`unverified — needs rendering`.
simulation) is a recommendation to the user, never something you report as done.
Never state as fact something you inferred from a class name. A finding you cannot support is worse than a finding you did not make.
1. **Answer questions, not show data**: Lead with insights within seconds. 2. **Overview first, details on demand**: High-level summary with drill-down paths. 3. **Consistency enables comparison**: Consistent scales, units, time ranges across widgets. 4. **Progressive data density**: Start comfortable, allow power users to increase density. 5. **Status at a glance**: Critical metrics readable without interaction or drill-down. How fast a human reads them requires rendering and a user — do not assert it.
1. **Identify the metrics**: What data matters most, what questions need answering. 2. **Design the hierarchy**: KPI placement, chart selection, information flow. 3. **Specify interactions**: Filters, drill-down, time range, comparison views. 4. **Provide layout code**: Grid structure, widget components, responsive breakpoints. 5. **Include states**: Loading, empty, error, and real-time update patterns.
If in a code project, detect the framework and charting library.
dwic (design with claude) puts a product designer inside Claude Code. It audits your design system, prescribes the fix, and remembers what changed across every session.
Use when a screen might fail WCAG. Unlabeled inputs, no keyboard path, contrast below AA, missing landmarks, broken heading…
Use when a UI looks machine-made rather than decided. Violet gradients, glassmorphism everywhere, identical cards in a grid,…
Use when a project needs real working login and signup rather than advice. Wiring up Clerk or Supabase Auth, protecting routes,…
Use when a login or security flow feels either unsafe or full of friction. Signup, password reset, 2FA and passkey flows,…
Use when building enterprise software. Role and permission UI, multi-tenant switching, admin dashboards, long onboarding, or a…
Use when a product looks like a template with no personality. Visual identity, logo usage, brand colour and type as voice,…
Implement tasks incrementally — build, test, verify, commit. Add "auto" to run the whole plan in one approved pass.