I have reviewed a lot of responsive design handoffs over more than a decade. The ones that fail consistently have the same root cause: the designer completed the desktop layout, then scaled it down to mobile as an afterthought. The result is a mobile experience that is technically responsive but experientially broken: crammed navigation, touch targets that require surgeon-level precision, and content hierarchy that makes sense on a 1440px canvas but falls apart on a 390px screen.
Mobile first is a philosophy, not a technique. The CSS min-width media query is just the mechanical expression of a decision that should have been made much earlier, at the point where you decided what content matters most, what the user's primary task is on this surface, and how a constrained environment should force clarity rather than compromise.
The Constraint Is the Design
A 390px viewport with a soft keyboard that takes a third of it or more once the predictive bar is up, a thumb as the primary input device, a connection that drops without warning, and a user doing something else at the same time. That is the design problem. Start there and you are forced into real decisions. What is the one thing this screen must do? What information is genuinely necessary? What gets deferred to a secondary screen or a more intentional session?
When you start from desktop, you never have to make those decisions. You have space to accommodate everything, so everything gets included. Then you try to fit it into mobile and nothing fits cleanly. The hamburger menu becomes a dumping ground. Cards collapse into illegible density. The primary CTA gets buried below the fold.
Information Architecture Comes First
Before any visual design, the mobile-first process starts with content prioritization. For every screen, I ask: what is the user's primary goal on mobile? What information supports that goal directly? What can wait?
This exercise produces a content hierarchy specific to the mobile context. Picture a banking dashboard. On desktop the screen carries an account summary, recent transactions, spending insights, promotional offers, quick links, and alerts all at once. On mobile the hierarchy is account balance and the most recent transaction first, everything else reachable but secondary. That is not a layout decision. It is an information architecture decision that changes what gets built, not just how it is arranged.
- Start with a content audit: list every element on the screen and rank it by user value in a mobile context
- Eliminate ruthlessly: if an element is not in the top three priorities for mobile, it either gets deferred or removed
- Define progressive disclosure: what appears immediately, what requires a tap to reveal, what lives on a separate screen
- Consider the task context: mobile users are often on the go. Design for interruption, not sustained sessions
- Design the empty state and the loading state for mobile first. These are the states that most expose flawed assumptions
Touch Targets: 24x24 Is the Floor, 44x44 Is the Rule
Apple's Human Interface Guidelines specify a minimum touch target of 44x44 points. Google's Material Design recommends 48x48dp. WCAG has two criteria here and the difference matters the moment someone asks what you conform to. SC 2.5.8 Target Size (Minimum) is Level AA in WCAG 2.2 and asks for 24x24 CSS pixels. SC 2.5.5 Target Size (Enhanced) is Level AAA and asks for 44x44. So 24x24 is the floor you have to clear to claim AA, and 44x44 is the number the platform guidelines use and the one I design to on mobile. Clear the floor in the audit, hit 44x44 in the design.
This is where desktop-first designs visibly break. A 24x24 icon button on desktop has enough surrounding whitespace to be usable with a mouse. The same 24x24 button on mobile is a frustration machine. Keep the visual size at 24x24 if the design needs it, then extend the tappable area to 44x44 with padding or a pseudo-element. The drawn size and the hit area are two different numbers and only one of them has to satisfy the guideline.
/* Touch-friendly icon button, visible size 24px, tap target 44px */
.icon-btn {
/* Visual size */
width: 24px;
height: 24px;
/* Extend tap target without affecting layout */
position: relative;
cursor: pointer;
display: inline-flex;
align-items: center;
justify-content: center;
/* Invisible extended touch area */
&::after {
content: '';
position: absolute;
inset: -10px; /* Extends 10px in all directions: 24 + 20 = 44px */
}
}
/* Alternatively, use padding */
.touch-btn {
padding: 10px;
min-width: 44px;
min-height: 44px;
display: inline-flex;
align-items: center;
justify-content: center;
box-sizing: border-box;
}Navigation: The Hardest Mobile Problem
Navigation is the most consequential information architecture decision in a mobile-first design. The hamburger menu has become the default solution. And it is a weak one. It hides navigation, reduces discoverability, and adds a tap and a full-screen overlay to every navigation action.
The alternatives depend on how many navigation items exist. For five or fewer primary destinations, a bottom tab bar (following native mobile patterns) is dramatically more usable. Thumb-reachable, always visible, zero additional taps. For deeper hierarchies, consider which items genuinely need to be in the primary navigation versus accessible through contextual actions within each section.
Moving primary destinations out of a hamburger menu and into persistent, thumb-reachable navigation is one of the cheapest wins in a mobile-first redesign. Users feel less lost when navigation is always visible.
- Bottom tab bar: best for 3-5 primary destinations, follows native patterns users already know
- Hamburger menu: acceptable for secondary navigation with more than 7 items, never for primary navigation
- Breadcrumb + back button: essential for deep hierarchies, ensure the back button is thumb-reachable
- Contextual navigation: links and actions relevant to the current content, reduces need for global nav
- Avoid mega-menus entirely on mobile. They are a desktop pattern that has no mobile equivalent
Forms on Mobile: Reduce, Then Reduce Again
Forms are the most failure-prone element in mobile design. The soft keyboard takes a third of the screen or more, so the field you are typing into can end up an inch above the keyboard with the submit button nowhere in sight. Validation errors require scrolling to see. The approach I take for mobile forms is progressive: show only what the current step needs, set the correct input type so the right keyboard opens, and validate inline rather than on submit.
// Angular form with mobile-optimized inputs
@Component({
selector: 'app-contact-form',
imports: [ReactiveFormsModule],
template: `
<form [formGroup]="form" (ngSubmit)="onSubmit()">
<!-- Correct inputmode triggers optimized mobile keyboards -->
<input
formControlName="phone"
type="tel"
inputmode="tel"
autocomplete="tel"
placeholder="Phone number" />
<input
formControlName="amount"
type="text"
inputmode="decimal"
autocomplete="off"
placeholder="Amount" />
<input
formControlName="email"
type="email"
inputmode="email"
autocomplete="email"
placeholder="Email" />
<!-- Large touch target for submit -->
<button
type="submit"
style="min-height: 48px; width: 100%; font-size: 1rem;">
Submit
</button>
</form>
`
})
export class ContactFormComponent {
form = this.fb.group({
phone: ['', Validators.required],
amount: ['', Validators.required],
email: ['', [Validators.required, Validators.email]]
});
constructor(private fb: FormBuilder) {}
onSubmit(): void { /* ... */ }
}Angular Responsive Patterns That Actually Work
On the implementation side, the mobile-first CSS approach means writing base styles for the smallest viewport and adding complexity for larger viewports with min-width media queries. This is the opposite of the traditional desktop-first approach and it produces leaner, more maintainable CSS.
Two newer CSS features do work that media queries and JavaScript used to split between them. Container queries let a component respond to the width of its own container rather than the viewport, which is the correct unit for a card that sits in a sidebar on one route and runs full width on another. Set container-type: inline-size on the wrapper, write @container (min-width: 400px) on the card, and the card stops caring where it was mounted. That removes most of the reason to reach for BreakpointObserver at the component level, and it leaves the media queries for genuine page-level layout.
The dynamic viewport units fix the soft-keyboard problem directly. 100vh on mobile resolves to the large viewport, the one measured with the browser chrome retracted, so a full-height layout gets clipped under the address bar. 100svh is the small viewport and never gets clipped. 100dvh tracks the current viewport as the keyboard and the URL bar come and go. Use dvh for a full-height app shell, svh for anything that must never be cut off, and pad the bottom with env(safe-area-inset-bottom) or your bottom tab bar lands underneath the home indicator.
/* Mobile-first CSS, base styles apply to all sizes */
.card-grid {
display: grid;
gap: var(--ds-spacing-4);
grid-template-columns: 1fr; /* Single column on mobile */
/* Tablet and up */
@media (min-width: 768px) {
grid-template-columns: repeat(2, 1fr);
}
/* Desktop and up */
@media (min-width: 1024px) {
grid-template-columns: repeat(3, 1fr);
}
}
/* Angular CDK BreakpointObserver for component-level responsive logic */
import { BreakpointObserver, Breakpoints } from '@angular/cdk/layout';
import { Component } from '@angular/core';
import { map } from 'rxjs/operators';
@Component({ /* ... */ })
export class ResponsivePanelComponent {
isMobile$ = this.breakpointObserver
.observe([Breakpoints.Handset])
.pipe(map(state => state.matches));
constructor(private breakpointObserver: BreakpointObserver) {}
}Progressive Enhancement vs Graceful Degradation
Progressive enhancement means starting with a baseline experience that works everywhere (small screens, slow connections, older browsers, assistive technologies) and layering on richer behavior for more capable environments. Graceful degradation means building for the best case and trying to catch edge cases as they break.
Mobile first is philosophically progressive enhancement. Start with the constrained environment and prove the design works there. Then enhance for larger screens, faster connections, hover states, and multi-column layouts. The baseline is not a stripped-down version of the real thing. It is the real thing, and the enhanced version is a richer variant.
The discipline that mobile constraints impose is not a limitation. It is a clarity filter. Every element that survives the mobile-first edit is there because it earns its place. Everything else is noise.
The next time you begin a design, open Figma at 390px. Design the entire experience at that width before touching a desktop frame. You will make harder decisions earlier, eliminate more unnecessary elements, and produce a design that is coherent at every size rather than broken at the small end. That is not a CSS trick. It is a design discipline.
References
- Apple Human Interface Guidelines. https://developer.apple.com/design/human-interface-guidelines/buttons
- Material Design 3 guidelines. https://m3.material.io/components/buttons/guidelines
- WCAG 2.2 Understanding SC 2.5.8 Target Size (Minimum), Level AA. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
- WCAG 2.2 Understanding SC 2.5.5 Target Size (Enhanced), Level AAA. https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html
- Angular CDK BreakpointObserver. https://material.angular.dev/cdk/layout/overview
- MDN. CSS container queries. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
- MDN. Viewport units svh, lvh and dvh. https://developer.mozilla.org/en-US/docs/Web/CSS/length#viewport-percentage_lengths