teslers-law

Applies Tesler's Law to decide whether the product or the user absorbs irreducible complexity.

2.5k|358|Updated Mar 7, 2026
One-click install
npx skills add https://github.com/Owl-Listener/designer-skills --skill teslers-law
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: teslers-law
Source: https://github.com/Owl-Listener/designer-skills/tree/main/interaction-design/skills/teslers-law
Command: npx skills add https://github.com/Owl-Listener/designer-skills --skill teslers-law

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Interfaces often push irreducible complexity onto users through confusing forms, manual formatting demands, and cryptic errors, while over-simplification can hide complexity that resurfaces as downstream burden. This Skill helps you decide deliberately who should carry that complexity.

Core Features & Use Cases

  • Complexity Auditing: Distinguish inherent complexity (from the task itself) from extraneous complexity (from the design) before simplifying.
  • Burden Shifting Guidance: Identify where the product should absorb work users currently do, such as accepting multiple date formats, auto-populating regions, or enforcing file naming conventions.
  • Over-Simplification Warnings: Detect when hiding options or over-defaulting critical decisions creates invisible downstream cost in support volume, error recovery, or lost power-user control.
  • Use Case: When redesigning a checkout flow, audit each step to find decisions the product can make with smart defaults, then verify the removed complexity did not reappear as support tickets.

Quick Start

Ask the AI to apply Tesler's Law to audit a user flow and identify which steps the product should absorb instead of the user.

Frequently Asked Questions about teslers-law

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is Tesler's Law in UX design?

Tesler's Law states every application has irreducible complexity that cannot be eliminated, only moved. The design decision is whether the user absorbs that complexity or the product absorbs it through defaults, automation, and format tolerance.

How do I decide what complexity the product should absorb?

Audit each step of a flow and ask what decision the user is making and whether the product could make it without losing fidelity. Automate steps that need no user judgment and ask only what only the user knows.

When should I use Tesler's Law versus Hick's Law?

Use Tesler's Law when deciding who carries irreducible complexity in a process. Use Hick's Law when the problem is reducing apparent choice and decision time among presented options.

Can simplifying an interface make UX worse?

Yes. Hiding too many options makes power users hunt, over-defaulting removes control at critical moments, and removed complexity often reappears as longer workflows, error recovery, or support volume. Simplification relocates complexity rather than removing it.

How do I measure whether complexity reduction worked?

Measure outcomes such as error rate, time-on-task, abandonment, and support volume rather than counting visible interface elements. A cleaner UI that increases support tickets has moved complexity, not reduced it.