Аргумент в пользу правила 3-х кликов: пользователи будут разочарованы, если для выполнения своих задач потратят хотя бы на один клик больше. Правило часто используют для оценки стоимости взаимодействия с продуктом, но его поверхностная простота настораживает.
Беда в том, что это правило не было подтверждено данными ни в каких опубликованных исследованиях на сегодняшний день. Более того, исследование Джошуа Портера фактически опровергло его — уровень удовлетворенности не уменьшается с увеличением количества кликов для решения задачи.
Клики — не очень-то значимый показатель, и вот почему:
- Количество кликов зависит не только от дизайна, но и от сложности задачи, поэтому вывести единое адекватное их число невозможно.
- Не все клики одинаковы: за одними следуют секунды ожидания (например, если загружается новая страница), за другими — мгновенная загрузка контента (например, если листается галерея).
- Количество кликов неинформативно с точки зрения юзабилити — в реальном мире пользователи тупят, ошибаются и запутываются. Простой подсчет количества шагов в процессе упускает их реальные действия и лишает возможности улучшить их горький опыт.
Поэтому не стоит воспринимать правило 3-х кликов как непреложную истину при разработке сайтов, информационной архитектуры и навигации.
Происхождение правила 3-х кликов
Самая ранняя ссылка на правило 3-кликов (которое смог найти автор статьи) содержится в книге Джеффри Зельдмана 2001 года «Перенеси свой талант в Интернет», где тот упоминает эту концепцию, на тот момент уже распространенную среди сообщества веб-дизайнеров. Подтверждений правилу книга не содержит, вместо этого там приводится фраза: «Понятное дело, если вы не идиот, то согласны с тем, что юзеры движимы желанием всё делать быстро — если они не смогут найти искомое за 3 клика, они уйдут на другой сайт».
Да, исследования подтверждают, что пользователям действительно важна скорость выполнения задач в интернете, но это не значит, что можно делать такие голословные выводы.
Правило 3-х кликов вредит пользовательским интерфейсам
Одно из главных последствий правила — меню должно быть кратким и не содержать кучу уровней, чтобы найти информацию. Да, это разумно, но из-за этого шаблона проектировщикам интерфейсов приходится несладко: вместо одной информационной архитектуры (ведущей вглубь), они вынуждены везде ляпать другую (которая разрастается в ширину).
Дизайнеры, руководствуясь правилом, запихивают всё больше пунктов в меню верхнего уровня. Да, у меню с большим уровнем вложенности тоже есть проблемы с юзабилити (поиск нужного в нём требует больше времени), но меню с большим количеством подкатегорий на верхних уровнях занимает много места и сложно для пользователя.
Из-за этого многим дизайнерам приходится выбирать из двух зол: не более 3 кликов или не более 7 категорий в основной навигации. При этом эти правила не подтверждены исследованиями, по факту бесполезны и подталкивают дизайнеров к принятию компромиссных решений между одинаково плохим пользовательским опытом.
Чем заменить подсчёт кликов
Подсчет кликов — грубый способ оценки взаимодействия и эффективности задач, поскольку не учитывает когнитивные факторы. Пользователям иногда необходимо прочитать и понять длинный список параметров, выяснить, где они в настоящее время находятся на сайте, или оценить, сколько действий еще нужно предпринять, чтобы достичь своей цели. И это тоже имеет значение.
Для хорошей навигации важны не клики, а:
- понятные пункты меню с однозначными и знакомыми формулировками;
- хлебные крошки, показывающие текущее положение пользователей;
- мега-меню с несколькими уровнями информационной иерархии вместо каскадного меню, в котором проще всего запутаться и потерять результат поиска при случайном закрытии;
- ссылки на самое важное с точки зрения пользователя;
- целевые страницы для сложных маршрутов поиска (страницы с группами ссылок, изображениями или другими элементами, которые помогают с незнакомой терминологией и помогают ориентироваться между станицами той же категории);
- минимальное время загрузки — 3 клика, длящиеся вечность, хуже, чем 5 шустрых.
История о Троянском коне — это история о войне, и вполне неплохая метафора: во многих организациях с Agile так и происходит, подчас даже неосознанно. Только в этом случае греки не подсовывают коня и не делают вид, что уплывают — они работают на предводителей Трои.
Этическая дилемма вот в чём: стоит ли выдвигать Agile как способ решения всех проблем организации, если при этом получается, что результат будет не совсем не тем, за который лидеры готовы были платить?!
Взять хотя бы Скрам — в некотором смысле он стал троянским конем, убившим Agile. Сазерленд — один из разработчиков Скрама — продал его менеджерам под соусом, что тот «выполняет двойной объём работы за половину времени». Тоже песенка про белого бычка троянского коня.
«Троянцы» считают, будто Agile просто ускорит их водопадную модель. И считают они так, поскольку платят за конечный продукт — якобы можно получить бОльшую ценность за счет максимизации результата при наименьшем количестве работы (привет, Скрам) — вот только это не всегда даёт ощутимый профит (как гласит еврейская поговорка, «спасибо в карман не положишь»).
Некоторые компании всё ещё путают ценность Скрама: одни считают, что дело в «производительности» команд, другие — что дело в самих командах.
Греки из нашей аналогии, конечно же, тоже хотят внедрить Agile, но чихали они на улучшение водопадной модели. Они думают, что видят «коня» насквозь, и внутри него кроется смерть не только водопадной модели, но и всей привычной организационной структуры. Получается, у нас есть две группы, которые используют одни и те же термины, но говорят на совершенно разных языках, часто с совершенно разными представлениями — стоит ли спрашивать, почему внедрение Agile проваливается?!
В закостенелых конторах, где руководство любит решать вопросы директивно, с внедрением Agile особенно тяжко — по идее нужно отдавать часть полномочий по принятию решений на местах неформальным группам (которые неизбежно появятся при Agile), а ссыкотно. Потому что это потеря накопленного авторитета как-никак.
А ведь неформальная власть самоорганизуется и более гибко решает вопросы с передачей и получением полномочий. Стоит нам найти в организации людей, с которыми мы хотим общаться, как автоматически проявляется самоорганизация. Стоит нам попросить людей из этой группы принимать определенные решения — как мы уже предоставляем им неформальные полномочия. Стоит нам перестать уважать чьи-то решения — полномочия отзываются так же быстро. Это реорганизация в режиме реального времени. Она гибкая, непредвзятая, постоянно готовая к работе и опирается на коллективные знания группы — формальной власти и не снилось (но это вовсе не значит, что пора от неё отказаться).
Да, только самоорганизующиеся команды могут быть «гибкими», но сделать руководство самоорганизующимся невозможно. Да и у неформальной системы есть свои проблемы. В неформальной системе всё решается на словах, нет общедоступных «правил игры», и это проблема. Формальная иерархия остро необходима, но Agile предписывает, куда должен быть направлен её фокус — а именно, на делегирование.
Настоящие Agile-преобразования начинаются тогда, когда при сохранении формальной власти появляется возможность управлять организацией по-другому. По своей сути, эта трансформация связана с новыми способами управления — как видите, тут и речи не идёт об улучшении эффективности команды, ради которой обычно так хочется внедрить Agile.