If you’ve ever pushed for a mobile-first approach to product design in your organization, there’s always at least one individual that I’ve dubbed the “mobile-first denier”. I bet you’re nodding to yourself, recalling a conversation that sounds a lot like this, as well as exactly who you had it with.

“Why would someone [perform X] on a mobile device? “Nobody is ever going to [perform X] on their mobile devices.”

Well, if that’s true, it’s most likely because someone hasn’t cared enough to design a good experience for mobile devices. “Never” is a dangerous assumption in a world where monumental shifts happen at any moment. In an industry where so-called “tech experts” unabashedly dismissed the iPhone and even the Internet, is anything really so far fetched anymore? Safe assumptions no longer exist. We have to take every “fad” seriously now.

You obviously don’t know what they say about assumptions.

“Never” is also a dangerous word because someone once said the same thing at some point about video chatting, scanning boarding passes, submitting car insurance accident claims, and countless other tasks we now take for granted as mobile functions. Many of us are so dependent on these capabilities by now that we quickly become frustrated with products and devices that don’t support them.

The better questions to ask are:

• “Is the reason people haven’t historically [performed X] on a mobile device because no one has designed a good enough experience for it, blindly glossing over a problem they didn’t know (or care) they had?”
• “What can we do to design a better experience for [performing X], starting at the mobile level?”

Approach [X] as if it were designed for the users of tomorrow, whether it be web apps, API/SDK documentation, dashboards, and more. Users will always find a way to accomplish a task if they have to, regardless of device. I’ve signed legally-binding documents, written email rules in a webmail client’s preferences, checked domain analytic segments, edited htaccess files on servers, and more, out of necessity and lack of time. Again, these are all tasks that multiple people have said couldn’t or wouldn’t ever be carried out on a non-desktop device.

This is a rare opportunity in product design to blaze new trails of user experience, which also happens to be a competitive advantage. After all, “good design is good business”.

Carousels and accordions only belong at the circus

Having constraints breeds clearer, more focused products. It also quickly prunes excessive UI components at the very beginning. Carousels are a content strategy, information architecture, and product-scope problem. Stock web UI components are also rarely responsive and were born with a desktop-only perspective in mind. A tab bar doesn’t translate well to mobile and if your response is “but, accordions!’”, please go ahead and show yourself out, grabbing a copy of The Humane Interface on your way.

If you have enough content that some of it needs to be hidden behind an interaction, you have too much or poorly-organized content. Also, if we can’t even predict how content will be laid out across countless form factors, how can we possibly attempt to design a UI component that will support and react predictably inside of every possible interaction model? Revealing important content “on hover” is a also particularly zombified interaction for some reason, but thankfully this one is extremely easy to debunk with a quick demo.

Another reason not to rely on these goofy Web 2.0 widget leftovers is performance. Many popular frameworks require several JS and CSS files and to do something that could have been accomplished much more simply, or even removed altogether, with far fewer HTTP requests. An epidemic in front-end development is using libraries at face value, which almost always results in obscene amounts of unused code weight. There is just too much data and research to deny that performance isn’t design, so it’s every bit a UX concern as it is an engineering concern.

Give me one good reason

Really, when the dust settles, the one question I think is the ultimate trump card is “why wouldn’t we design mobile-first?” If the answer is “budget” or “time”, then they clearly don’t understand that mobile-first product design saves money and streamlines development naturally. A follow-up question is: “can you justify how much it’s going to cost down the line to develop and maintain a separate ‘mobile’ version?” It’s our job to use data and research to educate and convert these folks until they’re allies. You won’t win them all over, but the ones you do will be armed with hard data to support their newfound advocacy.

To be overwhelmingly frank, being a mobile-first denier makes you look out of touch, and even worse, ignorant. Be a professional, stay current, stay adaptive. As a result, you’ll stay relevant, stay in the conversation, stay on par or ahead of your competitors, stay employed, and most imperatively of all, you’ll stay connected to your users’ needs.