By mid-2012, we had enough data to make the argument internally: mobile traffic was growing faster than desktop on every client property we managed. The average was 18% and accelerating. The question wasn't whether to prioritize mobile - it was how to make "mobile-first" a repeatable process rather than a one-off effort.
This post is about the specific decisions we made, the tools we used, and the client conversations we had to have.
The Problem With Our Existing Process
Our process before mobile-first looked like this:
- Client brief
- Desktop wireframes in Balsamiq
- Desktop designs in Photoshop (1280px canvas)
- Frontend build - desktop
- "Add mobile" - usually a two-day sprint at the end that tried to compress a 1280px layout into 320px
That final step was where everything broke. We were taking a design that assumed a horizontal layout, a sidebar, hover states, and mouse precision - and trying to squeeze it into a vertical, single-column, finger-operated context. It wasn't responsive design; it was compression. The results showed.
The content was wrong. The navigation was wrong. The typography was wrong. We were designing for mobile as an afterthought, and it read as an afterthought.
The Decision: Flip the Order
In August 2012 we made a formal team rule: no project goes into visual design without a mobile wireframe approved first.
The logic was simple. If the mobile layout works - content priority is right, navigation is clear, primary action is accessible - the desktop layout is straightforward. You have more space to work with. But if you start with desktop, you have to make hard cuts for mobile after the client has already approved the desktop design. You're taking things away from a design the client loves. That conversation is always painful.
Starting mobile-first meant the hard prioritization decisions happened before anyone got attached to a particular layout.
The Mobile Wireframe Process
We built a mobile wireframe kit in Balsamiq. Not a visual design - a content-priority wireframe. Blocks with labels. The questions we forced ourselves to answer before drawing any boxes:
1. What is the one thing a user on this page needs to do?
For a product page: add to cart. For a contact page: call us or submit the form. For a blog post: read the article.
That one thing went at the top. Everything else was ordered by secondary importance, tertiary importance, and "nice to have on desktop only."
Product Page - Mobile Priority Stack:
ββββββββββββββββββββ
β Product image β β Full width, swipeable gallery
β (swipeable) β
ββββββββββββββββββββββ€
β Name + Price β β Prominent, readable at a glance
ββββββββββββββββββββββ€
β [ADD TO CART] β β PRIMARY ACTION - cannot be missed
β β
ββββββββββββββββββββββ€
β Short description β β 2-3 sentences max
ββββββββββββββββββββββ€
β βΌ Full details β β Expandable - below the fold is fine
β βΌ Reviews (12) β β Expandable
β βΌ Related items β β Expandable or carousel
ββββββββββββββββββββ
The client approved this priority stack before we touched a pixel of visual design. Arguments about "why isn't the brand story above the add-to-cart button" happened at the wireframe stage, not after a Photoshop comp had been designed.
2. How does the user navigate?
Desktop navigation is typically horizontal - a top nav bar with 5-7 links visible simultaneously. On mobile, that horizontal bar collapses to a hamburger menu, which hides everything behind an extra tap.
Our rule from 2012: the mobile navigation should contain maximum 5 items, and the most important one should never be hidden.
For a product site: Home, Products, About, Contact. Four items. No hamburger needed - we used a bottom tab bar or a persistent icon row.
/* Bottom tab navigation - 2012 mobile pattern */
.mobile-nav {
position: fixed;
bottom: 0;
left: 0;
right: 0;
display: flex;
height: 56px;
background: #fff;
border-top: 1px solid #ddd;
z-index: 100;
}
.mobile-nav a {
flex: 1;
display: flex;
flex-direction: column;
align-items: center;
justify-content: center;
font-size: 10px;
color: #666;
text-decoration: none;
padding: 8px 0;
}
.mobile-nav a.active {
color: #0066cc;
}
.mobile-nav a svg {
width: 24px;
height: 24px;
margin-bottom: 2px;
}
The Client Conversation
The hardest part of mobile-first in 2012 wasn't technical - it was client management. Most clients had never thought about their site on a phone beyond "I checked it and it looks okay."
We developed a standard presentation that we ran in every kickoff meeting. Three parts:
Part 1: Show them their current site on a phone. Not screenshots - hand them an iPhone and ask them to find a product and add it to cart. Watch them zoom, pan, tap the wrong link, zoom again. No explanation needed. They saw the problem.
Part 2: Show them a mobile-first competitor. We always pre-selected one competitor who had done responsive well. The contrast was instant.
Part 3: Explain the process change. "We're going to design your site for this first. Then we'll design the desktop version. The content will be the same - just arranged differently for each context."
The common pushback was "but most of our customers use desktop." We had the data: "Currently yes. But 18% of your sessions are mobile, and that number grows 2-3% per month. By the time we finish building this project, you'll be at 25%. By next year, 35%."
That usually ended the argument.
What We Got Wrong in 2012
We over-used the hamburger menu. "Mobile-first" in 2012 often meant "put everything in a hamburger." We now know hamburger menus hide navigation and reduce engagement. The correct solution was to expose the 2-3 most important navigation items directly and hide the rest. We didn't do this consistently until 2014.
We treated images as decoration. Mobile-first pushed us to text-heavy layouts because images were heavy. We served the same large images to mobile as desktop and relied on max-width: 100% to scale them down - which downloaded the full-resolution image on a 3G connection. The right answer (srcset, <picture>) wasn't available until 2014. The pragmatic answer (serve 400px images to mobile via server-side detection) we didn't implement consistently.
We didn't test on actual devices. Chrome's device emulation mode existed but was imperfect. We tested on our office iPhones but not on the Android budget devices that represented a large portion of the actual user base. A Galaxy Y running Android 2.3 was a very different experience from an iPhone 5. We learned this from user support tickets.
The Outcome
By end of 2012, every new project we delivered was mobile-first. Our average mobile bounce rate dropped from 68% to 41% across client sites. Mobile conversion rate increased from 0.8% to 2.3% - still below desktop's 4.1%, but a 3x improvement.
The process change was more valuable than any individual technique. Starting with mobile wireframes meant mobile usability was baked into the design from the first conversation, not bolted on at the end. The projects that held up best over the next five years were the ones designed this way.
Mobile-first wasn't a trend we adopted in 2012. It was a permanent reorientation of how we thought about what a website is for.
Aunimeda builds modern web frontends - from single-page applications to complex multi-locale sites.
Contact us to discuss your frontend project. See also: Web Development, Corporate Website Development