Mac dashboard QA checklist for colors and CPU

The short answer: before sending a dashboard screenshot or screen sharing a live dashboard, freeze the filter state, capture the exact view, sample chart and legend colors from the rendered screen, check readability, watch CPU and memory, then save one QA note that another person can follow.

This is for analytics dashboards, client reports, internal KPI screens, status boards, sales snapshots, product metrics, and any browser-based dashboard where the screenshot becomes the decision record.

Disclosure: I build TeenyApps, including TeenyColor for local color sampling and TeenyStat for first-pass system vitals. My bias is toward small native Mac utilities. Apple's built-in Screenshot app, Digital Color Meter, and Activity Monitor still belong in the workflow when they are the better fit.

Use the paired TeenyColor guide to check dashboard chart colors on Mac when chart series, legends, labels, and contrast need a tight review note. Use the paired TeenyStat guide for slow Mac dashboards in the browser when the review may be affected by CPU, memory, browser tabs, or screen sharing.

For existing adjacent workflows, use the Mac data review checklist when the risk is the source CSV or display layout, the product page QA checklist when the risk is a public launch page, and the bug report checklist when you are filing a defect instead of approving a report.

Dashboard QA decision table

01Freeze the dashboard state before sampling anything

Dashboard QA starts with context, not pixels. Write down the report name, account, date range, comparison period, selected segment, timezone, data refresh time, and any hidden filters. If the dashboard has a "last updated" stamp, capture it in the screenshot or include it in the note.

This matters because a dashboard can change between the first color sample and the final screenshot. A scheduled refresh may move a chart. A live filter can switch a cohort. A stakeholder may compare your screenshot with a different date range and think the color or number is wrong.

If the dashboard is built from source files you are still reviewing, start with the Mac data review checklist. The dashboard QA pass assumes the source data is already accepted and the job is to prove the rendered review view.

02Capture the exact view that will be reviewed

Use Apple's screenshot tools for the evidence itself. Capture the full browser window when the surrounding filters, legends, or refresh timestamp matter. Capture a selected portion only when the review is local to one chart, one KPI card, or one tooltip.

Do not sample from a scaled chat preview or a compressed image pasted into a doc. Open the dashboard or exported screenshot at the size people will review. A crop can be useful for a focused question, but keep one wider screenshot nearby so the context is not lost.

If the dashboard includes private customer data, internal revenue, unreleased features, or client names, keep the color and system checks local until the screenshot is sanitized. A small local utility should reduce the need to paste private dashboards into random web tools.

03Sample chart colors from the rendered dashboard

A chart color is useful only when it is tied to a role. Sample and name the values as "actual revenue line", "forecast line", "warning badge", "selected segment", "muted grid line", "axis label", or "legend background". A loose hex value does not help the next reviewer.

TeenyColor fits this pass because its homepage and Swift source confirm native screen sampling with NSColorSampler, sRGB conversion, selected clipboard formats, local history, names, pins, palette export, and quick contrast badges against white and black. Use it when the dashboard is private or when the review note needs clean copied values.

Apple's Digital Color Meter is still a valid built-in reference for reading color values from the display. TeenyColor earns its place when you need local history, naming, pins, or a small exported palette for the review note.

If the dashboard uses color to show success, warning, critical, selected, or disabled states, do not approve by eye alone. Sample the state in the browser, then compare it with the intended token, design note, or previous approved screenshot.

04Check label contrast where the dashboard is dense

Dashboards often fail in the quiet parts: tiny axis labels, gray legends, disabled filters, pale trend lines, tooltip text, or white labels on saturated chart colors. Sample the foreground and background pair instead of arguing from memory.

WCAG 2.2 Success Criterion 1.4.3 uses 4.5:1 for normal text and 3:1 for large-scale text at Level AA. Non-text UI parts and graphical objects have their own contrast criterion. If the dashboard is not a public web page, the same numbers still make a useful review rule because they turn "hard to read" into a specific finding.

Be honest about limits. TeenyColor's quick badges cover sampled colors against white and black. For a real chart label on a custom card, sample both the label and the exact background, then include both values in the note.

05Watch CPU and memory before a live dashboard review

A dashboard can look broken when the Mac is the problem. Heavy browser tabs, video calls, cloud sync, large exports, local databases, and screen-sharing apps can all compete for CPU or memory before the review starts.

TeenyStat is useful as a first signal because its homepage and source confirm CPU usage, memory usage, fan speed where available, per-core CPU view, 60-point sparklines, session high and low values, threshold colors, and alerts. The app reads CPU with host_processor_info, memory with host_statistics64, and fan data through SMC keys when the Mac exposes fans.

The boundary is simple: TeenyStat tells you the Mac is busy. Activity Monitor tells you which process is busy. If the dashboard review depends on process names, memory pressure, a quit decision, or a before-and-after screenshot of the culprit, open Activity Monitor and capture that evidence.

Do this before the screen share starts. Once a call is live, the meeting app itself becomes part of the load, and it is harder to tell whether the dashboard, browser, call, or another process caused the slowdown.

06Save one QA note with the screenshot

The best dashboard QA note is small enough to read and specific enough to rerun. Put the dashboard context, screenshot filename, important color samples, contrast concerns, and system state in one place.

A useful note looks like this:

1. Dashboard: name, account, date range, segment, timezone, and refresh time.
2. Evidence: screenshot filename and whether it is full window or cropped.
3. Color samples: chart role, sampled value, and whether it matches the expected value.
4. Readability: any foreground/background pair that needs review.
5. System state: CPU and memory looked normal, or Activity Monitor evidence attached.
6. Decision: approved, approved with caveat, blocked, or needs a new export.

This note prevents the common dashboard-review failure: someone approves a screenshot, then later nobody knows which filter, display state, or browser state produced it.

Sources checked

• Apple Support: Take a screenshot on Mac for full-screen, selected-portion, window, menu, and Screenshot app capture paths.
• Apple Support: Digital Color Meter User Guide for Mac for reading color values from pixels on the display.
• Apple Support: View CPU activity in Activity Monitor on Mac for CPU history, current CPU usage, and process-level CPU context.
• Apple Support: View memory usage in Activity Monitor on Mac for memory pressure and memory-use context.
• W3C WAI: Understanding Success Criterion 1.4.3 Contrast (Minimum) for text contrast thresholds.
• TeenyColor claims were checked against the TeenyColor homepage and local Swift source for NSColorSampler, sRGB conversion, copy formats, local history, names, pins, palette export, and contrast badges.
• TeenyStat claims were checked against the TeenyStat homepage and local Swift source for CPU, memory, fan speed where available, sparklines, per-core CPU view, threshold colors, and alerts.

Common questions

How do I QA a dashboard screenshot on Mac?

Freeze the filter state, capture the exact dashboard view, sample important chart and legend colors, check text contrast, record CPU and memory state, and include the screenshot plus settings in one review note.

Should dashboard color checks use the design file or the browser?

Use the rendered browser or exported screenshot for QA evidence. The design file explains the intended colors, but the browser proves what reviewers and stakeholders saw.

When should I open Activity Monitor during dashboard QA?

Open Activity Monitor when CPU or memory stays high, the browser stops responding, the Mac gets hot, or the report needs the process name. A menu bar monitor is a first signal, not the final diagnosis.