Web vs Mobile
Screen space, nav placement, depth tolerance, input, and context—five hard differences. Structure can't be copied across.
The information architecture can be the same, but the presentation can't be copied across. Desktop's space advantage and mobile's gesture advantage each drive different approaches.
What you'll run into:
- The desktop version gets compressed straight into a mobile version, and everything scrolls sideways
- Tables on mobile need to be dragged left and right, and you still have to zoom in to tap
- You ask AI to make it responsive and it just stacks the layout into one column—the nav is left untouched
Five hard differences
| Dimension | Desktop | Mobile |
|---|---|---|
| Information per screen | Two or three columns; list and detail share the screen | One column; the same content splits into two or three pages |
| Navigation placement | Left or top rail, always visible | Four or five bottom tabs, or a hamburger menu |
| Depth tolerance | Three to four levels, supported by breadcrumbs | Two to three levels; deeper and users don't return |
| Input | Precise mouse, hover for hints | Fingers with real width, no hover—long press and swipe |
| Usage context | Seated, focused, long sessions | Walking or queuing, interrupted constantly, seconds per session |
The last row matters most and gets ignored most easily. Any flow on mobile must assume the user will be interrupted, so it has to save progress and let them continue later—a judgment that changes your data design directly, because you need somewhere to store the draft.
"Usage context" runs deeper than it looks. A desktop user sits in front of a machine and can finish a flow in one sitting; a mobile user may be standing at a subway exit when a message interrupts them mid-flow. The same form that can demand completion in one pass on desktop must support drafts and resuming on mobile. The same information architecture asks different questions on each end: desktop asks "how do I fit more on screen," mobile asks "how do I make interruption cost as little as possible."
Where did the nav go
The desktop left rail can hold a dozen or more entries; the mobile bottom bar holds at most five. The extras need somewhere to go.
- The first four top-level items. They go into the bottom tab bar. Pick the four most frequent, and save the fifth slot for "Me."
- The remaining top-level items. Fold them into the "Me" page as a list.
- Second-level navigation. Becomes a segmented control at the top once you enter a section, or a dropdown filter.
- Breadcrumbs. Become a back arrow in the top-left, with the title saying where you are.
- Batch operations. Enter multi-select by long press, or simply skip them and leave them to desktop.
The four slots of a mobile bottom bar are the most expensive real estate in the product. What you put there is a public statement of what you believe users do most often.
How to put it into practice
- Decide which end is primary first. Aiming for "equally good" on both usually means equally awkward. Pick a primary end, and make the other a good-enough version.
- Turn tables into cards on mobile. A horizontally scrolling table is basically unusable on a phone. Each row becomes a card showing only the two or three key fields.
- Size tap targets by fingers, not by pixels. A visually small icon still needs a hit area around 44px. apple-hig
- Never rely on hover to convey essential information. Mobile has no hover. If a button only makes sense on hover, it's dead on a phone.
Structure itself is device-agnostic; execution isn't. Before you start, answer one question: is this end the primary one or the good-enough one? Once that's settled, these differences give you a basis for every trade-off.