4 элемента дизайна, нарушающие ожидания пользователей относительно кнопки «Назад»: на 59% сайтов они работают неправильно

«Как мне вернуться назад? Просто нажму кнопку «Назад». С навигацией тут не очень, если честно. Она вернула меня в раздел «Для женщин». Мда. Я такое не люблю».

Специалисты Baymard Institute* изучили ожидания пользователей – как новичков, так и весьма опытных – касательно кнопки в браузере «Назад». Она уже давно стала одним из основных элементов веб-навигации. И многолетний опыт ее использования привел к формированию довольно специфичной модели понимания того, как именно должна работать кнопка «Назад».

Это серьезно влияет на удобство пользования сайтом, ведь многие распространенные элементы веб-дизайна (оверлеи, якорные ссылки, динамический или скрытый контент и т.п.) по умолчанию имеют технические настройки, которые не соответствуют ожиданиям пользователей относительно того, куда их должна возвращать кнопка «Назад». Исследование Baymard Institute показало, что 59% коммерческих сайтов имеют проблемы с ее функционированием.

При этом, если кнопка «Назад» срабатывает не так, как ожидают пользователи, последствия могут весьма печальны. Юзабилити-тесты показали, что это прямая причина для отказа – посетители уходили с площадки, ругаясь и проклиная всё на свете (причем даже самые спокойные из тестируемых).

• Как должна работать кнопка «Назад» по мнению пользователей
• “Подводный камень” №1. Оверлеи и лайтбоксы (проблема 37% сайтов)
• “Подводный камень” №2. Фильтрация и сортировка (проблема 27% сайтов)
• “Подводный камень” №3: Пошаговое оформление заказа
• “Подводный камень” №4. Возврат со страницы товара к списку товаров
• Еще 5 визуальных представлений, создающих проблемы с кнопкой «Назад»
• Простое решение

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

Как должна работать кнопка «Назад» по мнению пользователей

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

Соответственно, если новое визуальное представление концептуально ощущается как новая страница, пользователь будет считать его таковой, даже если технически оно ей не является. Это должно быть учтено в технических настройках элементов поиска и изучения товаров – таких как оверлеи, фильтрация и сортировка. Например, если пользовали нажмут на ссылку и визуальное представление изменится на 70%, большинство из них посчитают его новой страницей, хотя технически она останется той же, с тем же URL-адресом, но с новым визуальным представлением.

Пример того, как не оправдались ожидания пользователя относительно кнопки «Назад» на сайте Walmart. Путь посетительницы был такой: Список товаров > Страница товаров > Подстраница с отзывами. После этого она нажала «Назад», что вернуло ее на страницу товара. Посетительница провела пальцем по краю экрана, чтобы перейти обратно к списку товаров, но снова оказалась на подстранице с отзывами, что привело ее в замешательство. Еще один клик по ссылке «Назад» – и опять открылась страница товара. К этому моменту посетительница уже забыла о том, что хотела вернуться к списку товаров, и вместо этого перешла к разделу с рекомендуемыми товарами. Это показывает, как сильно непредсказуемая работа кнопки «Назад» может дезориентировать пользователя.

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

Ниже будут рассмотрены «подводные камни» в реализации 4 важных элементов сайта, из-за которых в большинстве случаев кнопка «Назад» срабатывает не так, как ожидают пользователи.

Оверлеи и лайтбоксы (проблема 37% сайтов)

На сайте Nike пользователи могут просматривать фотографии товаров в высоком качестве в галерее. При этом кнопка «Назад» возвращает их не на страницу товара, как ожидают посетители, а на предыдущую страницу – со списком товаров.

Оверлеи и лайтбойксы визуально выглядят как новая страница, появляющаяся поверх предыдущей. Именно поэтому пользователи ждут, что кнопка браузера «Назад» скроет этот элемент, и они вернутся на страницу под ним. Тем не менее на большинстве протестированных сайтов кнопка «Назад» не просто закрывала оверлей, а отправляла на страницу с предыдущим просмотренным URL. Соответствующие ожидания пользователей были отмечены как для десктопных, так и мобильных версий сайтов, для всех типов оверлеев, будь то поп-ап с подпиской на электронную рассылку, галерея изображений или чат. Поэтому кнопка «Назад» всегда должна скрывать оверлей и возвращать посетителя на страницу под ним, а не на предыдущую.

