preference-product-ui

name

preference-product-ui

description

Applies a scenario-matched preference brief to task-oriented product interfaces such as dashboards, forms, tables, settings, and operational workflows while preserving correctness, accessibility, state coverage, and task completion. Use when designing or revising authenticated or data-dense application UI. Do not use for marketing pages, purely editorial layouts, or aesthetic review without a representative task and realistic data states.

Preference Product UI

Apply preferences to task-oriented software without hiding data, states, permissions, or operational risk.

Keep three judgments separate

Keep correctness, task fitness, and human preference separate. Never average them into one quality or taste score. A preferred layout stays blocked when it misstates data, hides required status, harms task completion, or weakens accessibility.

Confirm the route

Use this skill for dashboards, forms, settings, tables, queues, repeated workflows, and authenticated product screens.

Route public acquisition and editorial pages to preference-marketing-web. Do not reuse a marketing preference record merely because the application shares a brand.

Protect the task model

Record before subjective review:

• user role, core task, frequency, stakes, device, and success condition;
• exact source revision and runtime;
• permissions, business rules, data semantics, and destructive-action behavior;
• representative synthetic or permitted data;
• required normal, empty, loading, error, permission-denied, long-content, and large-data states;
• keyboard, focus, assistive-technology, and recovery requirements.

Do not judge density or hierarchy from an empty mock.

Apply or calibrate one product axis

Load only a product-UI preference record matching the scenario and task.

Use these axes as question prompts:

• information density;
• hierarchy and grouping;
• navigation and orientation;
• control prominence;
• feedback and status visibility;
• confirmation and error recovery.

For an unresolved axis:

1. Fix the task, data, permissions, and state.
2. Change one factor or mark the trial confounded.
3. Use neutral candidate IDs and randomized order.
4. Let the decision-maker choose, reject all, or abstain.
5. Record the literal response before interpreting it.
6. Stop if a candidate fails correctness or task requirements.

Read references/product-ui-axes.md before constructing the trial.

Exercise realistic states

Use references/state-and-task-matrix.md to preregister the state and task checks.

At minimum:

1. Run the core task with realistic data.
2. Exercise each applicable state.
3. Check destructive and irreversible actions.
4. Check keyboard paths, focus order, screen-reader semantics, and non-color status cues.
5. Record task errors and recovery behavior.
6. Test one held-out task or state not used during calibration.
7. Pass the exact revision and dossier to preference-verify.

Stop and refuse

Block release for:

• incorrect data, calculations, permissions, or business behavior;
• broken or meaningfully slower core task;
• missing realistic data or state coverage;
• ambiguous destructive actions;
• status visible only through color or decoration;
• broken focus, keyboard, assistive-technology, or recovery behavior;
• preference-led hiding of required information;
• a marketing or editorial preference imported into product work;
• a request to make a dashboard "tasteful" without a task contract.

Return INSUFFICIENT CONTEXT when realistic states cannot be exercised. Preserve the conflict when a stated preference harms safety, accessibility, or task completion.

Output

Return:

• exact revision, role, task, and success condition;
• state matrix and interaction evidence;
• applied preference rules and provenance;
• held-out task or state result;
• separate correctness, task-fit, and preference assessments;
• blockers that preference cannot override.