# Cookie Consent Banner Visual QA Workflow from Figma > Compare implemented cookie banners and preference centers with Figma across breakpoints, content states, and real page contexts. - Canonical page: https://www.hypermatic.com/articles/pixelay-cookie-consent-banner-visual-qa-workflow-from-figma/ - Published: 2026-07-24T00:00:00.000Z - Updated: 2026-07-24T00:00:00.000Z A cookie banner can pass functional testing and still ship with broken hierarchy. The buttons work. Preferences save. The script records a choice. But on the actual site, the banner covers a checkout action, the secondary option looks disabled, translated copy overflows, or the preference center no longer resembles the approved design. [Pixelay](/pixelay/) compares Figma frames with real websites, including staging, localhost, and private environments. That makes it useful for consent UI because these components need to be reviewed in the page context where they interrupt the user, not only as isolated design-system frames. This is distinct from [Modal and Drawer QA Workflow from Figma](/articles/pixelay-modal-and-drawer-qa-workflow-from-figma/) and [Responsive Website QA from Figma](/articles/pixelay-responsive-website-qa-from-figma/). Those cover overlay components or responsive implementation broadly. This workflow focuses on consent-specific states: first visit, preference expansion, saved choice, withdrawal, localization, and interaction with the page beneath. This is a visual implementation review, not a legal or consent-management audit. Privacy and engineering owners still need to verify the lawful model, stored choice, scripts, and regional behavior. ## Map the states before opening the overlay One Figma frame is not enough. List the implemented states that need a matching design: - first-visit compact banner - expanded preference center - category toggles - save confirmation - error or unavailable state - returning-user privacy settings - withdrawal or change-consent state - mobile layout - translated variants Also record the conditions needed to reproduce them. Consent UI often depends on region, browser storage, feature flags, and previous choices. Without that map, reviewers repeatedly clear cookies and hope the right screen appears. ## Stabilize the environment Visual comparison is only useful when the page and design represent the same conditions. Before reviewing: - use the intended viewport - reset the consent state - load the correct regional variant - disable unrelated experiments - wait for fonts and page content - use representative translation strings - note any browser UI affecting the viewport For staging or local environments, Pixelay can compare the real URL directly with the Figma frame. If the site requires authentication or private access, use the same setup your team uses for other protected QA flows. ## Compare the banner in real page contexts Consent UI rarely exists on a blank background. Test it over: - a landing-page hero - a long article - a form or checkout - a dark page section - a mobile screen with sticky navigation Look for: - insufficient contrast against the page - important content covered by the banner - page controls competing with consent actions - shadows or dividers disappearing on certain backgrounds - fixed elements stacking above the preference center - mobile browser height making actions unreachable The design-system component may be correct while its site integration is not. ## Review action hierarchy Overlay or difference modes can reveal spacing drift, but consent QA also needs a semantic visual check. Ask: - Is the intended primary action actually most prominent? - Does the secondary action still look interactive? - Are category toggles aligned with their labels and descriptions? - Is the close control present only where designed? - Does focus styling match the approved accessible state? A two-pixel difference is less important than an implemented button hierarchy that changes how users understand their choices. Classify findings so the team does not treat every mismatch equally: - `choice clarity` - `blocked content` - `responsive failure` - `accessibility presentation` - `cosmetic drift` ## Stress-test copy and localization Consent copy is unusually prone to late changes. Compare the implementation with: - longest approved heading - longest category description - narrowest supported width - increased browser text size - a long translated locale - error messages Watch for fixed-height panels, clipped descriptions, buttons wrapping inconsistently, and scroll areas whose final action is hard to reach. If the copy needs its own governance workflow, [Cookie Consent Copy Governance Workflow in Figma](/articles/copydoc-cookie-consent-copy-governance-workflow-in-figma/) covers the source-of-truth problem. Pixelay’s role here is verifying what the browser actually rendered. ## Check the page after a choice The review should not end when the banner disappears. After each path: - confirm the overlay is fully removed - check that page scroll is restored - look for layout jumps - verify sticky elements return to the correct position - reopen preferences and compare the saved state - make sure the page does not retain a stray backdrop or focus trap These are partly functional issues, but they often reveal themselves visually first. ## Run a compact breakpoint matrix You do not need every possible width. Choose breakpoints that expose different layouts: - narrow mobile - wide mobile or small tablet - desktop - one short-height viewport For each, compare the compact banner and expanded preferences. Short-height testing matters because a consent panel that fits on a tall phone can trap the save action below the fold on a laptop or mobile browser with reduced vertical space. ## Consent UI visual signoff Before release, confirm: - every implemented state has an approved reference - the correct regional and storage conditions were tested - banner and preference-center hierarchy match the design - page content and sticky controls are not obstructed - long copy and translated variants remain usable - focus, hover, disabled, and selected states are visible - the page recovers cleanly after the user chooses - mobile width and short-height layouts passed comparison - legal and functional checks have separate owners ## Where Pixelay helps [Pixelay](/pixelay/) makes consent UI review concrete by placing the real browser implementation against the approved Figma design. It does not prove that scripts respect the user’s choice or that the consent model is compliant. It helps answer a narrower but important question: did the interface users actually receive preserve the hierarchy, states, and responsive behavior the team approved? Review the component on real pages, reproduce the full state family, and prioritize mismatches that affect choice clarity. Consent UI is too consequential to approve from one tidy desktop frame.