Стоит отметить, что заметный элемент «Закрыть» (например, тот же крестик «Х») может снизить нагрузку на кнопку «Назад» – часть посетителей будет пользоваться им. Но даже при его наличии кнопка «Назад» должна скрывать оверлей.

«Я не знаю, как отсюда выйти… Кнопкой «Назад»? И я снова в разделе с толстовками». Пользователь пытался выйти из галереи изображений с помощью кнопки «Назад», но она вернула его к списку товаров. При этом кнопка для выхода из галереи была скрыта под плашкой «Скачать приложение».

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

Фильтрация и сортировка (проблема 27% сайтов)

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

Фильтрация и сортировка обычно выдают пользователям совершенно новый список товаров. И посетители принимают обновленную выдачу за новую страницу, даже если страница не перезагружается во время выбора нового фильтра или изменения сортировки. Причем пользователь видит новый результат после каждого шага фильтрации, а значит, каждый из них для него – новая страница. Поэтому фильтрация – как категорий, так и результатов поиска – должна позволять пользователю с помощью кнопки «Назад» возвращаться к предыдущему состоянию списка товаров. Направления сортировки также должны меняться на установленные ранее.

«Так, давайте назад…» Посетительница сайта JBL отсортировала список наушников по цене от низкой к высокой. Изучив информацию на странице одного из товаров, она решила, что хочет еще посмотреть другие наушники. Но случайно нажала на кнопку «Назад» дважды. Это вернуло ее к списку товаров, а также изменило направление сортировки. Вот только в интерфейсе направление сортировки не изменилось: «Цена (от низкой к высокой)». По словам посетительницы: «Сортировка пропала, хотя написано, что она все еще работает… Они не отсортированы… Я не могу их найти те, что видела». Исследование показало, что подобные технические ошибки не редкость, при этом они часто сбивают с толку пользователей.

Важно отметить, что при тестировании было выявлено немало случаев, когда пользователи нажимали «Назад» и удаляли фильтр или меняли направление сортировки, но об этом не сообщалось на стороне пользователя. Другими словами, хотя нажатие кнопки «Назад» технически действительно удаляло фильтр или меняло направление сортировки, пользователям казалось, что ничего не изменилось, ведь удаленные фильтры и сортировки по-прежнему отображались как примененные. Это, естественно, запутывало пользователей – они не понимали, сработала ли вообще кнопка “Назад”.

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

Пошаговое оформление заказа

«Ааа, только не это! Мне что, начинать всё сначала? Ничего не сохранилось [имеется в виду уже набранный адрес и данные карты]. Тогда я ухожу. Это несерьезно». Во время тестирования мобильной оплаты пользователь сайта Foot Locker нажал кнопку «Назад» после того, как заполнил всю необходимую информацию на этапе оплаты. К сожалению, он был переброшен обратно в корзину, а все набранные им данные были потеряны. Цитата говорит сама за себя.

Мало кто из пользователей понимает, что для пошагового оформления заказа технически используется одна страница с несколькими свернутыми вкладками. Большинство воспринимает вкладки как несколько отдельных страниц. И это серьезная проблема для сайтов, где пошаговая форма реализована на странице с одним URL-адресом. Ведь пользователи, желающие вернуться к предыдущему «шагу» оформления заказа (например, для редактирования ранее введенной информации), кнопкой «Назад» будут отправлены обратно в корзину.

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

Возвращение со страницы товара к списку товаров

«Кнопка «Назад» возвращает в самое начало. А не туда, где я остановился». Этот пользователь потратил немало времени на скроллинг списка товаров после возврата со страницы каждого товара.

Обычно пользователи просматривают большое количество товаров, прежде чем найти именно то, что им нужно. А значит, им приходится много раз перемещаться между страницами отдельных товаров и общим списком. Если пользователей возвращают в верхнюю часть списка, а не в ту, откуда они перешли в конкретный товар, им приходится каждый раз заново скроллить до нужного места. Что особенно утомительно при использовании мобильных устройств из-за большого объема прокрутки. Кроме того, это дезориентирует пользователей – им может быть сложно вспомнить, где они остановились перед тем, как перешли на страницу отдельного товара. А значит, часть посетителей могут и вовсе отказаться от дальнейшего просмотра.

Но это еще не всё. Четыре примера, приведенные выше, – лишь наиболее распространенные ошибки, связанные с ожиданиями пользователей относительно работы кнопки «Назад». На самом деле «подводных камней» намного больше. Поэтому важно следить за всеми новыми визуальными представлениями, которые могут быть приняты пользователем за отдельные страницы.

