We don’t need a separate mockup for every screen size. But we do need to talk about how your design (and especially your content) translates across them.

Modern frameworks have made responsive design second nature; we’ve got the media queries, flexible containers, and layout systems to make things technically work across screen sizes. But what often gets missed isn’t the layout. It’s the content itself.

That sweeping panoramic hero video that looks stunning on a 4K desktop screen? On a mobile phone held vertically, it’s either cropped to oblivion or hidden altogether. That elegant hover animation with layered parallax? It’s great… unless you’re using your thumbs. And the intricately styled mouse-based carousel? It falls flat when there's no mouse in sight.

This isn’t a “designers should know better” kind of rant. It’s more of a heads-up from the dev and QA teams who are flagging these mismatches late in the game, after the client’s seen the full desktop experience and is now previewing mobile a few days before launch.

At that point, there’s a mad dash to recut images, hide features, or find alternate video clips that actually work on small screens. Everyone’s stress level spikes, timelines get tight, and we all wonder how we got here.

We’re not here to wave the “mobile-first” flag just because it was trendy in 2016. But we do believe in thinking about mobile first-ish. Not because it’s a requirement, but because so much content consumption actually happens there. Designing for mobile forces prioritization. It clarifies what’s essential and what’s decorative.

It’s also a helpful lens for evaluating interaction. Are you designing for touch or mouse? Are you considering tap targets, scroll behavior, and what happens when there’s no hover state? Because your dev team is.

We can scale things. But we can’t magically make content designed for a widescreen banner sing on a phone. That’s not a layout issue, it’s a creative one.

Designing with flexibility means:

It also means bringing your dev team in early. Not to nitpick, but to flag potential issues before you’re racing to fix them the night before launch.

This is the part where our PMs quietly weep with gratitude: when designers proactively ask, “Will this work on mobile?” or “Do we need a fallback for this on touch?”, it keeps timelines on track and launch days much calmer.

You don’t need to design for 18 breakpoints. But you do need to think about what happens between them.

If you’re not sure how something will scale, or if a feature’s going to break when it meets real content, we’re happy to talk it through early. The more we plan for flexibility, the better the end result (and the smoother the handoff).