stack/skills/ms-frontend-design/references/design-principles.md

Design principles as operating rules

These are contextual heuristics with concrete checks. The implementations below are this skill's application of the linked principles. They are not claims that a psychological law prescribes an exact component or pixel value.

UX-01 — Familiar behavior (SHOULD)

Applies: navigation, controls, and changes to an established interface. Behavior: reuse familiar control semantics, labels, and platform conventions. Preserve established product patterns unless changing them solves a demonstrated problem. Check: walk the same task before and after the change; confirm users do not need to discover a new meaning for an existing control. Exception: a specialized interaction may be justified by the task; provide discoverable instructions and an accessible alternative where needed. Source: Jakob's Law.

UX-02 — Reliable targets (SHOULD)

Applies: pointer and touch actions. Behavior: provide generous actual hit areas, separate neighboring actions, and place frequent actions near their task context. Keep destructive actions distinct from frequently used actions to reduce accidental activation. Check: inspect hit areas and pointer travel at narrow and wide layouts; exercise adjacent actions with touch or an appropriate simulation. Exception: dense tools may use smaller controls, subject to the requirements in accessibility; icon size is not hit size. Source: Fitts's Law.

UX-03 — Manage choices (SHOULD)

Applies: menus, forms, onboarding, and decision-heavy screens. Behavior: organize choices by intent; make the next step clear in the active task region. Disclose infrequent complexity progressively without hiding frequent actions or information needed for a decision. Check: complete representative tasks; inspect whether grouping or hidden options create extra search, backtracking, or unnecessary steps. Exception: comparison tasks and expert tools can benefit from simultaneous options. There is no universal maximum menu length or one-button-per-page rule. Source: Hick's Law.

UX-04 — Spacing communicates relationships (SHOULD)

Applies: forms, content groups, toolbars, and responsive composition. Behavior: use smaller gaps within groups than between groups. Keep labels, help, errors, and controls together. Use a shared region or border when it clarifies a real boundary; not every group needs a card. Check: examine grouping after wrapping, at narrow widths, and with long labels. A field error must not appear to belong to its neighbor. Exception: a stronger semantic or visual boundary may establish grouping without a spacing difference; make the relationship unambiguous. Sources: Proximity, Common region.

UX-05 — Appearance carries consistent meaning (SHOULD)

Applies: repeated components, status colors, and action hierarchies. Behavior: give equivalent actions and states consistent treatment. Reserve distinct emphasis for meaningful priority or differences; never rely on color alone to convey status. Check: compare repeated controls across routes and themes; confirm equal appearances do not imply incompatible behaviors. Exception: context can change prominence without changing a control's meaning; document intentional variants in the component system. Source: Similarity.

UX-06 — Reduce memory burden (SHOULD)

Applies: multistep tasks, forms, navigation, and comparison. Behavior: keep labels, selected values, requirements, and relevant prior choices visible or easily retrievable. Chunk content by meaning. Check: complete the task without memorizing information from an earlier screen; verify returning to a step preserves recoverable input. Exception: expert shortcuts may supplement a discoverable path. Do not derive a seven-item interface limit from a working-memory principle. Sources: Miller's Law and its cautions, Nielsen's heuristics.

UX-07 — Feedback and recovery (MUST)

Applies: operations that change state or can fail. Behavior: show pending, success, and failure truthfully. Explain recovery, preserve recoverable input, prevent accidental duplicate submissions, and provide cancel or undo when the operation supports it. Match confirmation friction to the consequence of an error. Optimistic UI needs failure handling. Check: exercise slow, failed, and repeated requests; verify the interface does not claim completion prematurely or leave the user stranded. Exception: instantaneous local actions need no artificial loading state. An unavailable recovery operation must not be offered as a working control. Source: Nielsen's heuristics.

Applying and resolving rules

Prefer measured task outcomes over a heuristic when they conflict. For example, moving a destructive action closer may reduce pointer travel but increase accidental activation; task safety takes priority. Record consequential tradeoffs briefly. Do not use a law's name as evidence that a design works.