The common failure is a resized desktop
Most sites described as responsive were designed at desktop width and then adjusted until nothing overlapped on a phone. The result technically fits, but the priority order is still the desktop's.
You can usually spot it: an enormous hero image pushing the actual content below three screens of scrolling, navigation collapsed into a menu that hides the most important link, and a footer containing information the visitor needed at the top.
Start with the hardest constraint
Designing the narrow layout first forces the priority question immediately: with one column and limited attention, what comes first?
That decision is valuable at every width. Expanding a well-prioritised mobile layout to desktop is straightforward; extracting priority from a crowded desktop layout afterwards is not.
Touch targets and thumb reach
A cursor is precise; a thumb is not. Interactive elements need enough size and spacing to be hit reliably, and the most-used controls belong within comfortable thumb reach rather than at the top of a tall screen.
- Minimum around 44×44px for anything tappable
- Adequate spacing between adjacent targets
- Primary actions reachable without repositioning the hand
- Never rely on hover to reveal something essential, because there is no hover
Typography carries more weight on a small screen
Text that is comfortable on a 27-inch monitor at arm's length is not automatically comfortable on a phone held closer. Body text below about 16px becomes tiring quickly, and long unbroken paragraphs are considerably harder to read in a narrow column.
Keep line length in a readable range, give generous line height, and break content into scannable sections with meaningful headings.
Navigation should not hide the important thing
The hamburger menu is an established convention and works well enough for secondary navigation. It becomes a problem when the primary action (contact, book, buy, enquire) is hidden inside it.
Keep the main action visible. A persistent bottom call-to-action bar is often a better solution on mobile than adding another item to a hidden menu.
Test on an actual device
Browser device emulation is useful and incomplete. It does not reproduce real touch accuracy, real screen brightness in daylight, real network variability, or the way a device gets slower as it warms up.
Load the site on a mid-range Android phone on mobile data. It is consistently the most informative ten minutes of any responsive design process.
Accessibility overlaps with mobile more than people expect
Larger touch targets, sufficient contrast, readable type sizes and layouts that survive text scaling all benefit mobile users and users of assistive technology at the same time.
Designing properly for one tends to improve the other, which makes it an efficient place to put effort.
Written by Ntege Israel Charles, a Web Developer and WordPress Developer based in Kampala, Uganda. If any of this applies to a site you are responsible for, get in touch.