Checking Every Screen at Phone Width

It is easy to build software on a large monitor and forget that many people will use it on a phone. A pastor checks event registrations between meetings. A shop owner answers a support ticket from the counter. A coach updates a page while waiting for a client. For many small organizations, the phone is not a secondary device; it is the main one.

So we check every screen at phone width before calling it finished. Not a sample of screens, and not only the public website. Every screen, including admin pages, dialogs and settings.

What usually breaks

After checking a lot of screens on small displays, we see the same problems again and again:

• Horizontal scrolling. A wide table, a long word or a fixed-width element pushes the page sideways.
• Crowded rows. Several buttons and labels squeezed into one line until they overlap or wrap awkwardly.
• Dialogs that do not fit. A modal taller than the screen, with its buttons hidden below the fold.
• Tiny tap targets. Links and icons too small to tap accurately with a finger.
• Hidden content. Sections that disappear on small screens without a way to reach them.
• Fixed headers that eat space. Sticky elements that leave little room for content.

Each of those is a small problem on its own. Together they make software feel broken.

How we design for small screens

Fixing these problems is easier when they are anticipated. Our admin design standard asks for rows that rearrange on small screens, forms that stack into a single column, dialogs that scroll internally with their action buttons always reachable and sticky save buttons that do not cover content. Section menus become compact dropdowns rather than long sidebars.

On public websites, our page builder's blocks are designed to stack and resize, and imported sites are checked at phone width specifically, because their original mobile layouts often behave differently from their desktop versions.

A real phone width, not a guess

We test at widths that match real phones, around 375 to 390 pixels for common devices, rather than simply shrinking a browser window until it looks fine. Some checks also happen on real devices, because touch behavior, on-screen keyboards and browser toolbars can reveal problems that a desktop browser does not.

No horizontal overflow, ever

One rule is simple to check and catches many issues: a page should never scroll sideways on a phone. During checks we look specifically for horizontal overflow, and we trace it to the element causing it. Often it is a single long link, an image without a maximum width or a decorative element positioned just past the edge.

Forms on small screens need extra care

Forms are where phone layouts most often fail people. Labels that sat beside fields on a desktop need to move above them. Inputs need to be large enough to tap and should trigger the right keyboard, such as a number pad for phone numbers or an email keyboard for addresses. Error messages must appear next to the field they describe, not in a banner the person has already scrolled past. And the save button needs to stay reachable even when the on-screen keyboard takes up half the display.

We check forms with the keyboard open, because that is how people actually fill them in. You can read more about form design in accessible forms.

Tables need a plan

Wide tables are the hardest element to fit on a phone. Rather than shrinking text until it is unreadable, we choose a strategy for each table: show only the most important columns on small screens, turn rows into stacked cards or let the table scroll inside its own container while the page itself stays still. The right choice depends on what people need from the table, which is a design decision, not a default.

Phone screenshots are evidence

When we redesign an admin module or rebuild a website, phone screenshots in light and dark modes are part of the evidence that the work is complete. They are stored with the work's handoff notes, so anyone can see what the screens actually looked like at release, as described in one design standard for every admin screen.

Small screens improve big screens too

Designing for phones forces clarity. When space is limited, you have to decide what matters most on each screen. Those decisions usually make the desktop version better as well: fewer distractions, clearer actions and simpler layouts. Mobile constraints are a gift to good design.

Frequently asked questions

What screen width should I test for mobile?

Common phones display websites at roughly 375 to 430 pixels wide. Testing around 375 to 390 pixels catches most problems.

Why does my website scroll sideways on a phone?

Usually one element is wider than the screen, such as a long link, a wide table or an image without a maximum width. Find that element and constrain it.

Do admin areas need to work on phones?

Yes. Many people manage their organizations from phones, so admin screens, dialogs and forms should work at phone width too.