Неработающие кнопки

Кнопки, которые активны в любой ситуации, давно уже вошли в число «лучших практик” UX-дизайна, однако до сих пор в интерфейсах встречаются и неактивные кнопки. В 2021 году коллеги из «Открытия» попросили меня подготовить презентацию с теоретическим обоснованием концепции "кнопки должны быть всегда активны”. Удобно иметь под рукой аргумент, чтобы предъявить менеджеру продукта. Теперь я оформил презентацию в виде статьи и надеюсь, что она будет полезна как продуктовым дизайнерам, так и менеджерам.

Кнопка нужна для совершения некоторого действия. Если кнопка находится в нерабочем состоянии, то совершить действие невозможно. Блокировать действие уместно тогда, когда недостаточно условий (или данных) для совершения этого действия.

Программа может ожидать данные как от пользователя, так и от собственных компонентов (сервера, локального хранилища, результатов локальных вычислений).

Пользователь может не предоставить данные:

Компоненты программы могут не предоставить данные:

Таким образом, существует по меньшей мере 6 возможных объяснений, почему действие заблокировано.

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

Единственный для пользователя вариант избежать негативных эмоций – не заметить неактивную кнопку вовсе. Именно такой паттерн и применяют дизайнеры: делают неактивные элементы по возможности незаметными.

Но это не сильно помогает. Давайте посмотрим на такую компоновку и сравним варианты:

Активная кнопка:

Неактивная кнопка:

Неактивная кнопка не может порадовать пользователя ничем хорошим. Она нужна только дизайнеру, чтобы заранее зарезервировать место для активной кнопки. Дизайнер-то себе работу облегчил, дизайнер молодец. А вот о пользователе не подумал.

Пусть кнопка будет всегда активна. Пользователь в любое время может попытаться совершить действие. Если попытка отклонена, интерфейс сообщит о причине – укажет на недостающие данные (например, выделит красным цветом). Пользователю не придётся гадать, что именно он (или программа) делает не так.

Хорошо, если удастся спрятать кнопку в самый низ, под скроллинг – никто не увидит активна она или нет. А когда пользователь заполнит все данные и долистает донизу, тогда и увидит активную кнопку. Соблюдается принцип своевременности, всё классно. Давайте сравним варианты.

Кнопка на виду:

Кнопка скрыта под скроллингом:

Действительно, за второй вариант набирается больше аргументов. Значит, лучше прятать кнопку под скроллингом. Но в реальности пользователи не ведут себя идеально. Некоторые пролистывают страницу вниз, не заполнив данные. Если такой пользователь увидит неактивную кнопку, перед ним встанет вопрос: почему кнопка не работает. Как мы определили выше, ответов может быть как минимум 6. Это перебор. Так что даже спрятанная внизу кнопка должна быть активной.

С тем, что кнопка должна быть всегда активна, мы разобрались. Теперь определим правила расположения этой самой активной кнопки. Аргумент “кнопка отнимает пространство” перестаёт работать на страницах, где мало контента. Поэтому баланс преимуществ и недостатков изменяется в зависимости от содержимого страницы. Стремясь к перевесу преимуществ над недостатками, мы придём к двум разным правилам: мало контента – кнопка видна, много контента – кнопка скрыта под скроллингом.

Мало контента:

Много контента:

Мне, как дизайнеру, проще сделать одну универсальную компоновку: привязать кнопку к нижнему краю экрана и всегда показывать её поверх контента (такой вариант я показывал выше). И программисту проще сделать одну компоновку. Дизайнер с программистом невольно путают простоту интерфейса и простоту создания интерфейса, от чего выдумывают, будто их простое решение упростит жизнь также и пользователю. Но аргументы за универсальную компоновку легко опровергнуть. Пользователю удобно всегда нажимать в одно и то же место? Нет, пользователь нажимает во множество разных мест на экране, ему всё равно. Пользователь хочет видеть главную кнопку в одном и том же месте? А он и увидит в том же месте, когда пролистает страницу до конца. И так далее.

В итоге, всё говорит в пользу адаптивного правила: мало контента – кнопка видна, много контента – кнопка скрыта под скроллингом.

Иногда неактивная кнопка всё же нужна. Если кнопка вызывает необратимое деструктивное действие, полезно предотвратить её случайное или необдуманное нажатие. Мы не стремимся облегчить действие, о котором пользователь, вероятно, пожалеет. Прежде чем выстрелить себе в ногу, пользователь должен потрудиться снять пистолет с предохранителя.

В начале статьи я писал про “лучшие практики”. У меня есть отдельная статья «Нет никаких UX-трендов», и я собираюсь написать ещё одну статью, где критически рассмотрю “лучшие практики”. Изучая тренды, я пришёл к выводу, что существует только один тренд – технический прогресс. UX-дизайнер лишь использует новые технологии, чтобы приблизить опыт использования цифровых продуктов к реальному опыту, к заложенному природой механизму восприятия человека. То же с лучшими практиками – они хороши лишь тем, что приближают цифровой опыт к реальному. Приближение к реальности – и есть единственная лучшая практика. В случае с кнопками напрашивается простая аналогия из окружающего мира: если что-то не работает, значит оно сломано. Если сущность не реагирует на касание, значит она умерла.

Итак, по итогам вышесказанного следует придерживаться следующих правил:

Если хотите посмотреть больше реальных кейсов продуктового дизайна – заходите ко мне на manwe.ru