We still get briefs that treat mobile as an afterthought. "Make it responsive" appears at the bottom of the requirements, after the desktop wireframes are signed off. That's backwards. And in 2015, it's becoming genuinely costly.
What You Need to Know
- Mobile traffic has overtaken desktop globally, and NZ is following the same trend
- Mobile-first doesn't mean mobile-only, it means designing for constraints first and enhancing from there
- Retrofitting a desktop design for mobile is slower, more expensive, and produces worse results than starting mobile-first
The Numbers Are Clear
51%
of web traffic globally now comes from mobile devices
Source: StatCounter Global Stats, Q2 2015
Google has been signalling for over a year that mobile-friendliness affects search rankings. Their April 2015 update made it official. If your site doesn't work well on a phone, you'll rank lower. For enterprise organisations that depend on web traffic for recruitment, stakeholder communication, or service delivery, that's not a theoretical risk. It's a measurable one.
And this isn't just about marketing sites. The enterprise applications we build at IDESIGN are increasingly accessed on tablets in the field, on phones during commutes, on whatever device happens to be closest. The expectation that "enterprise = desktop" is fading fast.
What Mobile-First Actually Means
Mobile-first is a design methodology, not a device preference. It means you start with the smallest screen and the tightest constraints, then add complexity as screen size increases.
Why? Because it's easier to add than to subtract.
When you design desktop-first, you make decisions with plenty of space. Four-column layouts. Side-by-side panels. Dense data tables. Then you try to squeeze all of that onto a 320px-wide screen and everything breaks. Columns stack awkwardly. Tables become unreadable. Navigation that made sense with a mouse becomes impossible with a thumb.
When you start mobile-first, you're forced to make hard decisions early. What's the most important thing on this screen? What can be deferred to a secondary view? How does this interaction work with touch? Those constraints produce clearer, more focused interfaces. And when you scale up to desktop, you're adding space and features to a design that already works. Not cramming a big design into a small box.
How We Approach It at IDESIGN
1. Content Priority First
Before any wireframe, we establish content priority. What does the user need most? What's secondary? What's optional? This hierarchy drives the mobile layout directly and informs the desktop layout too.
2. Breakpoints Follow Content, Not Devices
We don't design for "iPhone" and "iPad" and "desktop." Devices change every year. Instead, we set breakpoints where the content breaks. When a layout stops working at a particular width, that's where the breakpoint goes. This produces designs that work on devices that don't exist yet.
3. Touch Targets Are Non-Negotiable
Buttons and links need to be large enough to tap accurately. We use a minimum of 44px for interactive elements. This sounds obvious, but it's the first thing that gets compromised when a desktop design is squeezed onto mobile.
4. Performance Is Part of the Design
Mobile users are often on slower connections. Every image, every script, every web font is a decision. We set performance budgets early and design within them. A beautiful page that takes eight seconds to load on 3G isn't a good design. It's a slow one.
The constraint of a small screen forces you to decide what actually matters. Every project we've done mobile-first has produced a better experience at every size.
Rainui Teihotua
Chief Creative Officer
Common Mistakes We See
"Responsive" as a checkbox. Adding
<meta name="viewport"> and some media queries to a desktop site doesn't make it mobile-first. It makes it a desktop site that zooms out on phones.Hiding content on mobile. If content isn't important enough for mobile, question whether it's important enough for desktop. Hiding things creates two different experiences and doubles maintenance.
Testing on one device. We test on actual devices. Multiple screen sizes, multiple browsers, multiple operating systems. The iOS simulator and Chrome DevTools are useful, but they don't catch everything.
The Enterprise Angle
Enterprise clients sometimes push back on mobile-first. "Our staff use desktops." That's true today. But field workers are using tablets. Managers check dashboards on phones. External stakeholders access portals from whatever they have. And the applications we build today will be in use for five to ten years.
Designing mobile-first doesn't mean the desktop experience suffers. It means both experiences are intentional. The desktop version gets the full layout, the data density, the power features. The mobile version gets the core workflows, streamlined for touch and smaller screens. Both are designed, not one designed and the other adapted.
Google's mobile-first signal is just the beginning. The direction is clear. Start small. Enhance up. Build something that works everywhere.