More than half the visitors on most sites we build arrive on a phone. The industry's default answer is to design a desktop page, let the CSS squeeze it thinner, and call whatever survives responsive. We think that is backwards.
A phone layout is its own design. Same content, same brand, different decisions. On our builds, the desktop page and the mobile page are two deliberate compositions that happen to share a codebase, and the mobile one gets designed, not derived.
The single-column hero
On a phone, a hero is a stack, not a split. Below about 700px, our heroes become one column: eyebrow, then a big headline, then the subline, then full-width stacked buttons. One detail matters more than it looks: the desktop headline usually carries a character-width cap so its lines break nicely. Leave that cap on at phone sizes and the type crams into a narrow ribbon. Removing it is one line of CSS, and it changes the whole feel of the page.
Buttons go full width on purpose. A small centered pill floating in whitespace is easy to admire and easy to miss. A full-width button at the bottom of the hero sits exactly where a thumb already rests.
Stat bands follow the same logic. Four numbers in a desktop row become a tight two-by-two grid on the phone, big enough to read without squinting and balanced enough that the section still feels composed rather than collapsed.
Thumb-size targets and the details that bite
A mouse cursor is a few pixels. A thumb is not. So every tap target on our builds is at least 44px tall, and the primary action in a form flow gets 52px. Text inputs are at least 16px, because below that iOS zooms the whole viewport when the keyboard opens and the layout lurches.
- Tap targets: 44px minimum, 52px for the primary action.
- Inputs: 16px type minimum so iOS never auto-zooms the page.
- Gutters: at least 20px, extended by the device's safe-area insets so content clears the notch.
- Hero height: 100dvh instead of 100vh, so the browser chrome cannot eat the layout.
- Every content image sized and served for the phone, never shipped at desktop resolution.
The gutter rule has bitten us enough times to earn a permanent guard. A section that sets its padding with a two-value shorthand silently wipes out the container's side padding, and suddenly text is touching the edge of the glass. It looks fine in a desktop preview. It looks broken in a hand.
Forms become full-screen wizards
A wall of form fields on a six-inch screen is where leads go to die. On phones, our contact wizard goes true full screen: one question per step, big touch-friendly options that advance on tap, and a sticky bottom bar with a 52px next button padded away from the home indicator.
The result is a form that feels like an app instead of paperwork. Progress is visible, the back button preserves every answer, and nobody pinch-zooms into a dropdown. Completion is the entire point of a contact form, so the mobile version gets the most care, not the least.
Phones have no hover
Half the polish on a desktop site lives in hover states: cards lift, borders tint, affordances appear. None of that exists on glass. Worse, iOS makes hover sticky, so a tapped card can freeze in its hover look and stay frozen until the next tap lands somewhere else.
So every hover rule we write gets a touch twin that restores the resting state. And rather than simply deleting the polish, we replace it. On Kwaan Bear Technology's site, cards light up as they pass through the middle of the viewport while you scroll, so touch users get the same highlight moment a mouse would have given them.
The performance stakes are higher
Mobile is also where performance failure hides. On one of our contractor builds, the mobile hero took 13.7 seconds to paint before we rebuilt the image pipeline. After the fix it painted in 2.8 seconds, and the page payload dropped from 4.75MB to 1.3MB. Nothing on the desktop report hinted at any of it. You only find that by measuring the phone.
Verified at a real viewport
The last step is not optional. Before any page is called done, we render it at a real phone viewport, 390 by 844, and read the screenshot. Not the code. Not the diff. The page. A green build tells you the page compiles; it says nothing about a headline crammed into a ribbon or a card stuck mid-hover.
The squeezed-desktop era produced a decade of sites that technically work on phones. Technically working is not the bar. The phone is where most of your visitors meet you, and it deserves a layout designed for the hand it sits in.
