Before you start
Bring the facts, not more tabs.
- The desktop version has real content. Responsive decisions made against placeholder copy will need to be repeated.
- The primary customer journey is known, including its final success or confirmation state.
You will learn to
- Understand how Desktop, Tablet, and Mobile values cascade.
- Create only the overrides that smaller screens need.
- Test both Storefront and Backoffice at phone width.
- Finish with interaction checks, not a screenshot-only review.
Start from Desktop, then inspect Tablet and Mobile
Naratake uses a cascade: Desktop is the base, Tablet adds overrides, and Mobile inherits both before adding its own overrides.
- Use Desktop to establish the base layout, typography, spacing, and visual order.
- Switch to Tablet and change only properties that no longer fit comfortably.
- Switch to Mobile and add the smallest final set of phone-specific overrides.
- Use the keyboard shortcuts shown in help when useful: ⌘1 for Desktop, ⌘2 for Tablet, and ⌘3 for Mobile.
Done when: The same content works at all three breakpoints, and smaller screens contain only deliberate overrides.
Fix structure before shrinking text
Phone layouts usually fail because rows, fixed widths, or content order no longer fit. Making every font smaller hides the symptom and harms readability.
- Select the section container and inspect Style → Layout before editing child elements.
- Change a crowded row to a column, reduce column count, or allow wrapping at the smaller breakpoint.
- Remove fixed widths that exceed the canvas and check margin plus padding together.
- Keep the primary action early in the mobile reading order.
Done when: The page has no horizontal scrolling, overlapping blocks, clipped controls, or important action pushed below avoidable decoration.
Tune type, spacing, and media at phone width
After structure fits, adjust the details that determine reading comfort and visual hierarchy.
- Keep body text comfortably readable and shorten copy before forcing it into an unusually small size.
- Reduce oversized headings until line breaks feel intentional. Recheck translated content if the site is bilingual.
- Use consistent vertical spacing between sections and preserve enough space around tap targets.
- Inspect image crops and focal content. A desktop-wide crop can remove the subject on a narrow frame.
Done when: Headings break cleanly, body copy is readable without zooming, and every important image still communicates its subject.
Open Preview and test the full Storefront
The editor canvas is for construction. Preview is where you verify the customer experience and responsive controls together.
- Choose Preview, switch to Storefront, and select Mobile.
- Open and close the navigation, change pages, follow every main call to action, and submit forms with test information.
- If ordering is enabled, add an item, change quantity or options, and reach the expected checkout or mock-payment state.
- If reservations or appointments are enabled, test available, unavailable, validation, and confirmation states.
Done when: The customer journey works from entry through a visible completion state using only the phone-sized preview.
Test Backoffice at Mobile when the site has operations
A business owner may open orders, reservations, or appointments on a phone during the workday. The preview supports the same device frame for Backoffice.
- In Preview, switch from Storefront to Backoffice.
- Keep Mobile selected and open the operational pages enabled for the project.
- Check navigation, tables or boards, overlays, forms, and the new-order alert at the constrained width.
- Return to Desktop and verify that mobile fixes did not introduce new base styles.
Done when: The owner can reach and act on the project’s enabled operational areas without controls escaping the phone frame.
Perform the final real-device check
Preview is deterministic and fast, but a real browser adds dynamic address bars, touch input, font rendering, and device-specific safe areas.
- Use a review or preview URL on at least one real phone before a public launch when that URL is available.
- Test touch targets, the on-screen keyboard, sticky controls, forms, and any payment handoff.
- Record the page, device, browser, and exact problem for every fix instead of describing it only as “mobile broken.”
Done when: A real-device pass confirms the primary journey, and Launch guide can honestly be marked Preview it on a phone size.
Final check
Do not call it done until these are true.
- No horizontal scrolling, clipped content, or accidental overlap.
- Desktop is the base; Tablet and Mobile contain scoped overrides only.
- Navigation and primary tap targets are reachable and readable.
- Storefront and enabled Backoffice areas were tested in Mobile Preview.
- A real phone was used for the final customer journey when a shareable URL was available.