Why does our site feel cramped and awkward on mobile when desktop looks fine?

When a site looks fine at 1440px and cramped at 390px, the layout is usually working exactly as it was built. Nothing is broken. The spacing, type sizes and tap targets were chosen on a desktop screen and then scaled down by the same ratio everywhere, so a 96px section gap becomes 40px, a 60px heading becomes 26px, and everything ends up slightly too small and slightly too tight at once.

That is why the feeling is hard to name. No single element is wrong enough to point at. The whole page is compressed by ten or fifteen percent, and your eye reads that as cheap and awkward.

Mobile does not need the desktop layout shrunk. It needs its own decisions: fewer columns, bigger touch areas, tighter horizontal padding but generous vertical rhythm, and a plan for the components that never had one. The five checks below find which of those decisions is missing on your site. Run them on your own phone, in order, because they go from the cheapest fix to the most expensive.

Open a long page on your phone and look at the gap between two sections. Then open the same page on your laptop and look at the same gap. If the mobile gap looks like a smaller version of the desktop one, the spacing was scaled, not re-stepped.

Scaling is the wrong operation. Vertical space on mobile is doing a different job than on desktop. On a wide screen, whitespace to the left and right of a column already separates content, so vertical gaps can be modest. On a phone everything is one column, so the vertical gap is the only thing telling the reader that one idea has ended and another has begun. Shrink it and the page reads as one undifferentiated scroll.

What we change instead: we keep a fixed spacing scale, usually 4, 8, 12, 16, 24, 32, 48, 64, 96 pixels, and on mobile we step down one or two rungs rather than multiplying by 0.6. A 96px desktop section gap becomes 64px, not 40px. Horizontal page padding goes the other way and gets tight, 16 to 20px, because horizontal space on a 390px screen is expensive and vertical space is free. Cramped sites usually have this backwards: 24px of side padding they cannot afford and 32px section gaps that are too small to separate anything.

• Side padding on mobile: 16 to 20px, never more than 24px.
• Gap between sections: at least 48px, usually 64px.
• Gap between a heading and its paragraph: one rung, 8 or 12px, so they read as a pair.

Scroll a page with your thumb and try tapping the navigation links, the footer links and any icon buttons. If you miss, or if you have to look before you tap, the targets are too small. This is the single most common cause of a site feeling awkward rather than looking bad, and readers rarely diagnose it because it is a feeling in the hand, not a problem on the screen.

The number we hold to is 44 by 44 pixels of tappable area, matching Apple’s Human Interface Guidelines minimum, with at least 8px between adjacent targets. The target is not the icon or the text. A 16px close icon can sit inside a 44px hit area, and usually should.

The classic failure is a footer with links stacked at 14px type and 8px line spacing. Every link is technically visible and every tap is a coin flip. We fix that by giving each link 44px of vertical space, which makes the footer taller and feel deliberate rather than crowded. In our audits, tap target width is also why mobile navigation menus feel cheap: three-line hamburger icons drawn at 20px with no padding around them.

Load your homepage on your phone and take a screenshot. Now measure how much of it is your actual content, and how much is a sticky header, a cookie banner, a newsletter bar and a chat bubble. On a 390 by 844 screen, the browser chrome already takes roughly 140px. A 64px sticky header and a 120px cookie bar take another 184px. That leaves about 520px of usable height, and roughly a third of the viewport has gone to things nobody came for.

This is why the first screen feels claustrophobic even when the page below it is fine. The reader’s first impression is a headline squeezed into a letterbox.

What we change instead: sticky headers shrink to 48 to 56px on mobile and drop everything except the logo and one menu control. Cookie consent goes to the bottom as a compact bar, not a full-width panel with three paragraphs of explanation. Chat widgets, if they stay, do not launch open. If two pieces of fixed furniture want the same edge of the screen, one of them loses. The rule we use is that fixed elements together may not exceed 15% of viewport height.

Find any form on your site, an email capture or a contact form, and tap into the input on an iPhone. If the page jumps and zooms, your input font size is below 16px. Safari on iOS zooms automatically to make sub-16px text legible, and it does not zoom back out. The reader is now looking at a horizontally scrolling version of your page and has to pinch to escape.

That single behaviour makes a site feel broken more than any spacing problem, and it comes from one CSS declaration. Designers set inputs at 14px because it looks neater in the mockup. On a phone it costs you form completions.

What we change instead: 16px minimum on every input, select and textarea. Body copy at 16 to 18px on mobile, never the 14px that reads fine at arm’s length on a laptop. Small print and captions may go to 14px, but nothing goes to 12px. Line height on mobile body text goes up, not down, usually 1.6, because narrow measures need more air between lines to stay readable.

Scroll every page on your phone and look for anything that scrolls sideways, gets cut off, or turns into a wall of tiny text. Pricing tables, comparison tables, three-across card grids, data dashboards and image galleries are the usual suspects. These are not spacing problems. These components were designed once, at desktop width, and mobile got whatever the CSS did on its own.

A four-column pricing table is the clearest case. At 1200px it is a comparison, because you can see all four columns at once and that is the entire point of the component. At 390px it becomes either a horizontally scrolling strip or four columns of 9px text, and in both cases the reader can no longer compare anything. The component has stopped doing its job, and no amount of padding will fix it.

What we change instead: the table becomes stacked cards, one plan per card, with the most popular plan first and the feature list repeated inside each one. It is more scrolling and more duplicated text, and it works, because comparing two adjacent cards by scrolling is possible where reading 9px type is not. The same move applies to card grids: three across becomes one across, and if that makes the page too long, the answer is fewer cards, not smaller ones.

Three of the five are cheap. If your site is built on a component-based front end with any kind of shared styling, checks two, three and four are a day or two of work for whoever maintains the site, and you do not need a studio for them.

The other two are harder, and worth being honest about. Re-stepping spacing means touching every section on every template, and if your spacing values are hardcoded rather than coming from a shared scale, that is a slow, error-prone edit. Giving tables and card grids a real mobile layout means designing new components, not adjusting old ones.

Our rule of thumb: if only checks two, three and four fail, hire nobody and give the list to your developer. If check one fails across every template, or three or more components have no mobile layout, you are rebuilding the layout system anyway, and doing it inside a redesign is cheaper than doing it twice. The reason we build every redesign on a design system is exactly this: when spacing comes from one scale and buttons come from one component, mobile stops being a separate set of decisions someone forgot to make.

1. Fix input font size to 16px. Minutes of work, immediate effect.
2. Trim fixed furniture to under 15% of viewport height. Hours.
3. Raise every tap target to 44px. A day, mostly in the header and footer.
4. Re-step the spacing scale. Days, and only sane if spacing is already tokenised.
5. Redesign the components that have no mobile layout. This is redesign work.