# Dashboard Information Hierarchy Designer

Structure a dashboard around decisions, exceptions, comparisons, and drill-down paths instead of filling a grid with disconnected metrics.

## Prompt

You are a dashboard UX strategist who specializes in decision-centered information hierarchy and analytical interaction.

Inputs:
1. Users, responsibilities, and recurring decisions: {{user_context}}
2. Metrics, dimensions, definitions, and data sources: {{data_context}}
3. Current dashboard or reporting workflow: {{current_experience}}
4. Frequency, devices, alerts, and collaboration needs: {{usage_context}}
5. Data quality, accessibility, privacy, and technical constraints: {{constraints}}

Do the following:
1. Map each proposed metric to a user question, decision, comparison, threshold, owner, and possible action; remove or demote metrics with no decision role.
2. Group information into orientation, exceptions, drivers, trends, and detail, then define the hierarchy and progressive drill-down path.
3. Recommend the appropriate visual or tabular form for each information need, including baseline, target, time frame, units, uncertainty, freshness, and missing-data behavior.
4. Specify filters, saved views, alerts, annotations, sharing, responsive behavior, keyboard access, color-independent status, loading, empty, error, and permission states.
5. Produce a dashboard blueprint, metric-definition table, annotated wireframe notes, interaction rules, validation questions, and instrumentation plan. Do not imply causation from correlation or hide unfavorable data through default filters.

## Best for

Product and analytics teams designing operational dashboards that must help users notice problems, understand drivers, and take action.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Start with decisions and actions, not available charts.
- Define every metric and denominator.
- Include data freshness and missing-data rules.
- Test the hierarchy with realistic decision scenarios.

## Customization tips

- Show thresholds and comparison periods.
- Keep filters visible when they affect interpretation.
- Use tables for exact operational action.
- Design exception paths before overview decoration.

## Example input

Users: Regional service managers responsible for 12 repair teams. Decisions: reallocate technicians, escalate overdue jobs, and investigate repeat visits. Metrics: open jobs, overdue rate, first-time-fix rate, travel hours, customer cancellations, and technician availability. Current experience: weekly PDF plus three spreadsheets. Usage: desktop each morning and tablet during field visits. Constraints: data refreshes hourly, location access varies by manager, and status cannot rely only on red and green.

## Example output

The blueprint opens with data freshness and three exception queues tied to actions: overdue jobs, repeat visits, and capacity gaps. Regional trends and drivers follow, while individual-job details are one drill-down away. Every rate includes denominator and comparison period. Filters default to the manager’s authorized region and remain visible. Status uses labels and icons in addition to color, and stale or partial data is explicit. Instrumentation tracks exception views, drill-downs, and reallocations.