Mobile-first is one of the most widely claimed and least practised principles in web design. In most projects the desktop composition is drawn first, approved, and then reflowed for a phone, which produces a mobile experience that is a compressed remainder rather than a considered design.
For an Indian audience that ordering is backwards in a way that costs real money, because the overwhelming majority of visitors arrive on a phone and a meaningful share never see the desktop version at all.
Doing it properly means drawing the phone composition first, deciding what survives, and then expanding.
Where mobile-first is the wrong instinct
There are cases where designing phone-first produces a worse result, and it is worth naming them so the principle does not get applied blindly.
Data-dense interfaces are the clearest. A dashboard, a comparison table or an administrative tool used primarily at a desk should be designed for the screen it will be used on. Forcing that through a phone composition first produces an interface that serves neither well.
B2B tools with a known user base are similar. If your users are procurement staff working at a desktop all day, and you can verify that from analytics, designing for the phone first optimises for a minority.
The test is evidence rather than principle. Look at your actual device split by page type, because it varies more than people expect: a marketing page may be ninety per cent mobile while the logged-in application is ninety per cent desktop, on the same domain.
The honest version of mobile-first is designing for the device your users actually have, first. For Indian business websites that is overwhelmingly a phone. For a few specific interfaces it is not, and pretending otherwise serves nobody.
The device you should be designing for
The single most useful correction most teams can make is to be specific about the device rather than designing for an abstraction.
The typical visitor to an Indian business website is on an Android handset costing between nine and eighteen thousand rupees, two to four years old, on a congested mobile network, with several apps resident in memory and possibly a battery saver throttling the processor.
That device has a fraction of the JavaScript execution capacity of the machine the site was built on, and the difference is not marginal. A page that feels instant on a development laptop can take five or six seconds to become usable on it.
The practical discipline is to keep one such device in the office and test on it, on mobile data rather than wifi, before anything is signed off. Emulators model network latency and do not model thermal throttling or a four-year-old processor.
This single habit changes more design decisions than any amount of guideline reading, because it makes the cost of a decision visible at the moment it is made.
In practice
Layout decisions that change
Designing the phone first forces a set of decisions that reflowing a desktop layout allows you to avoid, and those decisions are the substance of the discipline.
You have to decide what genuinely matters, because there is room for one thing at a time. A desktop hero can carry a headline, a subheading, two buttons, a trust badge row and an image; a phone screen cannot, and choosing which of those survives is a strategy question rather than a layout one.
Navigation has to be reconsidered rather than collapsed. A mega-menu with sixty links becomes unusable as an accordion, and the honest answer is usually a much shorter primary navigation with everything else reachable from within the relevant section.
Tables need a plan. Specification tables, price comparisons and product matrices are genuinely difficult on a narrow screen, and the options are horizontal scroll within a contained area, a card-per-row transformation, or progressive disclosure. Choosing one deliberately is better than letting the layout break.
And forms shorten. Every field is more expensive on a phone than on a desktop, because typing is harder and the keyboard covers half the screen. A form that is merely tedious on desktop is abandoned on mobile.
Interaction on a real phone
Several interaction realities are invisible in a desktop mockup and decide whether a mobile experience works.
Thumb reach. Primary actions belong in the lower two-thirds of the screen where a thumb comfortably reaches, not in a top corner that requires a grip change. This is why a persistent call and WhatsApp affordance at the bottom outperforms one in the header.
Tap target size. Fingers are imprecise and people are frequently moving. Small adjacent links produce mis-taps, and a mis-tap that opens the wrong page is a substantial share of abandonment.
Hover does not exist. Anything revealed by hovering is invisible on a phone, and designs that hide meaning behind hover states lose it entirely for most of the audience.
And the keyboard. When it opens it covers roughly half the screen, so a form field near the bottom with the submit button beneath it becomes unreachable. Use the correct input types so the right keyboard appears, which is a small detail that measurably improves completion.
None of this is exotic. All of it is invisible until someone uses the actual thing on an actual phone.
The test that settles arguments
Hand the phone to someone who has not seen the design, on mobile data, and ask them to complete the main task without guidance. Watch silently. Twenty minutes of this produces more actionable findings than any amount of internal discussion, and it ends most debates about whether something is clear.
Key takeaways
- Mobile-first means drawing the phone composition first, not narrowing a desktop one.
- Design for a two-to-four-year-old mid-range Android on mobile data, and keep one in the office.
- The phone forces you to decide what genuinely matters, which is a strategy question.
- Navigation needs reconsidering rather than collapsing; a sixty-link accordion is unusable.
- Primary actions belong within thumb reach in the lower two-thirds of the screen.
- Hover does not exist on a phone. Anything hidden behind it is lost to most of your audience.
Frequently asked
Drawing the phone composition first and expanding outward, rather than designing for desktop and reflowing. The distinction matters because designing phone-first forces decisions about what genuinely matters, since there is room for one thing at a time. Reflowing a desktop layout allows those decisions to be avoided, which is why the result is usually a compressed remainder.
A real Android handset costing roughly nine to eighteen thousand rupees, two to four years old, on mobile data rather than wifi. That is what most Indian visitors actually use, and it has a fraction of the processing capacity of a development machine. Emulators model network latency but not thermal throttling or an ageing processor.
Choose one approach deliberately rather than letting the layout break: horizontal scroll within a contained area that does not scroll the whole page, transformation to one card per row, or progressive disclosure where the key columns show and the rest expand. Specification tables and price comparisons are genuinely hard on a narrow screen and need a decision.
Usually friction that is invisible in a desktop mockup: primary actions outside thumb reach, tap targets too small and too close, meaning hidden behind hover states that do not exist, forms whose submit button is covered by the keyboard, and load times that on a real mid-range phone are three to four times what the team experiences.