Workflow and scope
Tesler's Law
When a task is complicated, decide who should handle each part and how mistakes can be corrected.
The idea in plain language
What it means.
Tesler's formulation asks whether the user, application developer or platform developer will handle a task's inherent complexity. It is a useful design question rather than a measurable conservation law. Automation can take work off the screen while moving decisions into defaults, integrations and maintenance.
Evidence and interpretation
What supports it.
A design heuristic documented by Larry Tesler. It does not prove that every existing step is necessary or that complexity is a fixed quantity across different product scopes.
From principle to interface
Where you could use it.
Proposed applications, not tested outcomes. The expected effects are hypotheses to check with realistic tasks and users.
Application 1
Import a spreadsheet
Suggest column mappings, show sample rows and require review before writing records.
Expected effect to test
The system handles repetitive matching while the user can inspect consequential choices.
Keep in view
A confident guess can still be wrong; preserve the source and make corrections possible.
Application 2
Set a time zone
Suggest the device time zone, display it beside scheduled times and let the person override it.
Expected effect to test
Most users avoid repetitive setup while travelers can choose the right interpretation.
Keep in view
Do not silently treat a device setting as proof of the person's intended location.
Turn the idea into a check
Use it deliberately.
- Identify the actual requirement behind each difficult step.
- Document defaults and the decisions automation makes.
- Design inspection, correction and failure recovery alongside the happy path.
Where the rule gets complicated
Keep the limits attached.
- Scope reduction can remove work; this is not a physical conservation equation.
- Hidden complexity can produce maintenance, privacy and security costs.
- Expert users may need direct controls that a simplified workflow conceals.
A named principle does not settle an accessibility requirement, prove a conversion lift or replace testing the particular interface.
Application and implementation boundaries
What the application check shows.
The import example disclosed a suggested mapping before changing its synthetic counter. It demonstrated an inspection step, not a real import or a conservation law.
Methods: Local application example. A completed check covers the stated sample; it is not a safety certification.
- Target
- Original IonBin synthetic interface example; no external product or human-participant study.
- Version or capture
- 2026-10-19 local fixture
- Integrity scope
- SHA-256 f85d1056afd667225a1e0364edfb8f25b4693ffa7b2b8c7d7af5b92338b85ee4 identifies the exact HTML fixture only.
Test conditions
- 155.0.8059.82 Chromium; fresh context with all network requests blocked.
- Synthetic inputs, memory-only state, reduced-motion preference, 1280px and 320px viewports.
Individual checks and observations
Import before review
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: Import was disabled until its mapping preview was requested.
Mapping disclosed
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: Preview revealed the suggested mapping and two-row count without committing.
Import confirmed
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: Explicit confirmation changed the synthetic counter only.
Security findings and boundaries
Review of the local example’s stated interaction boundaries; no backend, authentication, production permissions or external service was exercised.
Practical advice · caution
Automation must expose consequential assumptions
Real imports need server-side validation, scoped credentials, authorization and rollback. A visible preview alone cannot enforce those controls.
Practical caveats
- Let users inspect defaults and correct mappings; preserve source data until the result has been verified.
What remains untested
- This checks an authored application example, not the truth, effect size or generality of the named principle.
- No users, assistive-technology participants, physical devices or production task outcomes were evaluated.
Security limits
- The example has no real authorization or persistence layer; its UI behavior cannot establish the security of a deployed workflow.
Evaluation sources
- Larry Tesler: The Law of Conservation of Complexity
Author's formulation and historical context.
Go to the source
Research and further reading.
- Larry Tesler: The Law of Conservation of Complexity
Author's formulation and historical context.
Related questions
More on workflow and scope.
Design heuristic
Parkinson's Law
Define the useful task and remove avoidable work. Do not manufacture urgency.
Design heuristic
Occam's Razor
Prefer a simpler adequate solution. Adequate still includes accessibility, clarity and recovery.
Design heuristic
Pareto principle
Find where effort has the greatest measured effect. Treat 80/20 as a prompt to investigate, not a fact about your product.