The One Percent That Changes Everything

Why responsive completeness demands data over drama


Here’s a number that almost got ignored: one percent.

We were doing an analytics deep-dive on a corporate web platform — the kind of Fortune 50 site that serves millions of visitors across every imaginable device. And buried in the viewport data was a cluster of users at a resolution that didn’t fit neatly into our breakpoint model. About one percent of overall traffic. The easy call was to move on. One percent? Rounding error.

But then we segmented by audience. Among internal users — the employees who use this platform as a daily tool — that number jumped to three percent. Three percent of the people who depend on this site every single day were seeing a layout that didn’t quite work. Content designed for a wider viewport was getting squeezed into a space that triggered the tablet layout, but the tablet layout wasn’t designed to handle that particular width gracefully.

One of our core values at Johns & Taylor is Data Over Drama. And this situation is exactly why that value exists. The dramatic response would have been to either panic (“three percent of internal users are having a bad experience!”) or dismiss (“it’s only one percent of total traffic”). The data-driven response was to understand why it was happening and decide what to do about it.

What we found was a generation gap in the hardware. Lots of enterprise laptops ship with 13-inch screens that resolve to viewport widths in a narrow band — around 1280 to 1340 pixels — that sits right at the boundary between our desktop and tablet breakpoints. These aren’t edge cases. They’re standard-issue corporate hardware. And our breakpoint model was treating their users like an afterthought.

The fix required a principle we now apply to every feature we build: three fields, three breakpoints, every time. If a feature involves images — hero banners, video poster frames, promotional cards, anything visual — it needs three separate asset fields: desktop, tablet, and mobile. No exceptions. No “the desktop image will scale down fine.” No “we’ll handle it with CSS.”

I’ll admit this felt heavy-handed at first, even to me. Three image fields for every visual component means more work for content teams, more storage, more complexity in the CMS. But the data told us what our intuition didn’t: users on those in-between viewports were getting images that were either too large (slow loads, wasted bandwidth) or awkwardly cropped (content cut off, focal points missed). The three-field approach meant each breakpoint got exactly the image it needed.

We’ve since baked this into our user story template. Any feature that touches images gets a line item: “Does this feature include three separate asset fields for desktop, tablet, and mobile?” If the answer is no, the story goes back for revision before it enters a sprint. It’s become so routine that our team catches it before I do — which is exactly how a principle should work. It shouldn’t require the senior person in the room to enforce it. It should be obvious enough that everyone enforces it.

The broader lesson here is about what “responsive” actually means. The industry moved past the responsive-vs-adaptive debate years ago, but a lot of teams still think responsiveness means “it doesn’t break on a phone.” True responsive completeness means every viewport gets an intentional experience — not a gracefully degraded one, not a technically-functional one, but one that was actually designed for that context.

Data Over Drama means being willing to look at the numbers even when they’re inconvenient. One percent of traffic didn’t feel important until we understood who that one percent was. Three percent of your most engaged internal audience changes the calculation entirely. The data didn’t tell us to panic. It told us to design intentionally for a viewport we’d been treating as a rounding error.

Every platform has its version of this one-percent problem. The question is whether your team has the discipline to find it, the honesty to acknowledge it, and the process to prevent it from happening on the next feature you build.

Three fields. Three breakpoints. Every time.