Process And Robustness Principles

Use this skill whenever the question is *how* to develop a design — through one big push or through repeated cycles of build, test, learn, refine. Trigger when planning a design process, scoping an MVP, deciding between waterfall and iterative delivery, planning research cadence, or reviewing why a project drifted from its original vision. Iteration is one of the foundational principles in 'Universal Principles of Design' (Lidwell, Holden, Butler 2003) — and one of the most-violated by teams that try to ship "perfect" first versions.

Use this skill whenever the design has unknowns that need testing — when a sketch could resolve a debate, when assumptions about user behavior could be checked cheaply, when a high-fidelity build would benefit from a low-fidelity draft first. Trigger when planning research, when scoping a new feature, when stakeholders want to see something concrete, or when the team is stuck arguing about an approach. Prototyping is one of the foundational principles in 'Universal Principles of Design' (Lidwell, Holden, Butler 2003) and one of the highest-leverage process principles — the cheapest prototype that resolves the question is almost always cheaper than the consequences of skipping it.

Apply the principle of the Weakest Link — a system's reliability is determined by its least reliable component, not by the average. Use when designing critical-path workflows, evaluating dependencies for risk, deciding where to invest in robustness, auditing onboarding or checkout flows for the step most likely to fail. The user's experience of the product is dominated by its worst step. Improving the average without improving the weakest step often doesn't improve the experience at all.

Use this skill on every design task that produces a user-facing surface. Trigger on every screen, component, prototype, or design review — accessibility isn't a phase, it's a property each surface either has or doesn't. Trigger when the user mentions accessibility, a11y, WCAG, screen readers, keyboard navigation, contrast, motion sensitivity, ARIA, color blindness, "section 508," "EAA," or compliance. Also trigger when the user is *not* asking about accessibility — because most of the highest-impact accessibility decisions are made silently when no one was asking. Routes to sub-aspect skills for the four WCAG sub-principles: perceivable, operable, understandable, robust.

Apply Ockham's Razor — given a choice between functionally equivalent designs, prefer the simplest. Use when comparing design approaches, evaluating whether a feature is necessary, deciding between elaborate and minimal solutions, auditing a product for accumulated complexity, or pruning features that no longer earn their place. The principle is not "always make things simpler" — it's "when two designs do the same thing, pick the simpler one." Most design problems involve actual tradeoffs; the razor cuts only when functionality is truly equivalent.

Use this skill whenever the question is *how* to design well over time or *how* to make a design that doesn't break — accessibility, prototyping cadence, MVP scoping, edge cases, performance budget, error handling at scale, design system governance, or any architectural-design question. Trigger on accessibility questions, "is this ready to ship," "what about the edge case where," design reviews, MVP scoping, "we have too many opinions on this." Framework-agnostic. Routes the model to the right process or robustness principle in this plugin.

Apply the principle of avoiding the Scaling Fallacy — the assumption that a system that works at one scale will work at a different (smaller or larger) scale. Use when scaling a feature from prototype to production, designing for an unfamiliar user volume, evaluating whether a process that works for 10 users will work for 10,000, or planning a launch in a much larger market. Two distinct kinds: load assumptions (will it handle the volume?) and interaction assumptions (will users behave the same way?). Both need testing at the actual scale.

Use this skill whenever the design will encounter conditions that can't be fully predicted at design time — load spikes, edge-case content, real-world variability, hardware variation, third-party flakiness, or any "what if" scenario. Trigger when scoping performance budgets, designing for content extremes, picking infrastructure capacity, designing error-handling, or planning for the long tail of users with unusual setups. Factor of Safety is one of the foundational principles in 'Universal Principles of Design' (Lidwell, Holden, Butler 2003) — also called "factor of ignorance" because the size of the safety factor is proportional to how much you *don't* know.

Use this skill when the question is whether assistive technologies — screen readers, voice control, switch devices, refreshable braille displays — can reliably interpret your UI. Trigger when picking between semantic HTML and a custom-built component, when reaching for ARIA, when designing live regions for dynamic content (toasts, validation, search results), or when reviewing a UI built largely from `<div>` elements. Covers WCAG Principle 4 (Robust). Sub-aspect of `accessibility`; read that first if you haven't already.

Use this skill when the question is whether users can *operate* a UI — keyboard, switch device, voice, screen-reader gestures — not just by mouse or touch. Trigger when designing keyboard navigation, focus management for modals/menus/popovers, drag-and-drop with alternatives, motion-heavy interactions, or any flow that asks the user to do something. Covers WCAG Principle 2 (Operable). Sub-aspect of `accessibility`; read that first if you haven't already.

