Ланч-тайм 233: краткий перевод свежих статей о digital
В номере: сомнительное правило 3-х кликов и троянская война agile.
Содержание
#793. Правило 3-х кликов ошибочно
The 3-Click Rule for Navigation Is False
Правило 3-х кликов — распространённый неофициальный шаблон, который гласит, что до любой страницы или важной информации нужно добраться в 3 клика, а иначе у вас так-себе-интерфейс. Часто дизайнеры применяют это правило для формирования навигации по сайту и задач поиска информации, но некоторые идут дальше и руководствуются им даже при проектировании форм.
Аргумент в пользу правила 3-х кликов: пользователи будут разочарованы, если для выполнения своих задач потратят хотя бы на один клик больше. Правило часто используют для оценки стоимости взаимодействия с продуктом, но его поверхностная простота настораживает.
Эффективная и выгодная реклама с сервисом от МегаФона
Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.
Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.
Беда в том, что это правило не было подтверждено данными ни в каких опубликованных исследованиях на сегодняшний день. Более того, исследование Джошуа Портера фактически опровергло его — уровень удовлетворённости не уменьшается с увеличением количества кликов для решения задачи.
Клики — не очень-то значимый показатель, и вот почему:
- Количество кликов зависит не только от дизайна, но и от сложности задачи, поэтому вывести единое адекватное их число невозможно.
- Не все клики одинаковы: за одними следуют секунды ожидания (например, если загружается новая страница), за другими — мгновенная загрузка контента (например, если листается галерея).
- Количество кликов неинформативно с точки зрения юзабилити — в реальном мире пользователи тупят, ошибаются и запутываются. Простой подсчёт количества шагов в процессе упускает их реальные действия и лишает возможности улучшить их горький опыт.
Поэтому не стоит воспринимать правило 3-х кликов как непреложную истину при разработке сайтов, информационной архитектуры и навигации.
На сайте NYC.gov поиск ссылки, с помощью которой можно сообщить о сломанном счётчике воды, занимает всего 3 щелчка, хотя это довольно трудоёмкий опыт: приходится копаться в куче ссылок и скроллить.
Происхождение правила 3-х кликов
Самая ранняя ссылка на правило 3-кликов (которое смог найти автор статьи) содержится в книге Джеффри Зельдмана 2001 года «Перенеси свой талант в Интернет», где тот упоминает эту концепцию, на тот момент уже распространённую среди сообщества веб-дизайнеров. Подтверждений правилу книга не содержит, вместо этого там приводится фраза: «Понятное дело, если вы не идиот, то согласны с тем, что юзеры движимы желанием всё делать быстро — если они не смогут найти искомое за 3 клика, они уйдут на другой сайт».
Да, исследования подтверждают, что пользователям действительно важна скорость выполнения задач в интернете, но это не значит, что можно делать такие голословные выводы.
Правило 3-х кликов вредит пользовательским интерфейсам
Одно из главных последствий правила — меню должно быть кратким и не содержать кучу уровней, чтобы найти информацию. Да, это разумно, но из-за этого шаблона проектировщикам интерфейсов приходится несладко: вместо одной информационной архитектуры (ведущей вглубь), они вынуждены везде ляпать другую (которая разрастается в ширину).
Дизайнеры, руководствуясь правилом, запихивают всё больше пунктов в меню верхнего уровня. Да, у меню с большим уровнем вложенности тоже есть проблемы с юзабилити (поиск нужного в нём требует больше времени), но меню с большим количеством подкатегорий на верхних уровнях занимает много места и сложно для пользователя.
Из-за этого многим дизайнерам приходится выбирать из двух зол: не более 3 кликов или не более 7 категорий в основной навигации. При этом эти правила не подтверждены исследованиями, по факту бесполезны и подталкивают дизайнеров к принятию компромиссных решений между одинаково плохим пользовательским опытом.
Чем заменить подсчёт кликов
Подсчёт кликов — грубый способ оценки взаимодействия и эффективности задач, поскольку не учитывает когнитивные факторы. Пользователям иногда необходимо прочитать и понять длинный список параметров, выяснить, где они в настоящее время находятся на сайте, или оценить, сколько действий ещё нужно предпринять, чтобы достичь своей цели. И это тоже имеет значение.
Для хорошей навигации важны не клики, а:
- понятные пункты меню с однозначными и знакомыми формулировками;
- хлебные крошки, показывающие текущее положение пользователей;
- мега-меню с несколькими уровнями информационной иерархии вместо каскадного меню, в котором проще всего запутаться и потерять результат поиска при случайном закрытии;
Cardinal Health использует иерархическое выпадающее меню для навигации — трудное для взаимодействия, неинформативное и подверженное ошибкам
- ссылки на самое важное с точки зрения пользователя;
-
целевые страницы для сложных маршрутов поиска (страницы с группами ссылок, изображениями или другими элементами, которые помогают с незнакомой терминологией и помогают ориентироваться между станицами той же категории);
Страница с возможностями фирмы Accenture, специализирующейся на кибербезопасности, содержит списки ссылок, которые в противном случае находились бы на нескольких уровнях в иерархических выпадающих меню
- минимальное время загрузки — 3 клика, длящиеся вечность, хуже, чем 5 шустрых.
Вывод: когда вам в очередной раз кто-то будет «втирать» про правило 3-х кликов, вы сразу поймёте, что этот человек не читал наших ланч-таймов (а правда будет за вами).
Вы сэкономили 6 минут.
#794. Этическая дилемма Agile, распределение решений и троянская война
Agile's Ethical Dilemma, Decision Distribution, and the Trojan War
Внутрикорпоративные войны управленцев часто напоминают историю с троянским конём: вот вам Agile на блюдечке, играйтесь. А потом — бац, и всё пошло по бороде: старые устои порушены, новые так и не укоренились. Разброд и шатание. Кто виноват и что делать?
История о Троянском коне — это история о войне и вполне неплохая метафора: во многих организациях с Agile так и происходит, подчас даже неосознанно. Только в этом случае греки не подсовывают коня и не делают вид, что уплывают — они работают на предводителей Трои.
Что внутри?!
Троянцы (руководство компаний, лидеры) платят грекам (командам), чтобы те помогли построить «коня» (Agile). Троянцы просто хотят более быструю лошадь (= получить результат быстрее) и думают, что это поможет изменить греков (= сделает команды эффективнее). Греки думают, что внутри «коня» скрывается нечто другое и что «конь» поможет изменить троянцев (= команды думают, что с внедрением Agile изменится всё — даже руководство станет более гибким). Ну ага.
Этическая дилемма вот в чём: стоит ли выдвигать Agile как способ решения всех проблем организации, если при этом получается, что результат будет не совсем тем, за который лидеры готовы были платить?!
Взять хотя бы Скрам — в некотором смысле он стал троянским конем, убившим Agile. Сазерленд — один из разработчиков Скрама — продал его менеджерам под соусом, что тот «выполняет двойной объём работы за половину времени». Тоже песенка про белого бычка троянского коня.
«Троянцы» считают, будто Agile просто ускорит их водопадную модель. И считают они так, поскольку платят за конечный продукт — якобы можно получить бо́льшую ценность за счёт максимизации результата при наименьшем количестве работы (привет, Скрам) — вот только это не всегда даёт ощутимый профит (как гласит еврейская поговорка, «спасибо в карман не положишь»).
Некоторые компании всё ещё путают ценность Скрама: одни считают, что дело в «производительности» команд, другие — что дело в самих командах.
Греки из нашей аналогии, конечно же, тоже хотят внедрить Agile, но чихали они на улучшение водопадной модели. Они думают, что видят «коня» насквозь, и внутри него кроется смерть не только водопадной модели, но и всей привычной организационной структуры. Получается, у нас есть две группы, которые используют одни и те же термины, но говорят на совершенно разных языках, часто с совершенно разными представлениями — стоит ли спрашивать, почему внедрение Agile проваливается?!
Внедрение Agile — это доведение принципов (гибкости, адаптивности и интеллектуальности самой системы), изначально предназначенных для команд разработчиков, до всей организации. Но стоит начать внедрять, как понятия «стратегия», «планирование», «управление» почему-то сразу идут по бороде. И тогда тут уже не до Agile — руководству бы как-то авторитет свой удержать сначала.
Если вернуться к аналогии с греками (командами) и троянцами (лидерами) — обе стороны неправы. Троянцы ошибаются, полагая, что профит от «коня» (Agile) — только в улучшении эффективности греков. Да, результат имеет значение, но фокус исключительно на нём равносилен солипсизму, когда есть два мнения: ваше и неправильное. Греки ошибаются, когда утверждают, что вся организация должна быть гибкой (сорян, но так не бывает).
В закостенелых конторах, где руководство любит решать вопросы директивно, с внедрением Agile особенно тяжко — по идее нужно отдавать часть полномочий по принятию решений на местах неформальным группам (которые неизбежно появятся при Agile), а ссыкотно. Потому что это потеря накопленного авторитета как-никак.
А ведь неформальная власть самоорганизуется и более гибко решает вопросы с передачей и получением полномочий. Стоит нам найти в организации людей, с которыми мы хотим общаться, как автоматически проявляется самоорганизация. Стоит нам попросить людей из этой группы принимать определенные решения — как мы уже предоставляем им неформальные полномочия. Стоит нам перестать уважать чьи-то решения — полномочия отзываются так же быстро. Это реорганизация в режиме реального времени. Она гибкая, непредвзятая, постоянно готовая к работе и опирается на коллективные знания группы — формальной власти и не снилось (но это вовсе не значит, что пора от неё отказаться).
Да, только самоорганизующиеся команды могут быть «гибкими», но сделать руководство самоорганизующимся невозможно. Да и у неформальной системы есть свои проблемы. В неформальной системе всё решается на словах, нет общедоступных «правил игры», и это проблема. Формальная иерархия остро необходима, но Agile предписывает, куда должен быть направлен её фокус — а именно, на делегирование.
Кажется, пора научиться делегировать
Формальное руководство стремится к тому, чтобы директивно выдавать информацию для всей системы сверху. Это не Agile. Вместо этого следует делегировать полномочия по принятию решений там, где естественным образом находится информация. Для этого формальной иерархии стоит структурировать «правила игры»: ограничения, в рамках которых будет работать сеть неформальных группировок, и позволить им принимать решения по принципу «когда это необходимо».
Настоящие Agile-преобразования начинаются тогда, когда при сохранении формальной власти появляется возможность управлять организацией по-другому. По своей сути, эта трансформация связана с новыми способами управления — как видите, тут и речи не идёт об улучшении эффективности команды, ради которой обычно так хочется внедрить Agile.
Вывод: если вы хотите внедрить agile только ради эффективности команды, расстроим — придётся меняться самому, чтобы давать ей больше свободы (но и ответственности).
Вы сэкономили 7 минут.
Надеемся, сегодня вы в три клика найдёте себе развлечение на пока ещё летние выходные :–)
Читать по теме: Ланч-тайм: краткий перевод свежих статей о Digital (все выпуски)
