Mobile-First Design Handbook Enterprise and responsible web applications

Reference handbook

Design for the smallest credible context.

A practical standard for mobile-first, enterprise-grade, accessible, resilient, and responsible web applications. The emphasis is not visual novelty. It is clear prioritization, trustworthy interaction, and complete product behavior.

Start with the enterprise standard Open launch checklist
15review areas
44–48pxpreferred touch region
WCAG 2.2accessibility baseline
0required dependencies
Prioritize outcomes.Design decisions and workflows before screens.
Expose the important.Discoverability takes precedence over decorative minimalism.
Enhance progressively.Core content and actions should survive JavaScript failure.
Make state explicit.Loading, saving, stale, offline, failed, and complete are different states.

01 · Definition

What mobile-first should mean

Mobile-first is a product architecture discipline. It begins with the most important outcome, the least available space, and the weakest credible operating condition.

Product-first

Design the decision surface

The first viewport should answer four questions:

  • Where am I?
  • What matters now?
  • What can I do next?
  • What happened after I acted?
Content-first

Make meaning survive layout changes

Content should remain understandable when columns stack, sidebars disappear, text wraps, images fail, or the page is zoomed.

Interaction-first

Assume coarse input and interruption

Design for thumbs, variable dexterity, one-handed use, short sessions, interruptions, and no hover.

Delivery-first

Treat constraints as architecture

Account for slow devices, variable networks, battery limits, browser differences, stale data, and partial failure.

The mobile home screen should be a decision surface, not a miniature portal.

02 · Enterprise standard

Fortune 500-grade considerations

Mature enterprise applications balance task completion, governance, accessibility, security, data density, scale, and maintainability.

PriorityPurposeTypical content
ImmediateEnable action nowCurrent status, urgent exceptions, primary action
SupportingEnable a sound decisionContext, summary metrics, critical dependencies
InvestigativeEnable diagnosisHistory, details, logs, related records
AdministrativeEnable configurationMetadata, permissions, infrequent controls
Design rule: Only immediate and supporting information should usually dominate the initial compact viewport.

Adaptive composition

Responsive design changes dimensions. Adaptive design may change the composition.

Compact                    Expanded
──────────────────         ─────────────────────────────
Top app bar                Persistent top bar
Single content pane        Navigation rail + content
Bottom navigation          Side navigation
List view                  List-detail split view
Filter sheet               Persistent filter panel
Overflow actions           Visible contextual toolbar

Governance

Tokens, components, release controls, migration guides, and deprecation policy.

Scale

Performance budgets, observability, localization, role complexity, and extensibility.

Trust

Visible state, auditable actions, transparent data use, and predictable recovery.

03 · Discoverability

Make primary paths obvious

Extreme minimalism often removes the cues users need. Discoverability is the ability to see where to go, what is possible, and what will happen.

Use

  • Visible primary destinations
  • Current-location indicators
  • Text labels for unfamiliar icons
  • Actions next to the object they affect
  • Visible search when retrieval is central
  • Overflow menus for secondary actions

Avoid

  • Hamburger-only primary navigation by default
  • Gesture-only essential actions
  • Unlabeled custom icons
  • Hidden destructive consequences
  • Ambiguous “More” actions without context
  • Primary controls revealed only on hover
Compact navigation recommendation

Use bottom navigation for three to five high-frequency destinations. Put account, settings, and infrequent destinations in a secondary menu.

Action hierarchy recommendation

Prefer one dominant action per decision point. Secondary actions should remain available but visually quieter. Destructive actions require separation and explicit wording.

04 · Accessibility

Accessibility shapes the architecture

WCAG 2.2 Level AA should be the compliance baseline. Production quality usually requires more generous touch targets and broader assistive-technology validation.

Touch target standard: Treat 24 × 24 CSS pixels as a compliance floor. Design most interactive regions toward 44–48 pixels.

Structural requirements

  • Semantic HTML and landmark regions
  • Logical heading order
  • Complete keyboard navigation
  • Visible and unobscured focus
  • Meaningful accessible names and states
  • Reflow and zoom without loss of function

Communication requirements

  • Persistent labels
  • Non-color status cues
  • Accessible errors and validation
  • Reduced-motion support
  • Announcements for dynamic changes
  • Plain-language recovery instructions

Validation matrix