Еще 5 визуальных представлений, создающих проблемы с кнопкой «Назад»

Исследование Baymard Institute показало, что в отношении оверлеев, фильтрации и сортировки, пошагового оформления заказа и возврата со страницы товара к общему списку ожидаемое пользователями поведение кнопки «Назад» является последовательным, а значит, есть четкое понимание, что должно быть показано посетителям. Однако при поиске и изучении товаров пользователи могут столкнуться и с другими визуальными представлениями, где всё не так очевидно. О пяти из них будет рассказано ниже.

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

1. Многошаговые процессы на одной странице
2. Раскрывающийся контент
3. Якорные ссылки
4. Скрытый под катом контент
5. Варианты на странице товара

1. Многошаговые процессы на одной странице

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

Часто бывает сложно определить, что показывать пользователям после нажатия кнопки «Назад», когда те взаимодействуют с многоэтапным процессом, встроенным в страницу. Например, с калькулятором стоимости доставки, мастером поиска товаров, опросником и т. д. Одни пользователи хотят увидеть предыдущую страницу, другие – вернуться к предыдущему шагу процесса.

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

Но значение имеет и продолжительность процесса. Пользователям не сложно вернуться, например, через трехэтапный процесс, даже если они ожидали, что кнопка «Назад» приведет их на предыдущую страницу. И последствия принуждения всех пользователей к этому будут не столь серьезны. Если же процесс длительный (например, из 7 шагов), то возврат через каждый шаг может их утомить. Ведь им придется просмотреть 6 отдельных визуальных представлений, чтобы наконец попасть на предыдущую страницу.

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

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

2. Раскрывающийся контент

Пользователь просматривал миниатюры изображений в разделе «Решения для сидения» на сайте IKEA. Каждая миниатюра при клике раскрывается на всю ширину страницы. Развернув первую миниатюру, пользователь затем открыл еще одну, а потом захотел вернуться к первому изображению и нажал кнопку браузера «Назад». Однако в итоге оказался на основной странице раздела, так как развернутые изображения не стали частью истории браузера.

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

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

3. Якорные ссылки

Посетительница сайта Target на странице товара нажала на звездочки в верхней части страницы и перешла в раздел отзывов. Почитав их, она нажала «Назад», но оказалась не в верхней части страницы товара, как ожидала, а в общем списке товаров. Она снова нашла интересующий товар, вернулась на его страницу и добавила в корзину.

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

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

Однако даже при выборе плавной прокрутке стоит учитывать конкретный контекст для решения по кнопке «Назад». Если речь идет о мобильной версии, и страница товара достаточно длинная, а опция «Вернуться к началу» не предусмотрена, имеет смысл направить пользователей обратно к ссылке, по которой он перешел, а не вернуть на предыдущую страницу.

Если же страница товара относительно короткая или на ней много якорных ссылок (по которым пользователь может начать «прыгать» при нажатии кнопки «Назад», если он перешел последовательно по нескольким), лучше сделать возврат на предыдущую страницу.

4. Скрытый под катом контент

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

Скрытый под катом контент, который показывается, когда пользователи нажимают ссылку или кнопку, не должен иметь отдельный URL-адрес, на который будут переброшены пользователи при нажатии кнопки «Назад». Например, на мобильных версиях часто показывают лишь пару строк текста, а остальное скрывают под ссылкой «Далее». И хотя это делает страницу более удобной для просмотра, пользователей при нажатии кнопки «Назад» стоит возвращать на предыдущую страницу, а не к предыдущему контенту.

Разворачивание скрытого контента не приводит к значительному изменению страницы, и пользователи ожидают возврата к ее предыдущему виду при нажатии кнопки «Назад». Чтобы посетителям сайта было проще сориентироваться, следует использовать плавное разворачивание контента, а не мгновенный переход.

5. Варианты на странице товара

«Как же это раздражает… Я хочу вернуться на страницу с разными помадами [к списку товаров]. Я что, как-то не так на нее [кнопку «Назад»] жму?» – посетительница сайта Sephora несколько раз нажала кнопку «Назад», но как будто ничего не изменилось, страница лишь чуть сдвинулась вверх. Лишь зажав кнопку «Назад» и открыв историю просмотров, посетительница наконец смогла вернуться к списку товаров. Дело в том, что она просмотрела несколько вариантов цвета помады, а на Sephora каждый оттенок имеет отдельный URL-адрес. В то же время при многократном нажатии кнопки «Назад» изображение товара не менялось (хотя это происходило, когда пользователь просматривал варианты).

