Mobile stress lab
Test eight pressures across one complete journey
Use real long content and adverse states. A page that passes at one preset width may still fail when controls, keyboards or dynamic content appear.
Navigation
Reach every critical destination with touch and keyboard.
- Pressure
- Menu open, back, deep link and scroll
- Failure
- Overlay traps focus or page position
- Evidence
- Complete route journey
Reflow and zoom
Preserve reading order and actions as content grows.
- Pressure
- 320px width, enlarged text and 400% zoom
- Failure
- Horizontal page scroll or clipped action
- Evidence
- No lost information or function
Touch targets
Make controls distinguishable and operable without fine pointing.
- Pressure
- Adjacent actions, sticky UI and one-hand use
- Failure
- Tiny icon controls trigger neighbor
- Evidence
- Target-size and spacing review
Forms and keyboard
Keep labels, errors and submit visible during input.
- Pressure
- Virtual keyboard, autofill and validation
- Failure
- Fixed footer covers active field
- Evidence
- Completed real form journey
Dynamic content
Handle banners, errors, loading and long records.
- Pressure
- Slow response, empty and maximum content
- Failure
- Layout designed only for demo data
- Evidence
- State matrix at narrow width
Orientation and safe area
Avoid controls hidden by device geometry or rotation.
- Pressure
- Portrait, landscape and inset areas
- Failure
- Fixed action conflicts with browser chrome
- Evidence
- Representative physical-device check
Performance
Measure useful content and interaction on constrained hardware.
- Pressure
- Mid-range device and slower network
- Failure
- Hydration blocks first action
- Evidence
- Journey performance budget
Assistive use
Combine mobile layout with screen-reader and switch behavior.
- Pressure
- Labels, focus order, announcements and motion
- Failure
- Visual reorder differs from semantic order
- Evidence
- Manual assistive journey
Operating principle
Test the outcome, not a gallery of widths
Viewport screenshots catch obvious wrapping defects, but they do not expose keyboard obstruction, focus loss, slow interaction, accidental touch or whether the user can recover from an error.
Choose one critical journey and run it across representative emulation and physical devices. Record browser, viewport, content state and interaction method so failures can be reproduced.
- Include real long content
- Test virtual keyboards
- Use physical devices
- Check zoom and assistive technology
Applied example
Mobile example: valid form, impossible submit
A registration form fits at 390 pixels. When the virtual keyboard opens, a fixed cookie banner and sticky footer cover the final field and submit button.
- Static viewport inspection passed
- Dynamic browser space was not tested
- Two fixed layers competed with the task
- The user cannot complete the journey
Plain answers
Questions to resolve before shipping
Which mobile widths should we test?+
Choose representative small and common widths plus content and zoom extremes. Do not rely only on named device presets.
Is browser emulation enough?+
No. It is efficient for repeatable coverage, but physical devices reveal keyboard, performance, browser chrome, touch and assistive behavior.
Should mobile have fewer features?+
Preserve critical information and outcomes. Recompose or defer optional presentation rather than removing essential capability without a product decision.