# Notification Center QA Workflow from Figma > Compare built notification feeds against Figma across unread, grouped, empty, loading, and responsive states before subtle hierarchy bugs reach users. - Canonical page: https://www.hypermatic.com/articles/pixelay-notification-center-qa-workflow-from-figma/ - Published: 2026-07-31T00:00:00.000Z - Updated: 2026-07-31T00:00:00.000Z Notification centers look simple in a static mockup: an icon, a badge, a panel, and a list. The built version must handle twenty unread items, a long actor name, missing avatars, grouped updates, stale timestamps, permission differences, and an empty state—all inside a surface that may be only a few hundred pixels wide. That makes notification UI especially vulnerable to implementation drift. A small spacing or truncation change can erase the distinction between read and unread items. A sticky header can cover the first row. A drawer that matches Figma on desktop may overflow on a narrow phone. This workflow uses [Pixelay](/pixelay/) to compare the staging implementation with its Figma source, then triage visual differences without confusing them with behavioral or accessibility testing. ## Establish the state matrix first Do not approve the notification center from one ideal fixture. List the states that the product actually supports: - Closed icon with zero unread - Closed icon with one- and multi-digit badge counts - Open panel with mixed read and unread items - Grouped notifications - Long list with scrolling - Loading and incremental loading - Empty state - Error and retry state - Mark-all-read action - Item without an avatar or thumbnail - Long names and localized strings - Reduced-permission or role-specific feeds - Mobile full-screen or drawer presentation Map each state to a Figma frame and a reproducible staging condition. If a design does not exist for an important state, log a design gap instead of selecting the nearest attractive mockup. ## Use controlled notification fixtures Random production-like data makes comparison noisy. Ask engineering for seeded fixtures or a test account that can produce known items. A useful set includes: ```text 1 short unread item 1 read item 1 item with a two-line message 1 item with no avatar 3 grouped items 1 timestamp near a boundary Enough rows to force scrolling ``` Keep dates stable if possible. A screenshot that changes from “59 minutes ago” to “1 hour ago” during review creates false differences and makes annotations harder to reproduce. Document the route, account, viewport, feature flags, and fixture used for each comparison. ## Compare the shell before individual rows Open the matching staging surface with Pixelay and use overlay, split, or difference modes to inspect the large structure first: - Panel width and anchoring - Distance from the notification trigger - Header height - Border radius and shadow - Viewport edge behavior - Footer or pagination position - Scroll container height If the shell is wrong, every child row will appear displaced. Fixing individual margins before the container geometry wastes time. For a modal- or drawer-wide treatment, the [modal and drawer QA workflow from Figma](/articles/pixelay-modal-and-drawer-qa-workflow-from-figma/) covers backdrop, focus surface, and page-layer concerns. This article focuses on the dense feed and its notification-specific states. ## Inspect information hierarchy row by row Notification rows usually combine actor, action, object, time, status, and optional media. Compare: - Avatar size and fallback treatment - Baseline alignment across mixed text weights - Line height for wrapped messages - Timestamp placement - Unread dot or background - Separator length and contrast - Thumbnail crop - Hover, focus, and selected states The important question is not merely whether a pixel differs. Ask whether the difference changes comprehension. If implementation makes unread status almost indistinguishable, that is more urgent than a two-pixel icon offset. Check one-line and multi-line rows next to each other. Fixed-height implementation can clip content or create inconsistent vertical centering. ## Test badge behavior separately The trigger badge is a tiny component with outsized visibility. Review: - Zero-state visibility - Single digit - Double digit - Maximum display such as `99+` - Position at browser zoom - Collision with the underlying icon - Color and contrast - Live update after marking items read The Figma source should show the expected cap and shape change. If it does not, ask product and design to decide rather than letting CSS behavior become the de facto specification. ## Review scrolling and sticky regions Populate enough notifications to exceed the available height. Then verify: - The header remains visible only if intended. - The first and last rows are not hidden. - The scrollbar does not cover content. - Mark-all-read remains reachable. - Loading indicators appear inside the correct region. - The page beneath does not scroll unexpectedly. - Returning to the panel preserves or resets position as designed. Pixelay can expose visual displacement while the long list is open. Behavioral checks still need direct interaction and browser tools. ## Check responsive and localized stress states Run comparisons at the exact viewports represented in Figma, then explore intermediate widths. Notification surfaces often switch from anchored popover to drawer or full-screen page; confirm where that transition occurs. Use long but realistic content: - Multi-part personal names - Verbose project names - German or Finnish UI strings - Right-to-left text if supported - Dates in the product’s localized format Look for unexpected truncation, badge collision, hidden actions, and rows that grow without preserving rhythm. A perfect English fixture is not evidence that the component is robust. ## Triage with reproducible evidence For each issue, capture: - Staging URL - Figma frame - Viewport - Account or fixture - Actual screenshot - Expected overlay - Comparison mode - Severity and user impact Group defects by owner: - **Shell/layout:** panel geometry, anchoring, scroll region - **Component:** row spacing, avatar, badge, separator - **Content:** wrapping, truncation, timestamp format - **State logic:** read status, grouping, count - **Accessibility:** focus, announcement, contrast, semantics Pixelay annotations help point to visual mismatches, but state-logic and accessibility findings should enter the team’s normal issue system with the additional evidence they require. ## Re-test the fix and nearby states When a row-height fix lands, repeat more than the failing screenshot. Check short rows, grouped rows, scrolling, and mobile presentation. CSS changes in dense lists often solve one fixture and disturb another. Use the same viewport and seeded data for the direct before-and-after comparison. Then run a lightweight regression across the state matrix. The broader [visual regression testing workflow](/articles/pixelay-visual-regression-testing/) can help teams decide how these targeted reviews fit into repeated release checks. ## Notification-center signoff checklist Before approving the implementation, confirm: - Every supported state has a design or an explicit decision. - Seeded data covers short, long, missing, grouped, and overflow content. - Panel geometry matches at documented viewports. - Read and unread hierarchy remains clear. - Badge counts handle zero, double digits, and the maximum. - Long lists scroll without hiding controls or rows. - Empty, loading, and error states are implemented. - Responsive mode changes match the intended breakpoint. - Localization stress tests do not hide essential actions. - Keyboard, focus, screen-reader, and live-update behavior were tested separately. - Fixes were rechecked against neighboring states. Pixelay makes visual comparison faster by bringing the built page and Figma design into the same review. Notification quality still depends on realistic data and interaction testing. Use overlays to find drift, then validate the feed as a living system rather than a polished empty rectangle.