Черная пятница в UPROCK!

Проектируем кнопку "Назад”: лучшие практики

Пользователи часто путаются и расстраиваются, когда взаимодействуют с кнопкой “Назад”. Как спроектировать этот элемент правильно и где разместить его в наших интерфейсах?

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

Когда мы имеем дело с одностраничным чекаутом, кнопка "Назад" должна возвращать пользователя к предыдущему шагу, а не к предыдущей странице. Разработано Адамом Сильвером.

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

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

Как же сделать кнопку "Назад" более предсказуемой и полезной? Давайте рассмотрим несколько идей и примеров использования.

Страх перед кнопкой "Назад" в браузере

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

Один из участников исследования комментировал свои действия так: "Как мне вернуться назад? Просто нажать кнопку "Назад"? Если честно, не очень удобная навигация. А теперь она вернула меня в раздел с товарами для женщин. Окей. Мне это не нравится.” (Изображение: Baymard Institute)

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

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

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

Всегда закрывайте большие оверлеи кнопкой "Назад"

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

Когда оверлей большой, кнопка "Назад" должна закрывать модальное окно, а не возвращать пользователя на предыдущую страницу. (Изображение: Eric Bailey)

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

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

Самое главное, что посетители редко воспринимают состояние карусели как "другую страницу". До тех пор, пока страница существенно не меняется, нам не следует добавлять состояния в историю. Это касается чекбоксов, выпадающих меню, переключателей просмотра и динамических секций, поскольку они меняют содержимое одной и той же страницы.

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

Положение пользовательской кнопки "Назад"

Несмотря на то, что мы настроили кнопку “Назад” в соответствии с ожиданиями пользователей, некоторые все равно будут беспокоиться о том, действительно ли она работает должным образом. Хороший способ решить эту проблему — добавить в интерфейс кастомную кнопку "Назад", специфичную для конкретной формы.

Пользователи воспринимают стандартную кнопку браузера и кастомную кнопку "Назад", эффектно вписанную в интерфейс, совершенно по-разному. Если поведение кнопки браузера не всегда очевидно, то от специальной оригинальной кнопки они ожидают “правильного поведения”. Следовательно, люди с большим доверием относятся к таким кнопкам и меньше сомневаются при взаимодействии с ними.

Но где же на самом деле должна располагаться эта кастомная кнопка?

Схема расположения кнопок Стива Шогера. Так где же должна находиться кнопка "Назад"? (Изображение: Steve Schoger)

Стив Шогер утверждает, что независимо от того, как выровнены кнопки в форме — по правому или по левому краю, — всегда стоит располагать основное действие с внешней стороны. Это означает, что кнопка "Назад", которая также должна иметь меньший визуальный вес, будет располагаться рядом с кнопкой "Далее".

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

Возможно, стоит поместить кнопку "Назад" над формой

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

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

Слева: кнопка "Назад" в нижней части страницы; справа: Кнопка "Назад" над формой. Главный вопрос заключается в том, какой шаблон работает лучше? (Изображение: Adam Silver)

Адам Сильвер предлагает разместить кнопку "Назад" над формой, как это сделал Джо Ланман, дизайнер Gov.uk. По словам Джо, при таком подходе она находится примерно там же, где и в большинстве браузеров. Кроме того, такая кнопка, вероятно, не нужна внизу страницы: "если пользователи заполнят форму и кликнут “Назад”, они потеряют свои ответы".

Пользовательская кнопка "Назад" должна выглядеть как интерактивный элемент

Стоит подчеркнуть, что кнопка "Назад", расположенная над формой, должна выглядеть как интерактивный элемент. Это может быть подчеркнутая ссылка или отдельная кнопка, которая действительно выглядит как кнопка.

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

На сайте Gov.uk ссылка "Назад" расположена сверху, подчеркнута и выглядит как интерактивный элемент. (Изображение: Gov.uk)

На сайте Gov.uk ссылка "Назад" расположена сверху (там, где пользователи обычно ожидают увидеть хлебные крошки), подчеркнута и выглядит как интерактивный элемент. Здесь есть только одна заметная кнопка — "Продолжить".

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

Когда форма короткая, подобных проблем не возникает: формы Gov.uk как раз спроектированы по принципу "Один шаг — одна страница".

Располагайте кнопки "Назад" и "Далее" далеко друг от друга

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

Переключатель со стрелками вперед / назад, как, например, в кастомайзере обуви Van's shoes, — небольшой, но эффективный компонент, который помогает клиентам плавно переходить от одного шага к другому. Однако важно, чтобы на каждом шаге были адекватные настройки по умолчанию. (Посмотрите видео)

Кастомайзер Van's shoes содержит панель навигации для быстрых переходов, а также переключатель “вперед / назад”. На узких экранах все доступные опции перечислены горизонтально, и чтобы выбрать одну из них, покупатель должен свайпнуть влево или вправо.

Сайт 177milkstreet с красивым лейаутом для отображения пошаговых рецептов. Этот шаблон можно применить и к конфигураторам. (Посмотрите видео)

В рецептах 177milkstreet кнопки "Назад” / “Далее" сгруппированы в нижней части разделенного экрана, а сами шаги расположены вертикально.

Fully.com подталкивает пользователей к завершению настройки.

На сайте Fully кнопки "Назад" и "Далее" расположены очень далеко друг от друга. Пользователи могут вернуться в любой момент, нажав на стрелку "Назад", которая расположена в левом верхнем углу, в то время как кнопка “Далее” находится в правом нижнем углу. Это надежный способ исключить ошибки.

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

Предусмотрите возможность сохранения настроек

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

Fender Mod Shop позволяет пользователям сохранять настройки в виде снапшотов.

На сайте Fender Mod Shop вы можете создавать "снапшоты" в процессе настройки модели. Вы всегда будете двигаться вперед, но при этом иметь возможность вернуться к определенной версии, которую сохранили в специальном окне.

Подведем итоги

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

Нам определенно нужно как минимум согласовать поведение кнопки “Назад” с ожиданиями пользователей. Кроме того, было бы неплохо добавить в интерфейс кастомную кнопку "Назад" — и, возможно, разместить ее подальше от кнопок "Далее" или "Продолжить", может быть, даже в верхней части страницы.

Хотя в некоторых сценариях это работает очень хорошо, такое решение может не сработать для вас. В этом случае постарайтесь не располагать кнопки слишком близко друг к другу и убедитесь, что они достаточно сильно различаются визуально. Одна может быть оформлена как ссылка, а другая — как кнопка. То, что кажется незначительной деталью, может окупиться с лихвой и привести к снижению количества отказов от покупки и повышению конверсии. А это того стоит.

Источник
и
:
arrow