Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts.
NewMaintained
Automatic
◆Design & UX Review pack
Last verified 8/21/2026
What it changes
Passed 17 of 22 test cases with the skill, and 17 of 22 without it.
Without skill77%
With skill77%
Checks it passed that the model alone missed
The response explicitly names the specific target user persona.
The response explicitly defines the core job the user is trying to accomplish.
The response flags that surface-level fixes indicate the checkout flow intent needs re-examination.
and 1 more in the full report
2 fixed15 passed either way3 still failing2 broke
Pass-rate lift
0 pp
Tokens
+14%
Agent turns
0%
Response time
+2%
Model gemini-3.6-flashMeasured 8/21/2026v117 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 2
Prompt
Here is a list of UI bug tickets for our checkout flow: 'Change button label from Submit to Pay Now', 'Move billing address box above shipping address', 'Add an info icon next to card field'. Provide a review of these proposed UI changes for the checkout team.
What was checked, without and with the skill
Checked
Without skill
With skill
The response evaluates the underlying user goal of completing purchase instead of evaluating the surface label tweaks in isolation.
Missed
Passed
The response flags that surface-level fixes indicate the checkout flow intent needs re-examination.
Missed
Passed
case-04 · gemini-3.6-flash · 8/21/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md33 linessingle file
User Experience
Apply this lens to any user-facing change, both before committing to an approach and when judging a built experience. Keep the work anchored to what the user is trying to accomplish.
Lead with the user's goal rather than a list of surface fixes. A pile of small corrections ("relabel this", "move that") is a sign the underlying flow was never examined. Start from intent and work down to detail.
Scope: this lens covers whether a change serves the user and whether the path through it is coherent. Visual and aesthetic craft — typography, color, spacing, motion polish — is a separate concern and stays out of scope here.
Understanding
Establish what the user actually needs before shaping a solution.
Name the user and the job they came to do.
Separate the stated request from the goal behind it, and solve the goal.
Ground claims about user needs in evidence (observed behavior, recurring reports, real usage). Flag a need that is assumed rather than known.
Bridging
Translate the need into the right solution rather than the first one that comes to mind.
Check that the solution addresses the goal, not just the visible symptom.
Weigh whether the change adds a step, a screen, or a concept the user must learn, and whether that cost is justified.
Prefer the path that removes work for the user over one that adds configuration or choices.
Watch for solving a builder's convenience at the user's expense.
Flowing
Trace the path the user takes from end to end.
Follow the full journey: how the user arrives, the change itself, and what happens after.
Walk the unhappy paths in the running software when it can be run: empty states, seeded defaults, errors, interruptions, first-time versus returning use. Flag any of these judged from source alone.
Confirm the user always knows what just happened and what to do next.
Surface friction: redundant steps, dead ends, and points where the user must hold state in their head.
Designing and evaluating complex AWS architectures — multi-account AWS Organizations, hybrid and cross-account networking (Transit Gateway, PrivateLink, Direct Connect), business-continuity and DR design, migration and modernization strategy (the 7 Rs), and cost/resilience/performance trade-offs at enterprise scale. Use when making or reviewing enterprise AWS design decisions across organizational complexity, new solutions, continuous improvement, or workload migration. Not hands-on pipeline/IaC