| name | ux-mobile-responsiveness-audit |
| description | Run a structured mobile-responsiveness audit on a design, screen, or component — viewport adaptation and reflow, orientation, touch-target size and spacing, thumb reachability, mobile input ergonomics, gesture safety, and mobile readability/content priority. Produces a severity-rated issue list with concrete fixes. Use when reviewing whether a UI works on phones/tablets, or as a validation step after generating mobile or responsive UI. |
| license | MIT |
| metadata | {"author":"uxcel","version":"1.0.0"} |
Mobile Responsiveness Audit Skill
How this skill behaves (read first)
This is an evaluative skill — it reviews existing work against mobile/touch standards, it doesn't generate. Flagging is safe, so it auto-runs and is built to be called as a validation step by generative skills whenever the target is mobile or responsive (the component family, screens, and flows all hand off here for their mobile context).
It owns the mobile/touch-adaptation concern in this repo. To avoid duplicating its sibling audits, it defers:
- WCAG ratios, screen-reader/assistive-tech, keyboard operability, alt text, captions → the accessibility audit. This skill judges physical touch ergonomics and layout adaptation, not AT compatibility or contrast math.
- Visual composition — hierarchy, spacing aesthetics, emphasis → the aesthetics audit.
- Usability, flow, and interaction logic → the heuristics audit.
- Content structure / navigation scheme → the information-architecture audit; type scale →
ux-typography.
Applicability gate: this audit only applies when the target is meant to work on mobile or across breakpoints. If a design is explicitly desktop-only (e.g. a complex internal admin tool with no mobile support), say so and skip — don't manufacture mobile findings.
Scope discipline. When invoked directly (the user named this audit), review only this concern — don't pull in sibling audits. It runs alongside other lenses only when an orchestrator (ux-design-review) or a generative skill calls it under docs/orchestration-policy.md, where it sits in Tier B — offered (only when the platform is mobile). Explicit scope always wins.
What this skill changes vs. default behavior
By default, "is it mobile-friendly?" gets a vague answer — "make the buttons bigger," "it should be responsive" — with no threshold, no severity, and no systematic sweep. This skill forces:
- Every finding names the violated principle (reflow, touch-target size, thumb reach, etc.) and gives the concrete threshold (44pt / 48dp, ≥8dp spacing, ≥16px body).
- Severity rated by whether it blocks the task on the device vs. adds friction vs. polish.
- A specific fix, not "optimize for mobile."
- A systematic sweep of all seven areas, so issues beyond "small tap targets" — orientation locks, wrong keyboard types, gesture dead-ends, non-reflowing layouts — actually get caught.
The framework — what to check and what a violation looks like
Work through each. Flag with principle, severity, fix.
1. Viewport adaptation & reflow
The layout must adapt to the viewport — fluid grids, flexible images, content that reflows and reorganizes — rather than a fixed-width desktop layout squeezed onto a small screen. (Responsive = one fluid layout with breakpoints; adaptive = distinct layouts per breakpoint. Either is fine; not adapting is the failure.)
Flag when: horizontal scrolling or content cut off at the edges; a fixed-width (px) container that doesn't shrink; tiny zoomed-out desktop layout; elements overlapping or colliding between common breakpoints; images that don't resize proportionally; multi-column layouts kept on narrow screens instead of stacking vertically.
- ❌ A 1200px content frame on a 390px phone → user must pinch-zoom and scroll sideways to read.
- ✅ Content reflows to a single fluid column; images scale; nothing exceeds the viewport width.
2. Orientation resilience
Users hold devices both ways. Essential features must work in portrait and landscape; orientation changes should be purposeful, not breaking.
Flag when: the layout breaks, clips, or leaves dead space when rotated; core functionality is locked to one orientation without a real reason; a keyboard-heavy or video screen is forced to portrait when landscape would serve better; auto-rotation fires where it disrupts the task.
- ❌ Rotating to landscape hides the submit button below an un-scrollable fold.
- ✅ Portrait is the primary design; landscape reflows and keeps every essential action reachable.
3. Touch-target size & spacing
Fingers and thumbs are imprecise. Targets must be large enough and spaced enough to hit reliably — especially for adjacent contradictory actions (Save vs. Delete).
Flag when: interactive targets below the platform minimum — iOS 44×44pt, Material 48×48dp (WCAG floor 24px, but the platform minimums are the working target); less than ~8dp/16px spacing between tappable elements; corner targets the same size as central ones (corners are harder — aim larger, ~12mm vs ~7mm center); destructive and confirming actions tiny and adjacent.
- ❌ A 28px icon button row with 2px gaps; "Delete" sits flush against "Save."
- ✅ ≥44pt/48dp targets, ≥8dp spacing, extra size for corner/contradictory actions.
4. Thumb reachability & one-handed use
People operate phones one-handed and prefer the screen center; hands obscure the interface and shift grip constantly.
Flag when: primary actions stranded in hard-to-reach top corners; destructive actions in the easy-tap thumb zone where they're hit by accident; key content jammed against the top edge; no bottom padding so content can't scroll to the comfortable center; right-edge-only button placement.
- ❌ The main CTA pinned top-right; a "Delete account" button in the bottom-center thumb sweet spot.
- ✅ Primary actions within thumb reach (lower-center / bottom sheet); destructive actions guarded or out of the accidental-tap zone; content scrollable to center.
5. Mobile input ergonomics
Typing on mobile is slow and error-prone (≈41% type two-thumbed). Match the input method to the data and minimize manual entry.
Flag when: a generic keyboard where a contextual one fits (no numeric keypad for phone/PIN, no "@"-optimized keyboard for email, no URL keyboard for web addresses); no autofill/autocomplete for name, address, email, payment; free-text fields where selection controls (picker, radio, toggle) would do; long forms not chunked across steps; no OTP autofill / card-scan where available.
- ❌ Phone-number field opens the full QWERTY keyboard; address typed from scratch with no autofill.
- ✅ Numeric keypad for numbers, email keyboard for email; autofill and selection controls reduce typing.
6. Gesture safety & discoverability
Gestures are invisible — they have discoverability, consistency, and accessibility limits. They should supplement, never solely carry, an action.
Flag when: a critical action is reachable only by a hidden gesture (edge-swipe menu, long-press) with no visible control; non-standard gestures redefining system conventions; complex multi-finger gestures required (exclude users with motor/dexterity limits); activation on touch-start rather than touch-end-within-target (accidental triggers).
- ❌ The only way to delete an item is an undiscoverable left-swipe; no button alternative.
- ✅ Swipe offered as a shortcut alongside a visible control; only simple, conventional gestures are required.
7. Mobile readability & content priority
Small screens used outdoors and in motion demand readable text and a ruthless first-screen priority — adapt content for mobile, don't just shrink the desktop.
Flag when: body text below 16px; mobile line length outside ~30–40 characters; display typefaces at small sizes; the screen tries to show everything instead of leading with the primary task; secondary/tertiary functions crowding the first view instead of living below the fold or behind menus; the mobile version feels like a different product from desktop (inconsistent patterns, colors, controls).
- ❌ 12px body text, four competing CTAs above the fold, a desktop-only color scheme.
- ✅ ≥16px body, one clear primary action first, secondary actions deferred, consistent with the desktop product.
Tension note: mobile pushes toward fewer, larger elements (targets, type, one primary action) while product owners push to surface more. Resolve toward the device reality — limited space and imprecise touch — and defer extra density to progressive disclosure rather than cramming. Where a fix would collide with the accessibility audit (e.g. target size, gesture alternatives), state it once and let accessibility own the AT/WCAG framing.
Severity rating
| Severity | Meaning |
|---|
| Critical | Unusable on the target device — content cut off / horizontal scroll, targets too small to tap reliably, a critical action only via an undiscoverable gesture, or a core feature locked to an unavailable orientation. Fix before ship. |
| Major | Significant friction users shouldn't have to absorb — targets below the platform minimum but still tappable, primary action outside thumb reach, wrong keyboard type, body text below 16px, layout that reflows poorly at a common breakpoint. |
| Minor | Noticeable polish — slightly tight spacing, a non-ideal landscape layout, mild over-density, corner targets not enlarged. |
Rate by impact on completing the task on the actual device, not by how easy the fix is. A one-line keyboard-type change can still be Major if it blocks fast entry.
Audit output format
## Mobile Responsiveness Audit — [Screen / Component]
Context: [device class / breakpoints · orientation · primary task, if known]
### Critical
- [Issue] — what's wrong → fix. (Principle: …)
### Major
- …
### Minor
- …
### Working well ✓
- …
**Top 3 priorities:** the highest-impact fixes for the target device.
End with the prioritized top 3 — that's what a calling generator acts on.
How to run a good audit
- Establish context — device class (phone/tablet/responsive web), the breakpoints in scope, orientation expectations, and the screen's primary task. Touch ergonomics can only be judged against the device and the action that matters most.
- Confirm applicability — if it's genuinely desktop-only, skip rather than inventing findings.
- Sweep all seven areas — the value over a default review is completeness; don't stop at touch-target size.
- Use the thresholds — 44pt/48dp targets, ≥8dp spacing, ≥16px body, ~30–40 char lines — so findings are checkable, not vibes.
- Defer contrast/AT/keyboard to accessibility, composition to aesthetics, flow to heuristics — don't re-derive them here.
- Prioritize, don't enumerate — rate by whether it blocks the task on the device.
Common do/don't patterns
| ❌ Don't | ✅ Do |
|---|
| "Make it responsive" / "buttons too small" | Name the principle + threshold (44pt/48dp, ≥16px) + the fix |
| Treat every nit as equal | Rate by whether it blocks the task on the device; surface top 3 |
| Shrink the desktop layout onto the phone | Reflow to a fluid single column; nothing exceeds viewport width |
| Lock core features to one orientation | Essential actions work in portrait and landscape |
| 28px targets with 2px gaps | ≥44pt/48dp targets, ≥8dp spacing, corners enlarged |
| Primary CTA top-corner; delete in the thumb zone | Primary within thumb reach; destructive guarded / out of easy reach |
| Full QWERTY for a phone-number field | Contextual keyboards; autofill; selection over typing |
| Hide the only path to an action behind a swipe | Gestures supplement a visible control, never replace it |
| Re-derive WCAG contrast or screen-reader issues | Defer to the accessibility audit |
| Report only tap-target size | Sweep all seven areas; cite the principle and threshold |
Source lessons (Uxcel)
