Adapt a desktop design for mobile

Shrinking a desktop layout to a phone produces either a tiny, unusable version of everything or a long scroll where the one thing mobile users came for is buried below a hero image. Mobile users often have different tasks, one hand, intermittent attention and a slower network. A good adaptation starts from what mobile users need to do, ranks every element against that, chooses a layout transformation per region, and makes explicit what moves, collapses or is deferred.

Adapt this desktop screen for mobile.

Only if [MOBILE_CONSTRAINTS] is given:

If the screen description is too thin to rank (no regions or no purpose), ask up to three questions and stop.

1. Mobile tasks. List the tasks people do on this screen and rank them for mobile context. Use the analytics given; otherwise reason from the screen's purpose and mark the ranking as an assumption to check with mobile analytics.
2. Content priority. Rank every region and element: must be visible on load, available within one tap or scroll, available on demand (behind a disclosure, tab or sheet), or dropped on mobile. Give the reason for each.
3. Layout. For each region choose a transformation and describe it: stack columns in priority order, reflow into a single column, collapse into accordions or tabs, convert tables into cards or a list with key columns and a detail view, move side panels to a bottom sheet or separate screen, turn hover-revealed controls into visible controls or an overflow menu, and replace wide charts with a simplified chart or a key figure. Describe the resulting screen from top to bottom at the smallest width, including what is visible without scrolling.
4. Navigation. Choose the pattern (bottom tab bar for 3 to 5 top destinations, top app bar with back, a menu for secondary destinations, segmented control for views of the same content) and keep it consistent with the rest of the product. Place the primary action where the thumb reaches it (bottom area or a sticky action bar) without covering content.
5. Interaction and touch. Touch targets of at least 44 by 44 points (iOS) or 48 by 48 dp (Android) with spacing between them; replace hover, right-click and drag-only interactions; input types and keyboards for fields; gestures only with a visible alternative; behaviour when the keyboard is open; safe areas and notches; text size at the platform's default and with larger accessibility text.
6. Dropped or deferred. List what is not on mobile and where users can still reach it (desktop, a "more" area, a later release), with the risk of each removal.
7. Risks to test. Three to five assumptions to check with mobile users or analytics, and what result would change the design.

• Do not invent elements that are not on the desktop screen; a new mobile-only element is marked "(new)" with the reason.
• Keep feature parity where users need it; do not remove something only because it is hard to fit. Say when a function should stay but move.
• Follow platform conventions for native apps; for mobile web, do not imitate native patterns that conflict with the browser's own controls.
• Separate what you verified from what you inferred. Mark inferences as such.
• When you do not know, say "I don't know" once and state what would settle it.

Mobile tasks

Content priority

| Element | Desktop location | Mobile priority | Mobile treatment | Reason |

Layout

A top-to-bottom description of the mobile screen, then per-region transformations.

Navigation

Interaction and touch

Dropped or deferred

Risks to test