--- lastModified: 2026-10-10 type: feature title: "Responsive Site Testing for Storefront Teams" description: "Use responsive site testing in Runner AI to review storefront routes on desktop, tablet, and phone. Report layout issues and check changes before publishing." category: ai-websites h1: "Responsive Site Testing Before Your Store Goes Live" keyword: "responsive site testing" legacyKind: structured --- **Responsive site testing** in Runner AI starts with your current storefront and the customer task you need to check. Switch the preview between desktop, tablet, and phone layouts, inspect the same page, and describe a failure with its route and expected result. The output is a reviewable correction to your store project, not a promise that a device preset proves every browser or purchase flow works. ## Start responsive site testing with one customer task A storefront review needs a task, not just a collection of attractive screenshots. Choose a route and an action a customer should complete there. On a product page, that could mean reading the product information, choosing an available variant, and reaching the cart. On a collection page, it could mean finding a product without a filter covering the results. Use your real catalog and approved content so the review includes the text and images customers will encounter. Before starting, write down the result you expect and the parts of the store that must stay unchanged. A useful brief names the page, the affected control, and the viewport where the problem appears. Include a long product title or several options when those expose the issue. Do not replace your catalog with idealized sample content merely to make the layout look correct. This turns a broad request to improve mobile into a bounded correction that another person can inspect. If you are still creating the shopping layout, the [AI ecommerce mobile store builder](/ai-ecommerce-mobile-store-builder) covers that earlier design task. This page covers checking an existing storefront and returning a precise revision request. ## Compare desktop, tablet, and phone previews Runner AI's storefront preview provides desktop, tablet, and phone viewport choices. The desktop view uses the available preview area, while tablet and phone use fixed frames. Switching the frame changes the space around the preview rather than creating a separate storefront project. That lets you inspect how the current page responds to a narrower layout and compare the same content without treating each device choice as a new design. Read from the page heading through the final action in each frame. Look for text that disappears, images cropped across the product, overlapping buttons, horizontal scrolling, and menus that hide their own close control. Use the controls as well as looking at them. A button can fit on screen and still fail to open the next state. Repeat the same task at each viewport so your observations are comparable. The named frames are starting points. They are not a complete browser matrix or a physical-device simulator. Test additional widths and real devices separately when the task depends on touch behavior, the mobile keyboard, browser chrome, or a payment interface. A preview resize does not establish performance, accessibility conformance, or checkout availability. ## Turn a layout failure into a focused store edit Describe what failed with enough context to reproduce it. Include the storefront route, selected viewport, starting state, action, expected result, and observed result. A screenshot can show an overlap, but the explanation should also say which customer action it blocks. For example, report that a product option list hides Add to cart in the phone preview instead of asking for the whole product page to be redesigned. Give Runner AI that bounded brief with the catalog facts, approved copy, and brand constraints needed for the correction. Ask it to preserve unrelated sections and return the affected source changes for review. The [AI website editor](/ai-website-editor) describes the adjacent editing workflow, including selected-element requests where Design Mode is available. Regular chat remains the path for broader changes or projects where those direct controls are unavailable. After the change is saved and the updated preview is ready, repeat the original task. Check the same failure state first, then compare the other two viewport choices. A phone correction can alter desktop spacing or move a tablet control, so the first passing frame is not the end of the review. Keep the before-and-after observations tied to the same task rather than comparing unrelated screenshots. ## Review the result before choosing to publish Treat a passing preview as evidence for the scenario you checked. Confirm that the route loaded the intended page, that the relevant content remained present, and that the action reached the expected state. Review the current version rather than assuming that an older screenshot represents the latest correction. If the page depends on inventory, search, cart data, or another connected service, check those facts at the system that owns them. Publishing remains a separate decision. A responsive layout does not confirm that payment methods, shipping rules, tax settings, or analytics work in the public store. Use the appropriate test environment and authorization for purchase checks, and use a real phone for high-risk mobile interactions. Keep unresolved defects visible instead of treating a visual pass as a complete launch approval. For a wider change to page hierarchy, imagery, and navigation, [modern website design](/modern-website-design) covers the design brief. Responsive site testing gives that work a concrete review loop. Name the task, compare the preview frames, request one correction, and retest before you decide whether to publish. ## Responsive site testing FAQ ### What should I give Runner AI for a responsive layout correction? Provide the current storefront, route, selected viewport, starting state, action, and expected result. Describe the observed failure and include a screenshot when it clarifies the problem. Add verified catalog facts and the sections that must stay unchanged. Responsive site testing works best when the requested correction has an observable pass condition rather than a general request to improve the design. ### Does the phone preview replace testing on a real phone? No. Runner AI's phone frame supports a layout review of the current storefront, but it does not reproduce every physical device or mobile browser. Check priority tasks on real devices when touch, keyboard behavior, orientation, browser chrome, or payment controls matter. Treat the preview as an early review layer, not a device certification or a performance measurement. ### Does checking the preview publish my changes? No. Reviewing a preview and choosing to publish are separate steps. Inspect the saved correction in desktop, tablet, and phone layouts, then verify the relevant customer task and connected systems before publication. A passing layout check confirms only the scenario you observed; it does not prove that every storefront route or purchase condition is ready. [Explore all Runner AI features](/)