Make your project usable on a phone

Test one complete path before adjusting the layout

Write down the task: open the page, understand the offer, enter something, create a result and share or save it. Try that sequence on a phone without a desktop nearby. Notice whether the browser keyboard hides the primary button, a dialog traps the result or an embed captures scrolling in a confusing way.

Check a narrow layout and a larger phone layout, portrait and landscape where relevant. Use real long titles and error messages, not only short sample content. A layout that fits the empty state may overflow after the result appears. Reopen a direct project link and use the browser’s back button to see whether the page remains understandable.

Adapt the layout to the content

Use a proper viewport setting, flexible widths and layouts that can stack. Text should wrap naturally without requiring a sideways scroll. Let images and media respect their container, while preserving the aspect ratio that makes their content understandable. Avoid solving every overflow by hiding it; that can cut off the actual controls.

Prioritize the useful content. Put the main action and its explanation where a visitor can find them, and move secondary notes into a well-labeled disclosure when appropriate. Keep meaningful details accessible, especially assumptions, controls and result limits. A smaller screen is a reason to improve hierarchy, not to remove the information needed to use the tool.

• Responsive design basics ↗

Make input work without hover or precision

Buttons need enough room to tap without hitting a neighboring control. Avoid interactions that appear only on hover. Use visible labels and choose suitable keyboard types for the input. Keep focus visible for keyboard users and return it to a sensible place when a dialog closes. A close icon should have an understandable accessible name.

For a game, check touch controls during an entire round. A desktop keyboard mapping does not make a phone game. For a drawing or drag interaction, provide an alternative when precise dragging is not essential to the idea. Do not prevent all page scrolling merely to make one small interactive region feel stable.

• Tap every primary control with a finger, including close and reset.
• Enter and correct data with the on-screen keyboard visible.
• Use keyboard navigation to reach and leave the main interaction.
• Check that error messages explain what to fix without relying only on color.

Treat the opened experience as part of the page

Open every media type you offer: video, music, game, interactive tool and external webpage. An overlay should fit within the visible screen, show a clear close action and leave access to the original source. Test loading, playback controls and the return path. Some sites refuse embedding, so an original-link fallback is a normal requirement.

Do not assume a large desktop canvas becomes usable when squeezed into a smaller frame. If important controls are clipped or the project depends on a mouse, show a desktop recommendation before launching the embed. Offer “Bookmark for later” or a copyable project link. If bookmarking is browser-local, explain that it is saved on this device rather than promising cross-device account storage.

Check sharing and the cost of loading

Use native sharing where the browser supports it, from an explicit user action on HTTPS. Keep a copy-link or manual-link fallback for other browsers and permissions. Share the specific creator or project URL with matching metadata. If the person cancels the share sheet, keep them on the page and do not announce success.

Review image sizes, autoplay and heavy third-party embeds. A page can look fine on fast Wi-Fi while struggling on a mobile connection. Load a useful page first and defer heavy experiences until the person chooses to open them when that fits the design. Show progress and a recoverable error rather than an empty panel.

Turn the check into a repeatable release habit

Write a short mobile receipt for each important release: device/browser, tested path, observed result and remaining limits. Responsive developer tools are useful for layout checks, but include a real device for touch, media and the keyboard. Retest after changing navigation, dialogs or embeds.

Audit this project’s main task on a narrow phone layout and a real touch device when available. Check horizontal overflow, long content, visible labels, touch controls, keyboard focus, the on-screen keyboard, media overlays, close/back behavior and direct links. For any desktop-only experience, propose an honest explanation plus bookmark/copy-link fallback. Report observed failures and untested conditions separately; do not infer mobile support from a screenshot.