Apply treatment strategies for identified weak links — fix, eliminate, buffer, replicate, or communicate. Use when you've identified a weakest link and are deciding what to do about it. Each treatment has different costs, benefits, and contexts where it's right. The choice depends on whether the weak link is necessary, whether it's fixable, what alternatives exist, and what timeline the fix can realistically follow.

Prune accumulated complexity from a product — features, options, settings, code paths that no longer earn their place. Use when auditing a mature product, reducing surface area, simplifying complex workflows, or evaluating whether to remove low-usage features. Pruning is harder than adding because users (often a small but vocal minority) resist removal even when usage data justifies it. The skill is identifying what to prune, deciding how, and managing the transition.

Verify and design for load scaling — data volume, transaction volume, request rate, and user count. Use when sizing infrastructure, choosing data structures, designing pagination and lazy-loading patterns, evaluating dependencies' rate limits, or load-testing before launch. Most scaling failures are load failures: a system that handled X requests/second can't handle 10X. The skill is anticipating the load the system will see and designing or testing for it deliberately.

Use this skill when the question is whether users can *perceive* the content — see it, hear it, or feel it — regardless of impairment. Trigger when designing color systems, picking text sizes, building image-heavy surfaces, working with video/audio, designing for low-vision users, or running an accessibility audit. Covers WCAG Principle 1 (Perceivable). Sub-aspect of `accessibility`; read that first if you haven't already.

Use this skill when deciding what to prototype, what fidelity to use, and when to stop prototyping and ship. Trigger when planning research, scoping a design phase, or facing pressure to "stop prototyping and just build it." Sub-aspect of `prototyping`; read that first.

Identify when two design options are functionally equivalent so the razor can be applied. Use when comparing design alternatives, evaluating whether two implementations of a feature actually produce the same outcome, or recognizing that a complex solution doesn't earn its place against a simpler one. Most design debates involve actual tradeoffs; the razor only cuts when the alternatives genuinely produce equivalent results. The skill is identifying equivalence honestly rather than rationalizing complexity.

Apply methods for finding the weakest link in a workflow, system, or feature set. Use when planning a redesign, prioritizing engineering or design investment, auditing a product for quality issues, or beginning any improvement effort. Several methods exist (funnel analysis, journey mapping, failure-mode enumeration, support-pattern review, direct user observation); each surfaces different kinds of weakness, and combining them gives the clearest picture.

Use this skill when the question is whether users can *understand* the UI — predict its behavior, recover from errors, comprehend its labels and copy. Trigger when writing form labels and error messages, when designing flows with surprising state changes, when picking microcopy for the destructive moments, or when reviewing a UI that "works correctly but confuses people." Covers WCAG Principle 3 (Understandable). Sub-aspect of `accessibility`; read that first if you haven't already.

Use this skill when picking the appropriate prototype fidelity for an iteration cycle — sketches vs. wireframes vs. clickable Figma vs. code prototypes vs. production beta. Trigger when planning a research session, when a project is over- or under-investing in prototypes, or when the prototype fidelity is mismatched to the question being asked. Sub-aspect of `iteration`; read that first.

Use this skill when designing UI to survive content extremes — long names, big numbers, multi-line addresses, missing images, internationalized strings, dense data. Trigger when reviewing a design against worst-case content, when bug reports show layouts breaking on real data, or when picking content limits and validation rules. Sub-aspect of `factor-of-safety`; read that first.

Use this skill when planning capacity, redundancy, graceful degradation, or recovery for systems that must keep working under stress — performance budgets, dependency failure handling, retry logic, error budgets, infrastructure capacity. Trigger when scoping infrastructure, designing error-handling architecture, planning for failure modes, or reviewing reliability incidents. Sub-aspect of `factor-of-safety`; read that first.

Use this skill when reviewing where in the project lifecycle iteration is happening — desirable iteration during design vs. costly rework during development. Trigger when a project keeps slipping due to "design changes during build," when scoping how much design work to do before engineering begins, or when retrospectives reveal that issues were caught too late. Sub-aspect of `iteration`; read that first.

Verify and design for user-base scaling — broader audiences, more diverse use cases, more edge cases, behaviors that weren't anticipated. Use when launching to a new market, scaling from beta to GA, expanding from one team to a company, or any context where the user population is growing or changing. Interaction scaling is often harder than load scaling because it surfaces design assumptions that worked for the original audience but fail for a broader one.

Use this skill when picking which kind of prototype to build for the question at hand — concept (exploratory), throwaway (testing one specific aspect), or evolutionary (incremental toward final). Trigger when planning a research method, when scoping a technical spike, or when deciding whether an MVP should evolve or be thrown away. Sub-aspect of `prototyping`; read that first.