Что ты заставляешь держать в руках: когнитивная нагрузка

Форма оплаты просит код из СМС. Ты выходишь из приложения прочитать его, возвращаешься — поле пустое, и три поля выше тоже. Начинаешь заново. В этот раз сначала заучиваешь код, но к моменту, когда форма загрузилась, ты уже не уверен, кончался он на 4 или на 7.

Никто не проектировал это из жестокости. Каждое решение было локально разумным: очищать форму ради безопасности, держать код коротким, не захламлять экран. Вместе они собрали задачу, которая требует держать что-то в голове, а держать что-то в голове — ровно то, что человек умеет хуже всего.

Верстак заполняешь не ты

В сфере «Как учиться» механика разобрана подробно: рабочая память — крошечный верстак примерно на четыре элемента, и всё, чем ты жонглируешь прямо сейчас, должно на нём поместиться. Этот факт не меняется, когда человек садится перед твоим продуктом. Меняется другое — кто именно кладёт вещи на верстак.

Теория когнитивной нагрузки Джона Свеллера делит общую нагрузку на части, и для дизайнера это деление на редкость практично:

Внутренняя нагрузка — собственно сложность задачи. Выбрать рейс в поездку с тремя ограничениями действительно трудно. Это проблема пользователя, и она законна: за ней он и пришёл.

Внешняя нагрузка — всё, что подача добавляет сверху. Куда уехала кнопка, что означает это слово, какая из двух панелей сейчас активна, что нужно помнить с предыдущего шага. Вот это — твой вклад.

Работа делится ровно по этой линии: свести внешнюю нагрузку к нулю, чтобы весь верстак остался задаче, которая у человека есть на самом деле. Интерфейс не обязан быть интересным. Он обязан оставлять место.

Каждая ячейка, занятая интерфейсом, — ячейка, которая не достанется задаче.

Узнавать легче, чем вспоминать

Из всего списка это правило с самой высокой отдачей, и оно же шестое в эвристиках юзабилити Якоба Нильсена: снижай нагрузку на память, делая объекты, действия и варианты видимыми.

Вспоминание — извлечь из ничего — медленно, затратно и ненадёжно. Узнавание — увидеть и понять — почти бесплатно. Следствие для дизайна простое: если человеку нужна информация, клади её туда, где она нужна, а не туда, где ей логично лежать.

Поищи этот узор в своих продуктах:

Экран подтверждения, который не показывает введённый адрес, — приходится возвращаться и проверять.
Код, который надо принести из другого приложения в поле, очищающееся при потере фокуса (вставь его сам; ещё лучше — прочитай и заполни).
Горячая клавиша, упомянутая один раз в приветственном туре и больше никогда.
Фильтр, который применён, но нигде не перечислен, — про него забывают и считают, что данные врут.
Панель настроек, где подписи понятны только тому, кто помнит, как то же самое называлось на предыдущем экране.

Каждое спрятанное меню — ставка на то, что люди помнят о его существовании. В основном не помнят.

Закон Хика без искажений

Популярная версия звучит как «меньше вариантов — быстрее решение». Настоящий результат — Уильям Хик, 1952, и Рэй Хайман, 1953 — уже и полезнее: время решения растёт с логарифмом числа равновероятных альтернатив.

Логарифм тут важен. Переход от 2 вариантов к 4 стоит примерно столько же, сколько от 4 к 8 и от 8 к 16. Варианты не одинаково дороги — дороги первые несколько.

А «равновероятных» важно ещё сильнее. Меню из сотни пунктов — это не выбор из ста, если оно разбито на шесть подписанных разделов: это выбор из шести, а потом из пятнадцати. Такое дешевле и плоской сотни, и популярного совета «просто сократи до семи».

Отсюда последовательность: сначала сгруппировать, потом расставить приоритеты, и только потом удалять. Новички начинают с удаления — и именно этот ход чаще всего ломает то, что кому-то было нужно.

Самое цитируемое предостережение — исследование джемов Шины Айенгар и Марка Леппера (2000): дегустационный стол с 24 сортами привлекал больше прохожих, чем с 6, но маленький выбор продавал примерно в десять раз лучше. Позднейшие воспроизведения дали смешанную картину, так что размахивать этим как законом не стоит, — но направление держится там, где выбор труден, а сравнение дорого, то есть на большинстве когда-либо сделанных страниц с тарифами.

Закон Фиттса и где он кусается

Пол Фиттс, 1954: время попадания в цель растёт с расстоянием и падает с размером. Звучит как формула про мышку, а на деле это причина существования нескольких повседневных правил дизайна.

Главным действиям положено быть крупными. Не ради акцента — ради скорости. То, что делают чаще всего, должно быть проще всего нажать.

Края и углы бесконечно велики. Курсор упирается в границу экрана, поэтому цель, прижатая к ней вплотную, практически непромахиваемая — отсюда и место жительства строк меню и доков.

