Простыми словами
Простой экран не означает, что сама задача стала простой: часть работы могла просто переехать от пользователя внутрь программы. Например, автозаполнение убирает ручной ввод, но требует распознавания, проверки и обработки ошибок на стороне системы. Поэтому полезно спрашивать не «как убрать сложность вообще», а «где её безопаснее разместить».
Механизм действия
Сначала проверяют, есть ли исходное условие из определения. Затем смотрят, как оно влияет на структуру компонентов, потоки данных, ограничения и действия участников. Если эту связь не удаётся наблюдать, принцип не стоит использовать как готовое объяснение.
Пример в работе
В задаче «Навигация» сразу применить привычное решение и назвать происходящее «Закон Теслера», не проверив, действительно ли работает этот механизм. Так можно улучшить один симптом и пропустить основную причину.
Использовать «Закон Теслера» как гипотезу: сначала определить границы ситуации и исходное состояние, затем менять только то, что связано с проверяемым механизмом, и смотреть на результат.
Ограничения
Сложность можно перераспределять между пользователем, продуктом и разработкой, но не существует доказанного постоянного общего объёма сложности для любой задачи.
Источник
Larry Tesler, “The Law of Conservation of Complexity (Tesler’s Law)”, ca. 1984.