Process & Robustness

Plugin process-and-robustness-principles from marketplace universal-design-principles in Deibler/universal-design-principles. Commands read from the repo's manifest — 1 month ago.

Skills (24)

• accessibility-operable

  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 interactio

• accessibility-perceivable

  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 acce

• accessibility-robust

  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 regi

• accessibility-understandable

  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 m

• accessibility

  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, key

• factor-of-safety-content-stress

  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 conten

• factor-of-safety-failure-margin

  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

• factor-of-safety

  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 e

• iteration-design-vs-development

  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,

• iteration-prototype-fidelity

  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 fidel

• iteration

  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

• ockhams-equivalent-designs

  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 on

• ockhams-feature-pruning

  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 u

• ockhams-razor

  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 t

• process-router

  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

• prototyping-concept-throwaway-evolutionary

  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

• prototyping-when-and-what

  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.

• prototyping

  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 featur

• scaling-fallacy

  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

• scaling-interaction-assumptions

  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 changin

• scaling-load-assumptions

  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 ar

• weakest-link-identification

  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-

• weakest-link-treatment

  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 w

• weakest-link

  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 ste

Similar plugins