Design patterns
Dashboard UI design with AI: start with the decisions
Plan a dashboard around actions, comparisons and data states instead of filling a grid with charts. Includes a support-team example and implementation prompt.
A dashboard needs a job
Design a dashboard by naming the decision someone should make after reading it. For a support lead, that might be deciding which queue needs help this morning. Put the evidence for that decision together: waiting conversations, age of the oldest unresolved item and available staff. A row of unrelated totals can look complete while answering none of those questions.
Separate monitoring from investigation. The overview should help someone notice a problem and reach the relevant records. It does not need to display every metric the business collects. Decide what the user can do after noticing an exception.
Work through a support-team example
Imagine two queues: Billing has 30 waiting conversations and Technical has 12. A total alone suggests Billing is more urgent, but Technical’s oldest conversation may have waited much longer. Include the context that changes the staffing decision. Label the time window and make the route to each queue obvious.
Use synthetic values during design and label them as sample data. Define what zero, missing and stale values mean before asking an agent to draw charts. “No conversations waiting” is different from “Queue data unavailable.” Neither should quietly become a convincing-looking zero.
Choose references for comparison and hierarchy
In Taste, gather references for aligned comparisons, readable trend labels and an overview-to-detail transition. Annotate the relationship you want to preserve. If a reference uses a large chart, explain whether the trend matters to your decision; do not copy the chart simply because it fills the space.
Ask the agent to inspect the app’s current navigation and table components. A dashboard that invents a separate system of controls becomes harder to maintain and learn. Decide how the overview changes on mobile: preserve the priority order rather than compressing every panel equally.
Brief the implementation and review the exceptions
The following prompt describes an illustrative support workflow. Replace the metrics and available actions with real requirements.
Design the support overview for this project. The lead needs to decide which queue needs help. Show waiting count, oldest waiting time and the relevant time window for each queue, with a link to its records. Inspect my Taste dashboard references and explain what each contributes. Reuse existing components. Use clearly labeled sample data. Include loading, stale data, no waiting conversations and a failed queue request. Explain which values are unknown rather than treating them as zero.
Check whether the overview earns its space
Try a quiet day, an unusually busy queue and one unavailable data source. Can someone identify the important queue and open it without decoding a chart legend? Check long queue names and a narrow layout. Review the underlying data definitions with whoever owns the metrics.
Remove a panel if you cannot explain which decision it supports. Keep a link to deeper reporting when the information is useful for analysis but not for the dashboard’s immediate task.