# Chart and Dashboard Visual QA Workflow from Figma > Compare implemented charts and dashboards with Figma across realistic data, axes, legends, empty states, responsiveness, and interaction states. - Canonical page: https://www.hypermatic.com/articles/pixelay-chart-and-dashboard-visual-qa-workflow-from-figma/ - Published: 2026-09-18T00:00:00.000Z - Updated: 2026-09-18T00:00:00.000Z A dashboard can match Figma when it contains tidy sample data and still fail the moment production values arrive. Axis labels collide, a legend wraps into the plot, a zero becomes an empty card, negative values escape the scale, and a mobile chart becomes too compressed to read. [Pixelay](/pixelay/) compares Figma frames with live, staging, local, and authenticated webpages using overlay, split, difference, and other visual modes. For data visualization, the useful comparison unit is not "the dashboard." It is one chart with a known dataset, viewport, and interaction state. ## Turn sample data into named fixtures Create deterministic fixtures that exercise the visual system. A practical set includes: - typical values - all zeros - one extreme outlier - negative and positive values - missing points - one category and many categories - long labels and large numbers - loading, empty, stale, partial, and error states - dense time series across daylight-saving or month boundaries Give each fixture a stable URL, query parameter, seeded account, or mocked response. Record the dataset version with the matching Figma frame. If production data changes during review, overlays cannot tell you whether the implementation drifted or the inputs changed. This is more specific than a general [dashboard QA workflow](/articles/pixelay-dashboard-qa-workflow-from-figma/). The focus here is the chart grammar itself: scales, marks, labels, legends, tooltips, and data states. ## Compare the frame before the marks Align stable dashboard landmarks first: page container, card boundary, title, controls, and neighboring panels. Then inspect internal chart geometry. Check plot width and height, card padding, title baseline, subtitle spacing, control placement, and reserved areas for axes and legends. A charting library may add its own margins, making every line or bar look displaced even when the data mapping is correct. Use Pixelay's overlay or difference view to identify systematic offsets. If all cards are shifted, fix the grid. If only plotted marks differ, investigate scales, data, or rendering options. ## Verify the visual encoding For each chart type, compare the decisions that carry meaning: - axis domain, baseline, interval, and tick formatting - bar width, spacing, grouping, and stacking - line thickness, interpolation, and missing-point behavior - point size and overlap - area opacity and stacking order - threshold and reference lines - categorical colors and legend order - number, currency, percentage, and date formatting Do not force implementation to match a misleading design. A truncated axis or inconsistent scale may be a design defect. Record the discrepancy, agree on the correct rule, and update Figma and code together. Color needs a non-color companion when series or statuses must remain distinguishable. Test contrast, patterns or markers where appropriate, and what happens in forced-colors or high-contrast settings. ## Test tooltips and selection states Static screenshots miss much of a chart's behavior. Capture hover, keyboard focus, selected series, filtered state, zoom, brush, drill-down, and crosshair if supported. Verify tooltip position, collision avoidance, content order, formatting, and behavior near viewport edges. Keyboard users should be able to reach meaningful interactive data without traversing hundreds of useless points. Focus must remain visible, and screen-reader output needs an equivalent summary or accessible data representation. Pixelay can expose spatial drift, but semantic and input behavior still require manual accessibility testing. For every defect, record the fixture, route, viewport, chart ID, active filters, interaction state, Figma frame, comparison mode, and expected rule. "The graph looks wrong" is not replayable evidence. ## Stress responsive dashboards Test breakpoint boundaries, not just standard desktop and mobile widths. Watch for legends moving, axis labels rotating, cards changing order, controls collapsing, and charts switching from detailed to summarized views. At narrow widths, preserving every label can make the chart unusable. The intended design may legitimately reduce tick density, move the legend, or provide a horizontally scrollable plot. Compare against the corresponding responsive frame and verify that the data meaning remains intact. Also test browser zoom and enlarged text. A chart canvas may scale while surrounding HTML labels reflow differently, creating overlap that a fixed screenshot never predicts. ## Review loading and failure honestly Skeletons should resemble the final card closely enough to avoid disruptive layout movement. Empty states must distinguish "no activity," "filters removed all results," and "data unavailable." Stale or partial data needs visible status when users might otherwise make a decision from it. Never render zero as a fallback for a failed request. A visually perfect zero can be a more serious defect than an obvious error because it communicates false information. Pair chart checks with the [visual bug report workflow](/articles/pixelay-visual-bug-report-workflow-for-frontend-teams/) so data and design issues reach the correct owner. Before signoff, cover representative and adversarial fixtures, visual encodings, interactions, responsiveness, accessibility, loading, empty, stale, partial, and error states. Pixelay makes comparison precise when the dataset and state are controlled. That lets designers and developers spend less time debating whether a chart feels off and more time deciding whether the implementation communicates the data truthfully.