Когнитивное трение · Конспекты по бизнес-анализу

Главные идеи#

Что это#

Термин Купера — когнитивное трение (cognitive friction; в русском издании книги — «когнитивное сопротивление») — описывает усилие, которое ум тратит, чтобы разобраться в сложном наборе правил, меняющихся вместе с ситуацией. Как и физическое трение, в малых количествах оно безвредно, но с ростом его цена резко увеличивается. В отличие от физического трения, его нельзя измерить инженерными инструментами. Оно вполне реально — просто не поддаётся такому измерению.

Источник: элементы управления, смысл которых зависит от состояния#

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

Его мысль об эргономике: специалисты традиционно оптимизируют устройство под глаза и пальцы пользователя (видна ли кнопка, можно ли до неё дотянуться), а не под его ум. В результате появляются продукты, физически удобные, но умственно утомительные. Крайним случаем Купер считает даже гиперссылку: её единственное назначение — куда-то вас перенести, а содержимое на другом конце может меняться независимо от ссылки.

Проектирование взаимодействия и проектирование программы#

Купер утверждает, что любое программирование включает проектные решения, и проводит границу по тому, кого они затрагивают:

Проектирование взаимодействия (interaction design) охватывает решения, которые напрямую влияют на конечного пользователя: поведение, назначение, информацию и представление.
Проектирование программы (program design) охватывает всё остальное, например язык и внутреннюю архитектуру. Оно становится вопросом взаимодействия, когда технический выбор меняет что-то заметное пользователю, например время отклика.

Купер сознательно избегает слова «интерфейс». Оно предполагает, что код находится с одной стороны, люди — с другой, а между ними лежит тонкий слой, который и отвечает за нужды пользователя. На практике это позволяет программистам откладывать пользователя на потом («интерфейс появится, когда я закончу»), поэтому проектирование для пользователя делается в последнюю очередь и наспех, если делается вообще.

Недостаточное проектирование — тоже проектирование#

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

Как применять#

Для бизнес-аналитика главный урок — последний: если ваши требования оставляют поведение открытым, его спроектирует кто-то другой.

Описывайте поведение, а не только данные. Для каждой функции, с которой работает пользователь, укажите, что он видит, что делает каждый элемент управления и что происходит при успехе и при неудаче.
Разберите открытые решения. Отделите решения о взаимодействии, которым нужны мнение пользователей и проверка по персонам, от решений о программе, которые может принять команда. У каждого решения о взаимодействии должен быть ответственный.
Ищите элементы управления, зависящие от состояния. В прототипах ищите кнопки, клавиши или жесты, действие которых зависит от состояния, за которым пользователь может не следить.
Записывайте заметную пользователю производительность как требования. Если время отклика меняет то, как люди работают, это требование к взаимодействию, а не техническая деталь.
Планируйте проектирование взаимодействия до разработки. Не соглашайтесь на план, где «интерфейс» — последний этап.

Чек-лист для ревью#

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

Пример#

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

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

Подводные камни#

Рассчитывать, что разработчики «сделают интуитивно понятно» → запишите поведение.
Судить об удобстве использования только по числу кликов и размеру кнопок → учитывайте и состояния, которые пользователь должен держать в голове.
Считать интерфейс слоем, который добавят позже → планируйте проектирование взаимодействия вместе с требованиями.

Источники и что почитать#

A. Cooper. The Inmates Are Running the Asylum. Sams, 1999. Рус. изд.: А. Купер. Психбольница в руках пациентов. СПб.: Символ-Плюс, 2004. Гл. 2.