--- name: mobile-screen-eval description: Run rigorous heuristic and accessibility evaluations on mobile app screens. Use whenever the user wants to heuristic-eval, UX audit, critique, accessibility-check, or review mobile screens, whether shared as Figma frames, exported images, or descriptions. Applies three layers (Nielsen's 10 usability heuristics, WCAG 2.1 AA accessibility, and mobile platform accessibility from iOS HIG plus Material Design). Produces a per-screen markdown report with severity-rated findings on Nielsen's 0–4 scale. Trigger even when the user just pastes a single screen and says "review this," "audit this," "any issues with this," or "what would you change." Works for any mobile product, from consumer apps and B2B tools to fintech, health, or any other domain. --- # Mobile Screen Eval A rigorous three-layer evaluation framework for mobile app screens. Domain-agnostic: works for any mobile product on iOS or Android. Produces findings that are specific, evidence-based, and actionable. ## What this skill does Takes a screen (Figma frame, exported image, or description) plus optional flow context, and produces a per-screen markdown report with exhaustive findings. Each finding is rated on Nielsen's 0–4 severity scale, tied to a specific heuristic or accessibility criterion, and accompanied by a concrete recommendation. Three evaluation layers run in order: 1. Nielsen's 10 usability heuristics 2. WCAG 2.1 AA accessibility 3. Mobile platform accessibility: iOS HIG + Material Design ## When to use this skill Any time the user asks to evaluate, audit, critique, or review a mobile screen for usability or accessibility. Works for single screens or batches. If the product has its own design principles or brand guidelines, ask the user to share them. They can be applied as a fourth layer on top of the universal three. ## Workflow ### Step 1: Understand the screen - If a Figma frame link is provided and Figma MCP is connected: call `Figma:get_design_context` for structured layer data. - If an image is provided: analyze visually. Note explicitly what you can and cannot assess at the image's resolution. - Identify screen type: entry / list / detail / form / confirmation / error / empty state / modal / bottom sheet / other. - Note the user's apparent goal on this screen if context is provided. If not, infer and flag the inference in Assumptions. ### Step 2: Load reference files - `references/nielsen-heuristics.md`: Layer 1 - `references/wcag-aa-mobile.md`: Layers 2 and 3 ### Step 3: Run all three layers Be exhaustive: if the user asked for this eval, they want every finding. If a layer has nothing to flag, write "No findings in this layer." Do not pad. ### Step 4: Severity-rate everything Use Nielsen's 0–4 scale (below). State the reasoning when bumping severity up. ### Step 5: Produce the report Use the template in `references/templates.md`. ## Severity rubric: Nielsen 0–4 - **0: Not a problem.** Noted for completeness. Do not fix. - **1: Cosmetic.** Fix only if time permits. Visual inconsistency, minor copy tweak. - **2: Minor.** Low priority. Users notice but can work around it easily. - **3: Major.** High priority. Fix before ship. Meaningfully slows, confuses, or frustrates users. - **4: Catastrophic.** Must fix. Blocks task completion, causes data loss, creates safety or legal risk, or breaks accessibility fundamentally. ### How to defend a severity rating Every rating should be defensible by answering: - What specifically happens to the user? (Concrete consequence, not "it's confusing") - How often does it happen, and for whom? - Can the user recover? How easily? - What's the cost: time, money, data, trust, safety? A Sev 4 should answer at least two of those significantly. A Sev 2 might answer one, mildly. ## Handling missing context When flow or user goal is unknown: 1. Infer from visual evidence 2. State inferences explicitly in the Assumptions section 3. Evaluate against the inferred context 4. Call out which findings would change if assumptions are wrong Never silently guess. An explicit assumption can be corrected in seconds; a silent one costs a re-review. ## Intent-check before flagging Before writing a finding, ask: is this a deliberate design decision with a clear rationale? If yes, note it in What's Working, not Findings. If uncertain, ask the user before flagging. "Is this placement intentional?" costs 10 seconds and prevents a wasted finding. ## Copy as a UX issue: when to flag, when to skip Copy is in scope when it's also a UX problem: - Error message doesn't tell the user what to do next → H9 - Label uses system terminology the user doesn't understand → H2 - Instructions too dense for the time available → H8 Copy is out of scope when the issue is purely tone, brand voice, or style preference. Those belong in a separate copy audit, not a heuristic eval. ## Principles this skill follows - **Specificity beats volume.** Every finding names the exact element, the exact heuristic or criterion, and a concrete implementable fix. "Improve the hierarchy" is not a finding. - **Evidence-based.** Every finding cites what was observed: a measurement, a color, a specific string, a layout proportion. No vibes. - **Actionable.** Recommendations are implementable. "Increase the tap target from approximately 32dp to a minimum 44dp" not "consider making buttons bigger." - **Honest about uncertainty.** If the image resolution prevents a check, say so. If context is missing, say so. - **Preservation-first.** Do not flag things that are working. Do not invent issues. If a screen is clean on a layer, say so. ## Reference files - `references/nielsen-heuristics.md`: All 10 heuristics with plain-language descriptions and mobile-specific violation examples - `references/wcag-aa-mobile.md`: WCAG 2.1 AA checklist plus iOS HIG and Material Design accessibility guidance - `references/templates.md`: Per-screen report template and batch summary template