Define responsive behavior before choosing devices
A device list cannot replace component requirements. Hundreds of screen sizes can sit between two phones in a test lab. Start with the behavior each page and component must preserve as space changes.
For each component, define:
- The content and controls that must remain available
- The order elements should follow when columns stack
- The point where navigation changes form
- The way tables, charts, and code samples handle limited width
- The behavior of sticky controls, banners, modals, and chat widgets
- The image crop and focal point at each layout state
- The longest and shortest content the component must support
- The keyboard and touch interaction requirements
Use content to choose breakpoints. Resize the component until its layout stops working, then introduce a change. A familiar device width may provide a test point, but it should not dictate the design system.
Document the behavior beside the component specification. A developer should know whether a three-column comparison becomes a stack, a scrollable region, or a condensed summary. Marketing should know which fields and claims remain visible. QA should know the expected result.
Build a browser and device coverage matrix
Choose coverage from audience evidence and business risk. Review current analytics, sales and support records, browser support policy, and the systems your buyers use. If you lack reliable data, start with representative modern browsers and common viewport classes, then update the matrix after launch.
A useful matrix separates four concerns:
- Browsers: the current versions your policy supports, plus any older version your audience data requires.
- Operating systems: desktop and mobile systems that can change font rendering, form controls, and browser behavior.
- Viewport classes: narrow phones, wider phones, tablets, laptops, desktop screens, and large displays.
- Input methods: touch, mouse, keyboard, zoom, and screen-reader use where the acceptance plan requires it.
Do not promise identical rendering across the matrix. Require equivalent access to content, controls, and conversion paths. Minor font and spacing differences can remain. A blocked form or hidden pricing detail cannot.
Use browser emulation for fast coverage during development. Run critical paths on physical devices before approval. Emulation does not reproduce every keyboard, viewport, touch, performance, or embedded-script behavior.
Test every template with difficult content
A responsive system can pass with sample copy and fail after the content team starts publishing. Test the actual templates with content that strains the design.
Include:
- Long headlines and navigation labels
- Short cards beside long cards
- Large pricing values and detailed plan names
- Empty fields, missing images, and optional sections
- Long names, email addresses, and URLs
- Validation errors and success messages
- Tables with many columns
- Quotes, lists, captions, and footnotes
- Localized content when the site supports regions or languages
Your CMS preview should show the same component constraints editors will face on the live site. Add field guidance or validation when a length limit serves a real content need. Do not use tight limits to conceal a fragile layout.
Test combinations, not isolated blocks. A cookie banner, chat launcher, sticky call to action, and open mobile menu can compete for the same small screen. Your buyers experience the stack, not the components in separate stories.
Set measurable layout and accessibility checks
Visual approval needs testable limits. Define the conditions that count as a failure.
At minimum, check:
- No unintended horizontal page scrolling
- No clipped text, controls, or focus indicators
- Logical reading and focus order after layouts change
- Usable navigation at every supported width
- Images and video that stay within their containers
- Tables and diagrams with an intentional small-screen treatment
- Text zoom and browser zoom without lost content or function
- Touch controls with enough size or spacing
- Error messages that remain visible and tied to the right field
- Overlays that can open, close, scroll, and return focus
WCAG 2.2 Reflow sets a useful acceptance point: most content should work at a width equivalent to 320 CSS pixels without losing information or function or forcing two-dimensional scrolling. Some content, such as complex maps and data tables, may need a two-dimensional layout. Give those sections a deliberate treatment instead of letting the whole page overflow.
WCAG 2.2 Target Size (Minimum) sets a 24 by 24 CSS pixel minimum for pointer targets, with specific exceptions and spacing rules. Treat that as a floor. Primary navigation, form controls, and conversion actions should remain comfortable to use on touch screens.
Keep zoom available. Do not disable browser scaling to preserve a layout. A responsive design should adapt when a buyer enlarges content.
Test forms and conversion paths as systems
A responsive form can look correct while the conversion path fails. Test the browser interface, validation, form endpoint, CRM handoff, analytics event, and confirmation state together.
For each high-intent path, run these cases:
- A successful submission
- Missing and invalid fields
- A server or integration error
- A repeat submission
- Autofill and password-manager behavior where relevant
- Mobile keyboard changes for email, phone, and numeric fields
- Consent accepted and rejected
- A slow network response
- A long error or confirmation message
- Screen rotation during entry
Make sure the active field stays visible when the mobile keyboard opens. Check that sticky controls do not cover the submit button or error summary. Preserve entered data after a recoverable error. Confirm that the success state records one conversion and creates the expected CRM record.
Test meeting schedulers, video players, maps, chat tools, and embedded forms at the same widths. Third-party interfaces often bring fixed dimensions, layered controls, or their own breakpoints. Include them in the scope rather than marking the surrounding component complete.
Cover responsive images and performance
Large desktop media can make a mobile page slow even when CSS shrinks it on screen. Define how the website selects, crops, and loads media.
Ask the development team to cover:
- Appropriate source sizes for different display widths
- Image dimensions that let the browser reserve layout space
- Art direction when one crop cannot serve every layout
- Modern formats where platform support allows them
- Lazy loading for off-screen media
- Priority for the primary visible image
- Video poster images and playback behavior
- CMS guidance for focal points and source quality
Check performance on a representative mobile device and network profile. Lab tests help teams catch regressions during development. A production check confirms the live domain, CDN, scripts, consent settings, and third-party tools work together.
Do not accept a single performance score as responsive QA. A page can earn a strong score while its menu fails on touch. Use performance evidence beside interaction and content tests.
Require evidence for each critical template
“Tested on mobile” gives you no acceptance standard. Require a QA record that names the page, viewport or device, browser, test case, expected behavior, observed result, evidence, owner, and status.
Cover every distinct template and all shared high-risk components. A B2B site may include:
- Home and product pages
- Pricing and comparison pages
- Resource listings and articles
- Case studies
- Gated landing pages
- Contact and demo forms
- Search and filtering
- Legal and preference pages
- Error states
Use automated checks for repeatable regressions. Screenshot comparisons can catch layout shifts. Browser tests can exercise menus, forms, and core journeys. Accessibility tools can flag some overflow, naming, contrast, and target problems.
A person still needs to inspect content order, interaction clarity, touch comfort, overlay behavior, and real-device use. Automation should shorten the manual pass, not erase it.
Assign ownership after launch
Responsive behavior changes when your team adds a component, edits navigation, embeds a new tool, or publishes difficult content. Put responsive checks into the release process.
Name owners for:
- Browser and device support policy
- Component acceptance rules
- Content stress testing
- Accessibility review
- Automated regression tests
- Production smoke tests
- Defect triage
- CMS editor guidance
Require a handoff with the support matrix, component documentation, test suite, known exceptions, and evidence from the launch pass. Your internal team should know how to test a new landing page without reopening the entire redesign project.
Use these requirements to compare redesign proposals
Ask each agency to show where its scope covers:
- Responsive component specifications
- Browser and device coverage
- Real-content testing
- Accessibility and zoom checks
- Forms and third-party integrations
- Responsive image behavior
- Automated regression coverage
- Physical-device QA
- Production verification
- Documentation and handoff
A line item for “responsive development” does not explain the work. Ask which templates receive manual QA, which journeys receive automation, who supplies devices, how defects get recorded, and what evidence you receive before approval.
Virdis treats responsive behavior as part of the website system. We connect design rules, component development, content constraints, accessibility, conversion paths, and release QA so your team can maintain the site after launch.
Frequently asked questions
How many devices should a website redesign support?
Define a browser and device matrix from audience data, business risk, and current platform support. Test representative phones, tablets, laptops, and large screens, then add the devices your analytics and support records show matter.
Should responsive testing use breakpoints or specific devices?
Use both. Resize through widths around content-led breakpoints to catch layout failures, then run critical journeys on representative physical devices to catch touch, keyboard, viewport, and browser behavior.
Who owns responsive QA during a redesign?
The agency or development team should define and run technical QA. Marketing and content owners should test real content and conversion paths. One named owner should approve evidence before launch.
Can automated responsive testing replace manual QA?
No. Automation catches repeatable regressions such as overflow, screenshots, and failed interactions. A person still needs to judge reading order, touch behavior, content clarity, form recovery, overlays, and real-device use.
