sc-ux — usable before impressive
Language
Keep durable instructions in English. Reply in the user's language unless requested otherwise.
Core model
Optimize for task completion, comprehension, control, recovery, and accessibility. Do not equate fewer visible controls with better UX; hide complexity only when users can still discover, understand, and recover from actions.
Before changing a flow, identify:
- primary user jobs and frequency,
- user expertise and likely mental model,
- entry points and navigation path,
- current state model,
- irreversible/destructive actions,
- latency and failure points,
- keyboard/touch/pointer requirements,
- accessibility requirements,
- responsive task priority,
- explicit scope exclusions.
Usability gates
Every important flow should satisfy:
- Status is visible: users can tell what is happening, what changed, and what is selected.
- Language matches the user's task, not internal architecture.
- Users retain control: cancel/back/undo/retry where meaningful.
- Patterns are consistent across the product unless a difference communicates meaning.
- Prevent errors before explaining them.
- Prefer recognition over memory: labels, context, recent choices, and visible affordances beat hidden recall.
- Frequent tasks are efficient without making first use opaque.
- Interfaces contain only information/actions that earn their place.
- Errors explain impact and next recovery action.
- Help appears near the blocking context rather than as a documentation dump.
Interaction state contract
Important async/action surfaces must cover applicable states:
idle → pending → progress → success | error → retry/cancel.
Data surfaces must cover applicable states:
loading → populated | empty | error | permission-denied | offline/stale.
Do not use ambiguous spinners for long operations when meaningful progress/state can be shown.
Accessibility baseline
Use semantic controls and names. Preserve visible focus. Keyboard users must reach and operate every primary action without pointer-only traps. Do not encode meaning by color alone. Maintain sufficient text/control contrast. Respect reduced motion. Provide non-drag alternatives for required drag interactions. Make touch/pointer targets practical and avoid destructive actions adjacent to frequent controls without separation/confirmation/undo.
Desktop/workbench UX
For desktop shells and productivity tools:
- keep global navigation, local navigation, work area, and contextual tools conceptually distinct,
- support predictable focus movement between regions,
- use one tab stop for composite toolbars/lists where appropriate and arrow-key navigation inside them,
- preserve user context when opening/closing inspectors, dialogs, and secondary panes,
- make resize/collapse boundaries discoverable,
- remember reasonable layout state when product requirements allow,
- keep primary work visible; do not let chrome dominate the canvas,
- command palettes/shortcuts accelerate frequent actions but do not replace discoverable UI for essential tasks.
Responsive behavior
Responsive UX is reprioritization, not desktop columns → one long mobile stack. Preserve the highest-value task and state. Do not alter an explicitly excluded mobile/navigation surface.
Verification
When tools allow, test the real flow rather than only reading components:
- first-use path,
- frequent-user path,
- keyboard-only path,
- error/retry path,
- empty/loading path,
- destructive action recovery,
- representative viewport resize,
- deep link/back-forward behavior where relevant.
Record defects as problem → user impact → fix → verification.
1---2name: sc-ux3description: SI-Coder user experience skill for usable, accessible, predictable web interactions: navigation, information architecture, feedback, keyboard behavior, errors/recovery, forms, loading/empty states, responsive task priority, and desktop workbench ergonomics.4---56# sc-ux — usable before impressive78## Language9Keep durable instructions in English. Reply in the user's language unless requested otherwise.1011## Core model12Optimize for task completion, comprehension, control, recovery, and accessibility. Do not equate fewer visible controls with better UX; hide complexity only when users can still discover, understand, and recover from actions.1314Before changing a flow, identify:15- primary user jobs and frequency,16- user expertise and likely mental model,17- entry points and navigation path,18- current state model,19- irreversible/destructive actions,20- latency and failure points,21- keyboard/touch/pointer requirements,22- accessibility requirements,23- responsive task priority,24- explicit scope exclusions.2526## Usability gates27Every important flow should satisfy:281. Status is visible: users can tell what is happening, what changed, and what is selected.292. Language matches the user's task, not internal architecture.303. Users retain control: cancel/back/undo/retry where meaningful.314. Patterns are consistent across the product unless a difference communicates meaning.325. Prevent errors before explaining them.336. Prefer recognition over memory: labels, context, recent choices, and visible affordances beat hidden recall.347. Frequent tasks are efficient without making first use opaque.358. Interfaces contain only information/actions that earn their place.369. Errors explain impact and next recovery action.3710. Help appears near the blocking context rather than as a documentation dump.3839## Interaction state contract40Important async/action surfaces must cover applicable states:41`idle → pending → progress → success | error → retry/cancel`.4243Data surfaces must cover applicable states:44`loading → populated | empty | error | permission-denied | offline/stale`.4546Do not use ambiguous spinners for long operations when meaningful progress/state can be shown.4748## Accessibility baseline49Use semantic controls and names. Preserve visible focus. Keyboard users must reach and operate every primary action without pointer-only traps. Do not encode meaning by color alone. Maintain sufficient text/control contrast. Respect reduced motion. Provide non-drag alternatives for required drag interactions. Make touch/pointer targets practical and avoid destructive actions adjacent to frequent controls without separation/confirmation/undo.5051## Desktop/workbench UX52For desktop shells and productivity tools:53- keep global navigation, local navigation, work area, and contextual tools conceptually distinct,54- support predictable focus movement between regions,55- use one tab stop for composite toolbars/lists where appropriate and arrow-key navigation inside them,56- preserve user context when opening/closing inspectors, dialogs, and secondary panes,57- make resize/collapse boundaries discoverable,58- remember reasonable layout state when product requirements allow,59- keep primary work visible; do not let chrome dominate the canvas,60- command palettes/shortcuts accelerate frequent actions but do not replace discoverable UI for essential tasks.6162## Responsive behavior63Responsive UX is reprioritization, not `desktop columns → one long mobile stack`. Preserve the highest-value task and state. Do not alter an explicitly excluded mobile/navigation surface.6465## Verification66When tools allow, test the real flow rather than only reading components:67- first-use path,68- frequent-user path,69- keyboard-only path,70- error/retry path,71- empty/loading path,72- destructive action recovery,73- representative viewport resize,74- deep link/back-forward behavior where relevant.7576Record defects as `problem → user impact → fix → verification`.