Варианты одного и того же товара должны быть объединены в один элемент списка. Пользователи смогут просмотреть их на странице товара. А вот должен ли каждый вариант иметь отдельный URL-адрес, снова зависит от контекста. Если вариантов продукта мало, предпочтительно использовать для каждого из них отдельные URL-адреса. Да, кому-то из пользователей может не понравиться, что приходится 2-3 раза нажать «Назад», чтобы вернуться к общему списку товаров, но это будет не критично. А вот если посетителей будет выбрасывать с нужной страницы, в то время как они хотели всего лишь вернуться к предыдущему варианту, суммарный уровень негативного пользовательского опыта будет значительно выше. И еще серьезнее будет проблема, если их вернут не в то же место списка товаров, с которого они совершили переход, а в верхнюю часть, вынудив снова искать нужный продукт.

При этом крайне важно, чтобы изображение товара менялось после каждого нажатия кнопки «Назад». В противном случае пользователи будут нажимать «Назад», не видя изменений в интерфейсе (даже если технически показываются разные URL-адреса). Большинство из них подумают, что сайт «завис» или просто не поймут, почему в ответ на их действия ничего не происходит.

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

Простое решение

Хорошая новость заключается в том, что в HTML5 уже есть относительно простое решение: HTML5 History API. В частности, функция History.pushState() позволяет сайту вызывать изменение URL-адреса без перезагрузки страницы. Это означает, что на сайте можно настроить поведение кнопки «Назад» браузера в соответствии с ожиданиями пользователя. (Возможно и обратное: изменить URL-адрес, не создавая запись в истории пользователя.)

На сайте Skechers.com проблему с кнопкой «Назад» успешно решает реализация функции «Загрузить еще» – URL-адрес переписывается при каждом ее нажатии пользователем. Следовательно, когда посетители нажимают кнопку «Назад» в браузере на странице продукта, они возвращаются в нужное положение в списке товаров (например, на «Страницу 3»).

То есть при открытии, например, оверлея сайт может вызвать изменение истории в браузере, позволяя пользователю закрыть оверлей с помощью кнопки браузера «Назад». И это работает для всего, включая открываемые пользователем оверлеи и лайтбоксы, нумерацию страниц на основе AJAX, фильтрацию и сортировку списков, пошаговое оформление заказов — любого элемента, который, как ожидает пользователь, изменил бы историю браузера, но технически этого не делает.

Используйте функцию History.pushState() для создания новой записи в истории браузера пользователя для любого визуального представления, которое пользователь будет воспринимать как новую страницу. Это позволит гарантировать, что поведение сайта будет соответствовать ожиданиям пользователей. Итог: History.pushState() поможет вам настроить такое поведение кнопки «Назад», какое от нее ожидают пользователи. В частности, используя его, можно обеспечить добавление в историю браузера любого визуального представления, которое пользователи считают новой страницей, – независимо от того, является ли она технически таковой или нет.

В этот список входят (но не только):

• Оверлеи/лайтбоксы
• Фильтрация и сортировка выборок
• Пошаговое оформление заказов
• Возврат к списку товаров

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

К ним относятся:

1. Многошаговые процессы на одной странице
2. Раскрывающийся контент
3. Якорные ссылки
4. Варианты на странице товара

Скрытый под катом контент в большинстве случаев не рекомендуется реализовывать как новую «страницу» с помощью History.pushState().

При формировании своих ожиданий относительно того, что считать новой веб-страницей, а что – слегка измененным элементом на той же странице, пользователи полагаются на визуальные эффекты элемента, его контекст и предыдущий опыт работы с сайтом. И кнопка «Назад» должна действовать так, как ожидают посетители. Это поможет избежать непреднамеренных отклонений пути пользователя, которые во время исследования часто становились прямой причиной отказа. Несмотря на серьезность проблемы и довольно простое решение, 59% сайтов не соответствуют ожиданиям пользователя относительно работы кнопки «Назад» по крайней мере по одному из четырех указанных пунктов.

*Оригинал статьи: 4 Design Patterns That Violate “Back” Button UX Expectations – 59% of Sites Get It Wrong Christian Holst. 20.07.2020