Что произошло
В 1966 году IBM выпустила язык программирования PL/I — амбициозную попытку создать универсальный язык, объединяющий возможности Fortran, COBOL и ALGOL. Язык получился мощным. И чудовищно непредсказуемым.
PL/I был переполнен неявными преобразованиями типов, автоматическими значениями по умолчанию и конструкциями, которые делали не то, что подсказывала интуиция. Переменная могла изменить тип без предупреждения. Оператор, выглядящий как арифметика, мог выполнить строковую операцию. Программист писал одно, компилятор делал другое — и оба считали себя правыми.
Реакция сообщества была предсказуемой: раздражение, ошибки и убеждение, что так быть не должно. Именно в PL/I Bulletin в 1967 году впервые прозвучал термин «Law of Least Astonishment» — закон наименьшего удивления. Ирония была в том, что название родилось как диагноз болезни, а не как рецепт здоровья.
Пять лет спустя, в 1972 году, принцип получил академическую формулировку. Бержерон, Гэннон, Шектер и Томпа опубликовали работу «Systems Programming Languages», в которой записали:
«Every construct in the system should behave exactly as its syntax suggests. Widely accepted conventions should be followed whenever possible.»
«Каждая конструкция в системе должна вести себя в точности так, как подсказывает её синтаксис. Общепринятые соглашения следует соблюдать всюду, где это возможно».
Формулировка выглядит очевидной. Но очевидность — обманчивое свойство хороших принципов. Они кажутся банальными до тех пор, пока не нарушены.
Контекст эпохи
1960–70-е годы — золотое время проектирования языков программирования. Каждый университет, каждая крупная компания создавала свой язык, свой синтаксис, свою философию. Стандартов взаимодействия с пользователем — программистом — не существовало. Каждый автор языка решал сам, как должен выглядеть оператор присваивания, как работают циклы, что происходит при делении на ноль.
Программист, переходящий с одного языка на другой, оказывался в положении путешественника, попавшего в страну, где зелёный сигнал светофора означает «стоп». Знакомые символы вели себя незнакомо. Равенство могло быть присваиванием. Точка с запятой могла быть разделителем в одном языке и терминатором в другом. Каждый такой сюрприз стоил часов отладки.
Принцип наименьшего удивления возник как ответ на этот хаос. Не как теоретическая конструкция, а как крик практиков: хватит удивлять. Если в большинстве языков = означает присваивание, не делайте из него сравнение. Если программисты привыкли, что массивы начинаются с нуля, не начинайте их с единицы без веских причин.
В 1984 году Майк Каулишоу, создатель языка REXX для IBM, сформулировал принцип ещё точнее в статье «The Design of the REXX Language». REXX проектировался с нуля как язык, который не должен удивлять. Каулишоу описал свой подход: при любом сомнении в поведении конструкции следует выбирать вариант, который ожидает большинство пользователей, — даже если он менее элегантен с точки зрения внутренней архитектуры.
В 2003 году Эрик Реймонд включил принцип в свою книгу «The Art of Unix Programming» под названием «Rule of Least Surprise» — правило наименьшего сюрприза. Реймонд поднял его от уровня синтаксиса отдельного языка до уровня проектирования целых систем: интерфейсы командной строки, файловые форматы, API — всё должно подчиняться ожиданиям того, кто будет с этим работать.
Значение для UX
Принцип наименьшего удивления родился в программировании, но его подлинный масштаб раскрылся в проектировании пользовательских интерфейсов. Здесь ставки выше: программист может прочитать документацию, а пользователь не будет и не должен.
Предсказуемость — основа доверия. Человек формирует ожидания на основе предыдущего опыта. Он уже знает, что красный крестик закрывает окно. Что свайп вниз обновляет ленту. Что корзина — это место, откуда можно достать обратно. Каждое нарушение этих ожиданий — микротравма. Одна микротравма — пустяк. Десять — раздражение. Двадцать — удаление приложения.
Консистентность внутри системы. Если в одном разделе приложения свайп влево удаляет элемент, а в другом — открывает меню, пользователь неизбежно удалит то, что хотел отредактировать. Принцип наименьшего удивления требует: одинаковые жесты — одинаковые результаты. Везде. Без исключений.
Консистентность между системами. Пользователь приходит в новое приложение не с чистого листа. Он уже пользовался десятком других. Он ожидает, что Ctrl+Z отменит действие, что поиск будет в правом верхнем углу, что логотип вернёт на главную. Эти конвенции — не прихоть, а коллективный договор, нарушение которого ложится на совесть проектировщика.
Ментальные модели. Дон Норман в «Дизайне привычных вещей» (1988) описал разрыв между ментальной моделью пользователя (как он думает, что система работает) и концептуальной моделью разработчика (как она работает на самом деле). Принцип наименьшего удивления — это, по сути, требование совпадения этих двух моделей. Когда они расходятся, пользователь удивляется. Когда совпадают — он даже не замечает интерфейс. Он просто делает то, что хотел.
Иконический пример нарушения. В ранних версиях Microsoft Word кнопка «Закрыть» на панели инструментов закрывала документ, а не приложение. Кнопка «Закрыть» в заголовке окна закрывала приложение. Визуально они были похожи. Пользователи закрывали не то, что хотели. Тысячи несохранённых документов погибли от этого маленького удивления.
Принцип и эвристики Нильсена. Вторая эвристика Нильсена — «соответствие системы реальному миру» — прямое следствие принципа наименьшего удивления. Система должна говорить на языке пользователя, использовать знакомые концепции, следовать реальным конвенциям. Четвёртая эвристика — «единообразие и стандарты» — ещё одна грань того же принципа: пользователь не должен гадать, означают ли разные слова, ситуации или действия одно и то же.
Существует простой тест на соответствие принципу. Покажите человеку экран и спросите: «Что произойдёт, если нажать эту кнопку?» Если ответ совпадёт с реальным поведением — принцип соблюдён. Если не совпадёт — перед вами баг проектирования, даже если код работает безупречно.
Принцип наименьшего удивления не требует, чтобы интерфейс был примитивным. Он требует, чтобы интерфейс был честным. Чтобы каждый элемент делал ровно то, что обещает своим видом, положением и названием. Это одно из тех правил, которые невозможно соблюсти, не зная пользователя, — потому что «удивление» определяется не проектировщиком, а тем, кого удивили.
Связанные статьи
- Эвристики Нильсена — вторая («соответствие системы реальному миру») и четвёртая («единообразие и стандарты») эвристики — прямые следствия принципа наименьшего удивления.
- Дизайн привычных вещей, Дон Норман (1988) — концепция ментальных моделей объясняет, почему нарушение ожиданий вызывает ошибки: разрыв между тем, как пользователь думает, что система работает, и тем, как она работает на самом деле.
- Бритва Оккама (1300) — принцип простоты и принцип предсказуемости — союзники: чем проще система, тем меньше в ней мест, где можно удивить.
Из серии «История UX»:
- Закон Постела: принцип робастности (1989) — если закон Постела говорит «прощай ошибки пользователя», то принцип наименьшего удивления говорит «не провоцируй их». Два принципа работают в паре.
- Модель GOMS (1983) — GOMS предсказывает время выполнения задачи на основе выученных операций. Нарушение ожиданий ломает автоматизм и увеличивает время — модель это измеряет.
- Ментальная модель, Крейк (1943) — теоретический фундамент: человек строит внутреннюю модель системы и действует на её основе. Удивление — сигнал о том, что модель ошибочна.