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?
Canonical decision and implementation guide · Version 2.0
Design for the smallest credible context.
Mobile-first enterprise design prioritizes outcomes, state, evidence, and user agency under constrained space, attention, input, connectivity, authorization, and time.
Five conclusions
- Mobile-first is prioritization under constraint, not desktop reduction.
- Discoverability takes precedence over decorative minimalism.
- Accessibility, performance, security, and failure recovery are architectural requirements.
- Enterprise data density must transform according to the user’s task.
- Production value comes from hierarchy, complete states, resilient behavior, and trustworthy communication.
Evidence scope: “Fortune 500-grade” describes a synthesis of public enterprise design systems, standards, usability research, and production practices. It is not a representative survey of every Fortune 500 company.
- 01Prioritize outcomesDesign decisions and workflows before screens.
- 02Expose the importantRecognition should replace unnecessary recall.
- 03Enhance progressivelyCore content and actions survive degraded execution.
- 04Make state explicitLoading, saving, stale, offline, failed, and complete are distinct.
- 05Preserve agencyConsequences, automation, permissions, and evidence remain inspectable.
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.
Make meaning survive layout changes
Content should remain understandable when columns stack, sidebars disappear, text wraps, images fail, or the page is zoomed.
Assume coarse input and interruption
Design for thumbs, variable dexterity, one-handed use, short sessions, interruptions, and no hover.
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 · Cognitive architecture
Reduce extraneous effort without hiding meaningful complexity
Cognitive load is not simply the amount of content. The design objective is to reduce interface-created friction while preserving the context needed for an accurate mental model and informed decision.
Intrinsic complexity
Complexity inherent to the task, such as incident diagnosis, regulated approval, identity policy configuration, or financial comparison. It cannot always be removed.
Extraneous complexity
Complexity created by hidden navigation, inconsistent terms, repeated entry, unclear state, disconnected controls, decorative noise, or unnecessary transitions.
Germane effort
Effort that helps users compare evidence, understand trade-offs, build a mental model, verify a decision, or recover safely.
Recognition over recall: expose options, recent items, saved views, persistent labels, examples, filter summaries, history, and status. Do not make users remember hidden paths, prior selections, exact identifiers, or internal terminology.
03 · Enterprise standard
Fortune 500-grade considerations
Mature enterprise applications balance task completion, governance, accessibility, security, data density, scale, and maintainability.
| Priority | Purpose | Typical content |
|---|---|---|
| Immediate | Enable action now | Current status, urgent exceptions, primary action |
| Supporting | Enable a sound decision | Context, summary metrics, critical dependencies |
| Investigative | Enable diagnosis | History, details, logs, related records |
| Administrative | Enable configuration | Metadata, 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 toolbarGovernance
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.
04 · Enterprise context
Preserve interruption, role, scope, and cross-channel continuity
Enterprise mobile work is frequently interrupted and rarely exists in a single role, tenant, environment, device, or communication channel.
Interruption recovery
- Draft state
- Scroll and filter state
- Selected record
- Upload or workflow progress
- Last synchronized state
Role and scope
- Current tenant and organization
- Environment and acting role
- Read-only versus editable state
- Approval authority
- Restricted fields and data scope
Cross-channel continuity
- What can finish on mobile
- What requires another device
- Whether progress transfers
- Which channel is authoritative
- What notification or approval follows
Mobile-first should not mean mobile-only. It should make transitions between channels explicit and recoverable.
05 · Discoverability
Make primary paths obvious
Recommended defaultExtreme 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.
06 · Accessibility
Accessibility shapes the architecture
Required baselineWCAG 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
| Mode | What to validate |
|---|---|
| Touch | Reach, target size, spacing, accidental activation, sticky controls |
| Keyboard | Order, focus visibility, traps, skip links, dialogs, menus |
| Screen reader | Names, roles, states, headings, live announcements, errors |
| Zoom / reflow | 200%+ zoom, text resize, no page-level horizontal scroll |
| Voice / switch | Visible labels, unique names, predictable activation |
| Reduced motion | No essential meaning depends on animation |
07 · Performance and resilience
Performance is part of visual design
Recommended architectureA 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 persistenceUse 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.
08 · Enterprise data
Transform data density instead of shrinking it
Task-dependent transformationEnterprise interfaces often contain tables, filters, dashboards, batch actions, and record detail. Each compact treatment should preserve the user’s actual task.
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
Contained table
Use when cross-record comparison is essential.
- Frozen identity column
- Prioritized columns
- Contained horizontal scroll
- Column selection
List-detail
Use separate screens on compact layouts and a split view on larger layouts.
- Preserve search
- Preserve scroll
- Preserve selection
- Deep-link records
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.
09 · 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 | FailedLoading, saving, pending approval, stale, and offline are not interchangeable. Each state needs distinct language, timing, and recovery behavior.
10 · Component state system
Demonstrate complete behavior, not only the ideal state
A production component contract should specify what users see, what they can do, and what the system guarantees in every meaningful state.
Loading
Retrieving current data
Preserve layout geometry. Identify the object loading. Do not block unrelated actions.
Saving
Saving changes
Prevent accidental duplicate submission. Preserve editable work until confirmation.
Success
Change completed
State what changed, when it changed, and what happens next.
Failed
Change was not saved
Preserve input. Explain the failure boundary. Offer a direct retry or escalation path.
Offline
Connection unavailable
Identify what remains usable and whether pending work will synchronize later.
Stale
Data may be outdated
Show the last successful update and provide a refresh or verification action.
Empty
No records yet
Distinguish a legitimate first-use state from filtered results or a loading failure.
Unauthorized
Access is restricted
Explain the required role, owner, or approval path without exposing sensitive data.
11 · 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
12 · 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.
13 · 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: supported14 · 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.
| System | Best lessons | Adapt carefully |
|---|---|---|
| GOV.UK | Transactional clarity, plain language, errors, confirmation, progressive enhancement | Its restrained identity is not a consumer-brand template |
| USWDS | Accessible public-service components and resilient implementation guidance | Federal visual conventions require contextual adaptation |
| IBM Carbon | Enterprise data, tables, structured lists, dense workflows, AI disclosure | Desktop density must be transformed for compact layouts |
| Microsoft Fluent | Adaptive layout, cross-platform behavior, command overflow | Rich command surfaces can overload novice users |
| GitHub Primer | Productivity, compact interaction, responsive layout, touch guidance | Assumes frequent and technically fluent users |
| Material Design 3 | Compact navigation, sheets, canonical adaptive layouts, touch ergonomics | Unmodified use can appear generic |
| Salesforce Lightning | Record workflows, CRM structures, enterprise action patterns | Some dense components need additional mobile optimization |
| Atlassian | Tokens, spacing, governance, cross-product cohesion | Many 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.
15 · 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.
16 · Launch checklist
Production-readiness checklist
Use this as a production-readiness review. With JavaScript enabled, progress is stored locally in this browser.
0 of 12 checks complete.
17 · Evidence and governance
Separate requirements, recommendations, and contextual patterns
A mature handbook should state the authority, confidence, exceptions, and review status behind material guidance.
| Guidance | Classification | Evidence basis | Qualification |
|---|---|---|---|
| WCAG 2.2 Level AA baseline | Required | W3C accessibility standard | Additional legal and organizational requirements may apply. |
| 44–48px preferred touch region | Recommended | WCAG floor plus platform ergonomic guidance | Inline links and dense expert tools require contextual evaluation. |
| One dominant decision per view | Recommended | Hierarchy and cognitive-load synthesis | Opposing or secondary actions may remain visible when clearly differentiated. |
| Bottom navigation | Context-dependent | Mobile application-shell guidance | Not a default for reports, handbooks, linear transactions, or unstable destinations. |
| Fortune 500-grade considerations | Scope statement | Public enterprise systems, standards, and research | Not a representative audit of every Fortune 500 company. |
Governance contract: retain a canonical source, owner, version, change history, validation status, provenance, and machine-readable metadata. Derived visual artifacts should not become the only source of truth.
18 · Sources
Primary references
These are the principal systems and standards used to derive the handbook. Links open in a new tab.
- WCAG 2.2Accessibility requirements and success criteria.
- WCAG target size guidanceMinimum pointer target requirements and exceptions.
- GOV.UK Design SystemTransactional clarity, plain language, errors, confirmation, and progressive enhancement.
- U.S. Web Design SystemAccessible, mobile-friendly public-service components and implementation guidance.
- IBM Carbon Design SystemEnterprise data patterns, tables, lists, components, and design-system operations.
- Microsoft Fluent 2Adaptive layouts, command structures, drawers, and cross-platform behavior.
- Material Design 3Adaptive canonical layouts, navigation, touch ergonomics, and bidirectionality.
- GitHub PrimerProductivity patterns, compact interaction, and accessible implementation.
- Atlassian Design SystemTokens, spacing, governance, and multi-product consistency.
- Salesforce Lightning Design SystemRecord-oriented enterprise workflows and component patterns.
- Core Web VitalsLoading performance, responsiveness, and visual stability.
- W3C Ethical Web PrinciplesPrivacy, security, accessibility, internationalization, and user control.
- OWASP ASVSSecurity verification and secure-by-design application architecture.
- Nielsen Norman GroupUsability research on navigation, information architecture, forms, and data-heavy interfaces.