ModeWhat to validate
TouchReach, target size, spacing, accidental activation, sticky controls
KeyboardOrder, focus visibility, traps, skip links, dialogs, menus
Screen readerNames, roles, states, headings, live announcements, errors
Zoom / reflow200%+ zoom, text resize, no page-level horizontal scroll
Voice / switchVisible labels, unique names, predictable activation
Reduced motionNo essential meaning depends on animation

05 · Performance and resilience

Performance is part of visual design

A polished interface that responds slowly feels broken. The delivery sequence should favor comprehension and task readiness over visual completeness.

1Render the shell and title
2Make navigation usable
3Load critical data and actions
4Hydrate secondary enhancements

Budget explicitly

  • Initial JavaScript
  • Critical CSS
  • Fonts and images
  • Third-party scripts
  • API latency
  • Long tasks and interaction delay

Design failure states

  • Offline
  • Stale data
  • Partial API failure
  • Retrying
  • Unauthorized
  • Pending synchronization

Progressive enhancement hierarchy

HTML
└── Meaning, content, navigation, forms, links

CSS
└── Layout, hierarchy, responsive adaptation, visual states

JavaScript
└── Filtering, live validation, optimistic updates,
    richer data exploration, local persistence

Use real URLs, native form semantics, server-rendered results, and browser history. JavaScript should add capability rather than provide the only path to the core task.

06 · Enterprise data

Transform data density instead of shrinking it

Enterprise interfaces often contain tables, filters, dashboards, batch actions, and record detail. Each compact treatment should preserve the user’s actual task.

Find

Structured list

Use when users primarily scan, open, or act on individual records.

  • Strong title
  • Two or three supporting facts
  • Visible status
  • One clear action
Compare

Contained table

Use when cross-record comparison is essential.

  • Frozen identity column
  • Prioritized columns
  • Contained horizontal scroll
  • Column selection
Investigate

List-detail

Use separate screens on compact layouts and a split view on larger layouts.

  • Preserve search
  • Preserve scroll
  • Preserve selection
  • Deep-link records
Monitor

Exception-first dashboard

Lead with current condition, exceptions, trend, and recommended action.

  • Do not create a wall of charts
  • Use accessible summaries
  • Explain thresholds
Do not convert every table into cards. Cards improve individual-record scanning but make cross-record comparison harder.

07 · Forms and recovery

Reduce typing, uncertainty, and rework

Mobile forms should preserve user input, communicate consequences, and make recovery direct.

Form construction

  • Persistent labels
  • Correct input types and keyboards
  • Sensible autocomplete attributes
  • Explicit optional markers
  • Examples beneath fields
  • Save-and-resume for long workflows

Failure recovery

  • Preserve valid input
  • Explain what failed
  • State whether data was saved
  • Link error summary to fields
  • Place errors next to fields
  • Provide one direct recovery action

State model

Idle → Submitting → Success
                 ↘ Failed → Retry
                 ↘ Pending → Success | Failed

Loading, saving, pending approval, stale, and offline are not interchangeable. Each state needs distinct language, timing, and recovery behavior.

08 · Responsible design

Preserve user agency

Responsible design includes accessibility, privacy, security, internationalization, transparent automation, and resistance to manipulative patterns.

Privacy and consent

  • Request data only when needed
  • Explain why permissions are required
  • Separate required and optional data
  • Avoid preselected consent
  • Make accept and reject equally understandable

Security and consequential actions

  • Explain destructive consequences
  • Provide undo where feasible
  • Expose session and device activity
  • Show role and authorization boundaries
  • Maintain an audit history

AI-assisted interfaces

  • Identify AI-generated content
  • Show source data and provenance
  • Distinguish facts from inference
  • Indicate material uncertainty
  • Keep human approval for consequential actions

Internationalization

  • Test long translated strings
  • Support right-to-left layouts
  • Use local date, time, currency, and units
  • Avoid left/right assumptions in component APIs
  • Test mixed-script and localized legal content

09 · Best-in-class patterns

Utilitarian and informational patterns

These patterns repeatedly produce strong task completion and communication when applied with the correct information hierarchy.

Application shell

Short top bar, visible search when central, and three to five primary destinations on compact layouts.

Exception-first overview

Current condition → exceptions → trend → recommended action → supporting detail.

Search and filter

