UXPUB 🇺🇦 Дизайн-спільнота

Cover image for 4 дизайн паттерна не соответствующих ожиданиям пользователей относительно кнопки «Назад»
Редакція
Редакція

Опубліковано

4 дизайн паттерна не соответствующих ожиданиям пользователей относительно кнопки «Назад»

#ux

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

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

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

В этой статье мы поделимся результатами нашего масштабного исследования юзабилити и обсудим наши выводы.

Хотя решение этой проблемы весьма простое, как вы увидите ниже, им на удивление часто пренебрегают, даже крупные сайты и особенно мобильные сайты.

Как пользователи себе представляют работу кнопки «Назад»

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

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

Сайт Walmart не учитывает ожидания пользователя касательно кнопки «Назад». Путь пользователя был «product list > product page > reviews subpage», затем он нажал на ссылку «Назад». Это вернуло его с подстраницы отзывов на страницу продукта. Затем он провел пальцем по краю экрана, чтобы вернуться к списку продуктов, но вместо этого вернулся на страницу отзывов. В замешательстве он снова нажал на ссылку «Назад» и вернулся на страницу продукта. Теперь он забыл о своем первоначальном намерении вернуться к списку продуктов, и вместо этого начал просматривать перекрестные продажи. Игнорирование ожиданий пользователя, касательно кнопки «Назад» может привести к серьезной дезориентации пользователей.

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

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

4 наиболее распространенные ошибки, связанные с кнопкой «Назад»

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

1) Оверлеи и лайтбоксы (37% сайтов этого не делают)

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

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

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

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

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

Во время тестирования мобильных сайтов мы наблюдали, что у пользователей было больше трудностей с закрытием оверлеев с помощью предоставленных сайтом элементов «Закрыть», часто из-за проблем с размером области нажатия. Например, кнопку «X» часто помещали близко к краю экрана, или реклама «Установить приложение», перекрывала элемент «Закрыть» (см. нашу статью Deemphasize ‘Install App’ Ads or Avoid Them Entirely). Таким образом, мобильные пользователи с большей вероятностью используют для закрытия оверлеев кнопку «Назад». Поэтому крайне важно соответствовать их ожиданиям выхода из оверлея при нажатии кнопки «Назад».

2) Фильтрация и сортировка (27% сайтов этого не делают)

Пользователь на сайте Amazon нажимает «Назад» после того, как применил 3 фильтра (первое изображение). Это удаляет последний примененный фильтр, и теперь показано, что применено 2 фильтра (второе изображение). Нажатие «Назад» после применения фильтров должно удалить все примененные фильтры.

Фильтрация и сортировка обычно формируют совершенно новый список продуктов, и поэтому пользователи воспринимают каждое из этих действий как отдельное представление. Даже когда фильтры или направления сортировки не вызывают перезагрузку страницы, в ходе нашего исследования юзабилити списков продуктов и фильтрации мы обнаружили, что пользователи обычно воспринимают каждую дискретную итерацию своей фильтрации, как новое представление (скорее всего потому, что оно является действием, инициируемым пользователем, и каждая итерация выдает новый набор результатов).

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

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

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

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

3) Аккордеон оформления заказа

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

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

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

4) Возврат к списку товаров со страницы продукта

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

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

Когда пользователи попадают в верхнюю часть списка продуктов, а не туда, где были до посещения страницы товара, они дезориентированы и должны заново искать предыдущую позицию в списке продуктов. Это не только утомительно – пользователи должны повторить ранее проделанную работу, прокрутив список, но также может быть сложно вспомнить, где именно они находились до посещения страницы товара (например, если это список синих платьев с похожим стилем).

«Когда вы используете кнопку «Назад», вы сразу возвращаетесь к началу, а не туда, где были до этого».

Пользователям, попавшим в начало списка продуктов, возможно, придется пролистать много элементов, прежде чем они найдут нужное место в списке. В зависимости от схемы загрузки продукта на сайте, сложность повторного поиска может варьироваться от умеренного до экстремального.

Независимо от используемой схемы загрузки продукта, если процесс определения правильного места в списке продуктов является слишком длительным и хлопотным, пользователи вполне могут сдаться и покинуть ваш сайт.

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

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

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

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

  1. Многоступенчатые процессы на странице
  2. Расширение контента
  3. Якорные ссылки
  4. Усеченный контент
  5. Вариации на странице товара

1) Многоступенчатые процессы на странице

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

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

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

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

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

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

2) Расширение контента

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

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

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

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

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

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

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

Однако это менее очевидно, если пользователь плавно прокручивает страницу вниз. Поскольку пользователи прокручивают страницe вниз, они сохраняют обзор того, откуда они пришли, когда они переходят в новое место. Поэтому у них гораздо меньше шансов полностью потерять обзор по сравнению с пользователями, которые перепрыгивают вниз страницы.

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

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

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

4) Усеченный контент

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

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

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

5) Вариации на странице продукта

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

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

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

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

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

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

Решение

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

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

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

Поэтому используйте history.pushState(), чтобы создать новую запись в истории браузера для любого представления, которое пользователь будет воспринимать, как новую страницу (то есть любое представление, которое достаточно визуально или концептуально отличается). Таким образом, вы можете убедиться, что поведение сайта и ожидания пользователей совпадают.

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

  • Оверлеи / лайтбоксы
  • Фильтрация и сортировка выборок
  • Этапы оформления заказа в виде аккордеона
  • Положение списка товаров

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

  • Многоступенчатые процессы на странице
  • Расширение контента
  • Якорные ссылки
  • Вариации товара на странице продукта

Усеченный контент, как правило, не следует делать в виде новой «страницы» с помощью функции history.pushState().

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


Перевод статьи baymard.com

Топ коментарі (0)