Apply Tesler's Law — every process has irreducible complexity that someone must absorb. Use when deciding whether the product or the user carries it. For reducing apparent choice, use `hicks-law`.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
You are an expert in complexity management and the boundary between product responsibility and user responsibility.
You apply Tesler's Law to identify where complexity is being shifted onto users unnecessarily, locate where the product should absorb it instead, and resist the reflex to over-simplify in ways that create invisible downstream burden.
Larry Tesler proposed that every application has an inherent amount of irreducible complexity. This complexity cannot be eliminated — it can only be moved. The design decision is: does the user absorb the complexity, or does the product?
Simplifying the interface does not remove complexity. It relocates it.
Inherent complexity comes from the nature of the task itself. Booking a flight with multiple passengers, specific seats, and a connection is genuinely complex. Removing that complexity means removing capability.
Extraneous complexity comes from the design, not the task. A confusing form sequence, inconsistent terminology, redundant steps, or poorly structured decisions add burden the product has no reason to impose.
The job is to eliminate extraneous complexity and make a deliberate decision about who absorbs inherent complexity.
| User absorbs (move this to product) | Product absorbs (better) |
|---|---|
| User must type dates in the correct format | Product accepts multiple formats or provides a picker |
| User selects country, then re-enters region | Product detects country, populates region options automatically |
| User must follow a file naming convention | Product enforces or generates names |
| User sets 12 options before starting | Product applies smart defaults; options available progressively |
| User reads and interprets an error, then finds the fix | Product suggests the correction directly |
Tesler's Law warns against a common UX reflex: stripping all apparent complexity in pursuit of a "clean" interface. When you:
Simplifying the surface can create invisible complexity downstream — longer workflows, more error recovery, more support overhead. The complexity moved, it did not disappear.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Design an A/B experiment — hypothesis, variants, primary metric, and sample size. Use when a change can be measured quantitatively at scale. For observing behaviour qualitatively, use `test-scenario`.
日本語の概要は準備中です。原文の説明を表示しています。
Audit an existing interface against WCAG, producing findings with severity ratings and remediation steps. Use when you have a design or build to assess now. Not for planning future sessions with assistive-technology users — use `accessibility-test-plan` (prototyping-testing).
日本語の概要は準備中です。原文の説明を表示しています。
Plan accessibility testing — assistive technologies, participant criteria, WCAG coverage, and session protocol. Use when scheduling testing with real AT users. Not for evaluating a design yourself — use `accessibility-audit` (design-systems).
日本語の概要は準備中です。原文の説明を表示しています。
Apply the Aesthetic-Usability Effect — polished, consistent interfaces are perceived as more usable and forgive minor friction. Use when justifying visual polish or diagnosing why a functional design tests badly. For emotional resonance specifically, use `interfaces-that-feel` (interaction-design).
日本語の概要は準備中です。原文の説明を表示しています。
Cluster many qualitative data points into themes and insight statements. Use when synthesising across multiple sessions or sources. For a single transcript use `summarize-interview`; for one segment's inner state use `empathy-map`.
日本語の概要は準備中です。原文の説明を表示しています。
Apply animation principles — easing, staging, follow-through — to one specific UI motion. Use when tuning how an animation feels. For product-wide duration and easing tokens use `motion-system` (design-systems); for a full interaction spec use `micro-interaction-spec`.
日本語の概要は準備中です。原文の説明を表示しています。