На телефоне расстояние — это большой палец. Дотягивание идёт по физической дуге, а не по прямоугольнику. Низ экрана удобен, верхние углы — нет, и поэтому за последнее десятилетие навигация в мобильных уехала вниз.

Мелкие цели — провал доступности, а не стиль. WCAG 2.2 задаёт минимум 24×24 CSS-пикселя; рекомендации Apple говорят о 44 пунктах, Google — о 48 dp. Ниже этого ты проектируешь не компактный интерфейс, а промах.

Никогда не ставь разрушительное действие рядом с частым. Закон Фиттса гарантирует периодический перелёт. «Удалить» рядом с «Сохранить» — это не риск, это расписание.

Закон Теслера: сложность не исчезает

Ларри Теслер, посвятивший этому карьеру, сформулировал принцип сохранения сложности: у любого процесса есть неустранимый объём сложности, и вопрос только в том, кто её принимает на себя — пользователь, дизайнер или инженер.

Это превращает «упростить» из лозунга в решение. Дату можно ввести одиннадцатью способами. Кто-то должен с этим справиться: либо пользователь, выучив твой формат и получая выговор за отклонения, либо код, разобрав все одиннадцать. В телефоне бывают пробелы, дефисы и коды стран. У адреса есть индекс, который можно вывести самому. Файл можно сконвертировать, а не отвергнуть.

Каждый такой случай — небольшой объём инженерной работы против маленького налога с каждого пользователя навсегда. Сделка почти всегда выгодна, и почти всегда её обсуждают так, будто это запрос на функциональность, а не решение дизайнера.

Раскрывай постепенно и выставляй умолчания

Две механики позволяют обслуживать сложные продукты без сложного первого экрана.

Постепенное раскрытие — показать частый путь, остальное держать в одном осознанном шаге. Не спрятать, а отложить, с видимым входом. Проверка хорошего раздела «Дополнительно»: может ли тот, кому он нужен, предсказать, что раздел существует.

Умолчания — самый мощный и наименее обсуждаемый инструмент в области. Умолчание почти никто не меняет, а значит, тот, кто их выставил, спроектировал поведение большинства. Каждое умолчание — решение, принятое за тысячи людей, которые никогда не заметят, что это было решение. Ставь их под частый случай, а не под самый безопасно звучащий, и никогда не ставь умолчание, которое стоит человеку денег или приватности, которые он не собирался тратить.

На практике

Посчитай решения на экране. Пройди и выпиши каждую точку, где человек должен выбрать или вспомнить. Больше пяти для рутинной задачи — у тебя проблема с нагрузкой, как бы чисто это ни выглядело.

Показывай введённое. На каждом подтверждении, сводке и ошибке отображай сами значения. Одна эта привычка убирает удивительную долю беготни туда-обратно.

Удали одно поле. В любой форме возьми поле, в котором ты меньше всего уверен, и спроси, что будет, если его вывести, подставить по умолчанию или спросить позже. Повторяй, пока удаление следующего не станет реально дорогим.

Группируй прежде, чем сокращать. Если список слишком длинный, не режь его первым делом — разбей на подписанные разделы и посмотри, не исчезла ли проблема. Обычно исчезает.

Померь главную цель. Она крупная? Она рядом с большим пальцем? Она на безопасном расстоянии от разрушительного? Три вопроса, тридцать секунд.

Переноси сложность в код. Каждый раз, когда собираешься написать подсказку про формат — «ДД.ММ.ГГГГ», «без пробелов», — спроси, не может ли парсер просто это принять. Такая подсказка — налоговое уведомление.

Проверь себя

Закрой статью и ответь своими словами:

В чём разница между внутренней и внешней нагрузкой и какую из них убираешь ты?
Почему «узнавание вместо вспоминания» — правило с самой высокой отдачей?
Что логарифм в законе Хика меняет в совете «меньше вариантов»?
Почему группировка выигрывает у удаления и в каком порядке нужно работать?
Назови три практических следствия закона Фиттса, которые ты можешь применить к экрану сегодня.
По закону Теслера, кто принимает на себя сложность одиннадцати форматов даты и как это решать?
Почему умолчания — решение дизайнера, а не техническая деталь?

Коротко

Рабочая память держит около четырёх элементов. Каждый занятый интерфейсом — тот, что не достанется настоящей задаче.
Внутренняя нагрузка — это задача, внешняя — то, что добавляет подача. Твоя работа — свести вторую к нулю.
Узнавание сильнее вспоминания: клади информацию туда, где она нужна, а не где ей место. Спрятанное меню — ставка на чужую память.
Закон Хика логарифмический и предполагает равновероятные варианты. Сначала группировать, потом приоритизировать, удалять — последним.
Закон Фиттса: главные цели крупные, края бесплатны, палец дотягивается до низа, минимум 24–48 px, «удалить» никогда не рядом с «сохранить».
Закон Теслера: сложность сохраняется. Вопрос лишь в том, принимает её пользователь или код, — обычно должен код.
Постепенное раскрытие откладывает, а не прячет. Умолчания проектируют поведение большинства, поэтому выставляй их намеренно.