# Data Table Visual QA Workflow from Figma

> Compare production data tables with Figma across realistic content, responsive layouts, sticky regions, and interaction states before release.

- Canonical page: https://www.hypermatic.com/articles/pixelay-data-table-visual-qa-workflow-from-figma/
- Published: 2026-08-07T00:00:00.000Z
- Updated: 2026-08-07T00:00:00.000Z

Data tables often look correct in a design review because the sample content is unusually cooperative: short names, even numbers, one page of rows, and no permissions edge cases. The build meets real data and suddenly columns jump, headers wrap, sticky regions drift, and actions disappear below the fold.

Visual QA for a table must compare more than one pristine viewport. It needs representative data, interaction states, density settings, and responsive behavior.

## Agree on the table contract

Before comparing pixels, document what the table is supposed to do. Identify required columns, optional columns, default sort, alignment, truncation rules, row actions, selection behavior, pagination or virtualization, sticky headers, horizontal scrolling, and narrow-screen treatment.

Separate deliberate implementation decisions from bugs. If engineering changed a column width to accommodate localized values, the team should update the design or record the approved exception—not repeatedly report the same difference.

Create a small matrix for the review:

| Dimension | Cases to include |
| --- | --- |
| Content | shortest, longest, empty, unknown, negative, large value |
| State | loading, populated, no results, error, partial permission |
| Interaction | hover, focus, selected, sorted, expanded, menu open |
| Viewport | wide desktop, common laptop, narrow supported width |
| Density | default and compact, if supported |

## Seed data that exposes layout failures

QA data should be valid but adversarial. Use long customer or file names, large localized currency values, multiple date formats, missing avatars, several status badges, and text that includes non-Latin characters if the product supports them.

Include enough rows to trigger sticky headers, pagination, lazy loading, or virtualization. A five-row fixture cannot prove that the 100th row aligns with the header. Include rows with and without actions, disabled controls, and permission-restricted values.

Protect sensitive information. Use fabricated records that preserve the shape of production data rather than copying real customer names, emails, account balances, or health information into screenshots and test environments.

## Establish an honest comparison

[Pixelay](/pixelay/) aligns Figma designs with live, staging, local, or authenticated web pages and provides comparison modes including overlay, split-screen, and difference views. Open the exact implementation state and match the design frame’s viewport, zoom, and content as closely as possible.

Control avoidable noise before triage:

- wait for fonts and rows to finish loading;
- close browser extensions or banners that alter layout;
- match density and feature-flag settings;
- use the same sidebar and navigation state;
- freeze or record time-sensitive values;
- confirm device pixel ratio and browser zoom.

Use overlay mode to spot systematic column and baseline drift. Use split view when different live content makes a direct overlay noisy. Difference views can reveal borders and spacing changes, but they do not decide whether the implementation is semantically correct.

The [authenticated product-flow QA guide](/articles/pixelay-design-qa-for-authenticated-product-flows/) helps with access and repeatable private states. Table QA adds content extremes and scrolling behavior that a single product-flow comparison may miss.

## Review from structure to detail

### Table frame and controls

Compare the title, count, filters, search, bulk actions, export controls, and table container before individual cells. A 16-pixel drift in the toolbar can shift every row and create hundreds of misleading differences.

### Columns and cells

Check header and cell alignment, width allocation, numeric alignment, truncation, wrapping, badges, icons, avatars, and row height. Ensure blank values use the designed placeholder and do not collapse the cell. Confirm sortable headers communicate state visually and accessibly.

### Sticky and scrolling behavior

Scroll vertically and horizontally. Sticky headers should remain aligned with columns. Frozen first columns should not cover cell content or lose their divider. Menus and tooltips near container edges should remain visible rather than being clipped by overflow.

### Interaction states

Use keyboard navigation as well as the pointer. Compare focus rings, selection, hover, expanded rows, inline editing, validation, action menus, and confirmation states. A table can match the static design while being unusable once an editor opens.

## Test responsive decisions explicitly

A dense table may scroll horizontally, hide low-priority columns, switch to cards, or offer a column chooser. Compare the implemented rule with the design rather than expecting every desktop column to compress indefinitely.

At each supported width, test the longest fixture and an open menu. Verify that the primary identifier remains visible, headers still correspond to cells, row actions are reachable, and sticky regions leave enough usable space. If the product does not support small screens for a complex administration table, communicate that constraint intentionally instead of letting it fail unpredictably.

This workflow differs from [search results and filter-state QA](/articles/pixelay-search-results-and-filter-state-qa-workflow-from-figma/). Search QA focuses on query controls and result states; table QA focuses on column geometry, cell content, dense interactions, and two-directional scrolling.

## Triage differences by pattern

Group bugs instead of reporting every affected cell:

- **Systemic:** all row heights or text baselines differ.
- **Column-specific:** one width, alignment, or renderer is wrong.
- **Content-specific:** long values or missing data break the layout.
- **State-specific:** selection, loading, error, or permissions diverge.
- **Viewport-specific:** sticky or responsive behavior fails at a width.

Attach the URL, viewport, fixture, user role, table settings, reproduction steps, expected Figma frame, and a screenshot or comparison capture. Note whether the mismatch blocks a task or is cosmetic. One precise systemic issue is more actionable than 40 screenshots of repeated row drift.

## Release checklist

- The table contract and approved implementation exceptions are documented.
- Fixtures include extreme values, missing content, multiple scripts, and enough rows to scroll.
- Loading, empty, error, permission, and populated states are covered.
- Viewport, zoom, fonts, density, role, and flags match the comparison frame.
- Toolbars, headers, cells, numeric alignment, badges, and row heights are reviewed.
- Sticky headers, frozen columns, horizontal scrolling, and overflow layers work.
- Keyboard focus, selection, editing, sorting, menus, and validation match intended states.
- Responsive behavior preserves identifiers and reachable actions.
- Issues are grouped by systemic, column, content, state, or viewport pattern.
- Sensitive production data is absent from fixtures and captures.

The aim is not a screenshot-perfect table with fake data. It is a resilient implementation that preserves hierarchy, alignment, and usable actions when real content puts the design under pressure.