Visible scope, applied-filter summary, result count, deliberate apply action, persistent query state.

List-detail

Separate screens on compact layouts, split panes on larger screens, preserved history throughout.

Progressive disclosure

Use for secondary detail, advanced settings, and troubleshooting. Never hide critical warnings or required inputs.

Summary list

Use label–value pairs for key facts, metadata, and review-before-submit workflows.

Confirmation page

State what completed, reference number, date, next steps, expected timing, and support path.

Inline recovery

Place the recovery action next to the failure. Preserve user work and explain system state.

10 · Production value

High production value is system integrity

The strongest products feel complete because hierarchy, spacing, copy, states, motion, and component behavior reinforce one another.

Hierarchy

Use typography, spacing, position, and contrast to express importance. Too many cards flatten the page.

Rhythm

Use a constrained spacing scale. Tight spacing should imply relationship. Large spacing should signal a new region.

Typography

Prioritize legible x-height, clear numerals, comfortable line height, and tabular figures for metrics.

Component completeness

Include focus, pressed, disabled, loading, error, success, read-only, empty, and long-content states.

Motion

Use motion to explain origin, change, continuity, or ongoing work. Do not delay comprehension.

Content design

Use verbs, state consequences, front-load meaning, and write errors in recovery language.

Diagnostic: Most low-production-value applications are missing states, not gradients.

Practical compact specification

layout:
  outer-gutter: 16px
  content-columns: 1
  page-horizontal-scroll: prohibited

interaction:
  preferred-touch-target: 44-48px
  primary-actions-per-decision: 1
  major-navigation-destinations: 3-5

typography:
  body-baseline: 16px
  body-line-height: 1.45-1.6

delivery:
  semantic-html-baseline: required
  javascript: enhancement-first
  deep-linking: required
  history-state: preserved
  offline-and-stale-state: explicit

accessibility:
  target: WCAG 2.2 AA
  keyboard: complete workflows
  zoom-and-reflow: supported
  focus: visible and unobscured
  reduced-motion: supported

11 · Systems to study

Reference systems and their strongest lessons

No single design system is sufficient. The strongest enterprise approach combines patterns according to product context.

SystemBest lessonsAdapt carefully
GOV.UKTransactional clarity, plain language, errors, confirmation, progressive enhancementIts restrained identity is not a consumer-brand template
USWDSAccessible public-service components and resilient implementation guidanceFederal visual conventions require contextual adaptation
IBM CarbonEnterprise data, tables, structured lists, dense workflows, AI disclosureDesktop density must be transformed for compact layouts
Microsoft FluentAdaptive layout, cross-platform behavior, command overflowRich command surfaces can overload novice users
GitHub PrimerProductivity, compact interaction, responsive layout, touch guidanceAssumes frequent and technically fluent users
Material Design 3Compact navigation, sheets, canonical adaptive layouts, touch ergonomicsUnmodified use can appear generic
Salesforce LightningRecord workflows, CRM structures, enterprise action patternsSome dense components need additional mobile optimization
AtlassianTokens, spacing, governance, cross-product cohesionMany patterns assume established product familiarity
Composite approach: Use GOV.UK for transactional clarity, USWDS for accessible resilience, Carbon for enterprise data, Fluent and Material for adaptation, Primer for productive interaction, and Atlassian for system governance.

12 · Review rubric

Enterprise design review

Score each category from 0 to 5. Weight the score according to the percentages below.

Task completion20%
Can users complete the primary outcome quickly and correctly?
Discoverability15%
Are destinations, actions, state, and next steps apparent?
Accessibility15%
Can users operate every workflow across input and assistive modes?
Performance and resilience15%
Does the application remain useful under latency and partial failure?
Content clarity10%
Is information understandable without internal organizational knowledge?
Trust and responsibility10%
Are data use, consequences, permissions, and automation transparent?
Responsive adaptation10%
Does each viewport receive an appropriate composition?
Visual craftsmanship5%
Are hierarchy, typography, spacing, states, and motion coherent?
A beautiful application with poor task completion should fail the review.

13 · Launch checklist

Production-readiness checklist

Progress is stored locally in this browser. This checklist is an enhancement; all guidance remains available without JavaScript.

0 of 12 checks complete.

14 · Sources

Primary references

These are the principal systems and standards used to derive the handbook. Links open in a new tab.