От автора: все говорят о мобильных продажах. Некоторые вебсайты электронной коммерции (e-commerce) рискуют ими заниматься. Мобильная коммерция (m-commerce) обладает недюжинным потенциалом, показав рост в 86% и достигнув в 2012г. объема в 25 миллиардов долларов (согласно данным eMarketer, к 2016г. ее объем достигнет 86 миллиардов долларов).
Кроме того, это целая новая платформа с новыми методами взаимодействия и средой пользования, представляющими массу ограничений и подводных камней, которых следует опасаться при создании дизайна и ведении вебсайта мобильной коммерции. Помимо некоторых уже общепринятых практик, мобильная коммерция, когда дело доходит до ее фактического применения – в общем неизведанная территория.
Вот почему в Институте Baymard мы решили потратить лучшую часть года на проведение широкомасштабного исследования юзабилити, сосредоточившись конкретно на мобильной коммерции (следуя методике опросов TAP: “Think Aloud” Protocol). Мы решили полностью изучить впечатления от мобильных покупок, включая концептуальное понимание пользователями вебсайтов мобильной коммерции и их взаимодействие с полями форм, навигацией по категориям, поиском, страницами продуктов, процессом подтверждения данных и т.д.
Мы протестировали 18 сайтов мобильной коммерции: 1-800-Flowers, Amazon, Avis, Best Buy, Buy.com, Coastal.com, Enterprise.com, Fandango, Foot Locker, FTD, GAP, H&M, Macy’s, REI, Southwest Airlines, Toys “R” Us, United Airlines, Walmart.
Несмотря на исследование мобильных вебсайтов самых крупных игроков электронной коммерции в мире, наши испытуемые обнаружили во время проведения тестов более тысячи проблем, связанных с юзабилити. Проблемы были проанализированы и сведены к 147 рекомендациям по дизайну в отчете под названием «Юзабилити мобильной коммерции» (“M-Commerce Usability”). В данной статье мы поделимся с вами десятью рекомендациями из него.
Тогда как следование некоторым из них увеличило бы и удобство пользователей вебсайтов для настольных компьютеров, в серьезности их нарушения есть большая разница. Тогда как рекомендации для десктопов являются в основном всего лишь «приятными улучшениями», для правильного устройства сайта мобильной коммерции они являются «жизненно необходимыми». Так, по большей части правила юзабилити для мобильных устройств не исключительны, но в контексте мобильной коммерции они гораздо насущнее.
1. Сделайте домашнюю страницу легкой для просмотра
Проблема: Когда, быстро просмотрев домашнюю страницу, пользователи не могут получить общее представление о всем вебсайте, они ощущают к нему меньше доверия и, в конце концов, часто выбирают неподходящий образ действия для решения своего вопроса.
70% участников опроса при первом попадании на домашнюю страницу или в список категорий пролистали их целиком вверх и вниз в попытке, как ее назвало большинство «получить представление о возможностях». Эти опрошенные хотели видеть предлагаемые возможности до того, как решиться что-то выбрать. Даже зная, как найти нужный товар, некоторые участники опроса все равно решили сделать краткий обзор домашней страницы, предположительно для того, чтобы создать свое мнение о вебсайте, на котором собирались делать покупки. В некоторых случаях, найдя искомую категорию, участники опроса все же просматривали одну-две других категории, чтобы получить представление об остальных возможностях вебсайта.
Большая часть опрошенных просматривала всю домашнюю страницу, чтобы представить свои возможности и лучше понять, что можно сделать на отдельном вебсайте. Здесь один из участников продолжает исследовать возможности домашней страницы, уже отыскав нужную ему навигацию категории > “men.”
Следовательно, очень важно сделать домашнюю страницу легко просматриваемой, потому что она станет первой контактной точкой огромной части ваших мобильных посетителей. В значительной степени такое исходное впечатление повлияет на виды ожидаемых от вашего вебсайта товаров и, что важно, не ожидаемых от него. Так как «легко просматриваемая» звучит немного невнятно, во время опроса выяснились три примера того, что «не следует» делать на вебсайте.
ВНОСИТЬ СЛИШКОМ МНОГО ВИЗУАЛЬНЫХ ЭЛЕМЕНТОВ
Избегайте сбивающих с толку направлений, которые получаются по причине размещения на домашней странице множества графически сложных элементов, требующих повышенного внимания. Так произошло в случае с сайтом Macy’s, где примерно 60% первой попадающей в поле зрения части домашней страницы было занято высокографичным контентом, при этом внимания требовали минимум восемь различных элементов:
Многие опрошенные были ошеломлены домашней страницей Macy’s, потому что ее очень сложно просмотреть. Как выразился один из участников: «Я отчаянно пытаюсь получить о ней представление. Мне тут в лицо суют всякую хрень». На изображении справа показано типичное фокусирование взгляда.
Не утверждаю, что вам нельзя иметь на сайте графических изображений — но уменьшите их количество, если они занимают больше половины домашней страницы, и создайте четкое зрительное направление.
ПРОБЛЕМА НЕПОКАЗА ПЕРВОГО УРОВНЯ КАТЕГОРИЙ
Другой ошибкой является ненужное скрытие навигации по категориям. У некоторых вебсайтов опция просмотра категорий имеется в единственном числе, и она приводит пользователя на новую страницу с первым уровнем поиска по категориям. Если на вашем вебсайте пользователь не может делать просмотр другими способами, кроме как по категории или поиску (например, по бренду или магазину продавца прямиком с домашней страницы), а количество опций выбора основной категории – вполне контролируемого размера, то это излишнее упрощение. Вместо того покажите первый уровень категорий прямо на домашней странице с тем, чтобы пользователи могли начать просмотр их списка сразу же после попадания на нее.
Слева: На сайте Coastal.com все категории показаны прямо на домашней странице, что позволяет не только получить прямой доступ, но и дает пользователю верное представление о тех видах товаров, которые можно найти на вебсайте. Для магазинов с множеством способов перехода по каталогу (например, как по категории, так и по бренду), отображение опций категорий прямо на домашней странице может оказаться невыполнимым. Справа: Для магазинов с очень большим количеством категорий первого уровня (обычно торговцев товарами смешанного ассортимента), возможно, наилучшим окажется список наиболее популярных опций, потому что показ всех категорий помешает обзорности.
Более того, не представляйте категории в выпадающем диалоговом меню. Множество опрошенных ясно утверждали, что им приходилось прокручивать весь список в поиске той категории, где они ожидали найти определенный товар. Проблема с выпадающими меню, таким образом, быстро выяснилась: так как оно занимает только до 50% доступного пространства экрана, получение общего представления о доступных категориях ненужно усложняется (смотрите ниже Best Buy).
Так как область касания тоже составляет всего половину размера, участникам опроса было гораздо сложнее точно контролировать скорость прокрутки. Наконец, некоторые опрошенные путали выпадающий элемент интерфейса с выбором по фильтру и не опознавали его как основную навигацию вебсайта по категориям.
Не следуйте примеру сайта Best Buy, у которого в основном содержимом домашней страницы отсутствует опция выбора категорий. Место категорий в верхнем колонтитуле страницы занимает иконка с тремя полосками. От пользователей требуется не только догадаться о значении этой иконки, она также делает невозможным получение представления о магазине при просмотре домашней страницы. И, конечно, применение выпадающего меню для выбора категории тоже неидеально.
ИДЕЛЬНОЕ ВЫРАВНИВАНИЕ ПО НИЖНЕЙ ГРАНИЦЕ ЭКРАНА
Наконец, не создавайте дизайн своего вебсайта с идеальным выравниванием или белым пространством точно по нижнему краю. Это произошло с вебсайтом GAP, где непонятно, содержит ли домашняя страница что-то кроме поля поиска и нескольких графических элементов (т.е. никакой навигации по категориям), потому что эти элементы выравниваются точно по границе окна просмотра (по крайней мере, на iPhone’е).
Один участник опроса удивился: «Это и все? Это вся страница?», решив, что это и была вся домашняя страница GAP. Когда элементы разделяются попиксельным выравниванием по краю окна просмотра, пользователи часто принимают за всю домашнюю страницу одну ее верхнюю часть (в данном случае пропустив ниже расположенную навигацию по категориям).
Чтобы показать еще наличие содержимого, просто выровняйте элементы так, чтобы в самых популярных мобильных устройствах некоторые из них были видны в окне просмотра только частично.
Следовательно, при создании дизайна легко просматриваемой домашней страницы:
Над нижним краем домашней страницы размещайте очень мало (или вообще не размещайте) визуально стимулирующей графики, и убедитесь, что те изображения, которые там находятся, обладают четкой зрительной траекторией, чтобы пользователь мог быстро сделать обзор страницы.
Постарайтесь сделать так, чтобы нижняя граница окна (в самых популярных мобильных устройствах) частично отсекала контент, показывая, что ниже есть еще опции.
Отображайте навигацию домашней страницы в виде списка (а не выпадающего меню).
Если у вас есть всего один вид навигации по категориям (такой как «вид продукта» или «раздел», и нет вдобавок «бренда» или «магазина»), то покажите первый уровень категорийной иерархии прямо на домашней странице полностью или, если опций слишком много, в виде укороченного и свернутого списка самого популярного ассортимента.
Под полем поиска отображайте только выделенные или популярные товары и навигацию по категориям.
2. Внимательно отнеситесь к опасению потери данных
Проблема: Писать на мобильных устройствах неудобно, поэтому пользователи постоянно беспокоятся по поводу возможной потери своих введенных данных.
«О, нет! Мне придется начать сначала? Теперь я начинаю злиться. Он еще не получил мои данные, что ли?» — стонал участник опроса, обращаясь к введенным перед этим адресу и информации о кредитной карте, которые неожиданно исчезли. «Я ухожу. Это – несерьезный магазин»./p>
Сохранность данных – не тот предмет, к которому можно отнестись с легкостью. Ваши пользователи по этому поводу очень серьезны. Конечно, рекомендации просты: всегда сохраняйте данные пользователя, что потребует инвестиций в серьезную технологию, тщательного тестирования и временного хранения введенных данных на устройстве пользователя (большинство мобильных браузеров поддерживают localStorage). Конечно, это легче сказать, чем сделать, и, к великому разочарованию пользователей, многие вебсайты позорно провалились.
Так как пользователи уже набрались печального опыта потери данных, они часто выражают крайнюю осторожность к некоторым видам элементов и избегают определенного взаимодействия, где только это возможно. На следующем скриншоте показаны те виды действий и элементов, которые особенно их волнуют. Либо совсем избегайте их, либо успокойте опасения пользователей умным применением микрокопирования, иконок и анимации.
Во время проверки опрашиваемые постоянно открывали ссылки в новом окне, потому что боялись, что их данные потеряются, если открывать ссылки в текущем окне.
Участники опроса почти всегда тревожились по поводу неожиданных перезагрузок страницы (например, любой перезагрузкой, не являющейся прямым следствием щелчка по ссылке или кнопке). На нижеприведенном изображении опрашиваемый выбрал «Местожительство», что привело к перезагрузке страницы, при этом участник опроса тут же стал прокручивать вверх и вниз, чтобы убедиться, что никакие из его данных не утеряны. Время от времени во время тестирования мы отмечали этот вид обеспокоенности опрашиваемых перезагрузкой страницы.
Многие участники опасались системных диалогов и часто считали, что данные потеряются, если они щелкнут “OK”, хотя мало кто из них на самом деле читал сообщение. Опрошенный в вышеприведенном тесте хотел вернуться назад и выбрать другой билет, но столкнулся с этим диалогом и сделал отмену — решив, что при выборе другого билета ему придется вводить все заново.
Приличное количество участников опроса считали, что при выходе из процесса проверки их данные уничтожатся и отказывались вернуться и выбрать другие продукты. Участник вышеприведенного теста хотел бы вернуться и подыскать другой букет цветов, но не решился, потому что не хотел еще раз вводить все свои данные. Такое случалось несмотря на то, что на самом деле многие протестированные вебсайты запоминали данные пользователей, даже когда те бросали процесс проверки на середине — основное слово тут, конечно «многие» вебсайты, а не «все». О подверженности подобной нестабильности пользователи не могли знать заранее, поэтому подозревали в худшем все вебсайты подряд.
Во время проверки кнопка «назад» воспринималась участниками опроса в основном как нечто опасное и применяли они ее только тогда, когда чувствовали, что вышли из всех опций. Во многих случаях это восприятие было оправдано: многие вебсайты на самом деле не могли поддерживать сохранение данных пользователя при применении кнопки «назад». Однако в той же степени важно то, что ссылки на продолжение процесса и прочие «обратные» ссылки и кнопки, являвшиеся частью пользовательского интерфейса вебсайта, в основном воспринимались опрашиваемыми как «безопасные».
Таким образом, очень важно создать либо ссылки на продолжение процесса, либо обратные ссылки при проверке, чтобы пользователям не казалось, что им приходится рисковать, применяя кнопку браузера «назад», а можно было пользоваться для этих целей специальными элементами пользовательского интерфейса. В вышеприведенном тесте участник опроса искал ссылку или кнопку, которая привела бы его на предыдущий этап, но не смог ничего найти. В конце концов, он попытался воспользоваться кнопкой браузера «назад».
Это – самые значительные догадки, связанные со страхом пользователя потерять введенные данные. Вообще опрошенные выражали гораздо больший пессимизм по отношению к тем вебсайтам, на которых они их уже однажды теряли. Например, в результате щелчка одной из участниц опроса по кнопке клавиатуры «далее» очистились введенные на вебсайте данные, что заставило ее постоянно избегать этой кнопки на протяжении всей проверки. Как она сказала: «Ну вот, не решаюсь больше щелкать «далее», потому что не хочется начинать все сначала». Кроме того, опрашиваемая начала осторожничать при взаимодействии с любыми полями ввода вебсайта, опасаясь, что даже легчайший сбой уничтожит ее данные.
Единственный неудачный опыт ведет к плохим ожиданиям от остальных вебсайтов. Так что как мы пытаемся избежать плохого впечатления тогда, когда из-за технических ограничений неспособны хранить данные пользователя? В таких случаях четко уведомите пользователя о том, что тот собирается сделать что-то разрушительное.
Так как участница опроса не закончила заполнять данные, вебсайт предупредил ее, что те будут потеряны. «Это очень хорошо», отметила опрашиваемая, «потому что если бы я сделала что-то неправильное случайно, то была бы в высшей степени раздражена, если бы все удалилось. Поэтому хорошо, что меня предупредили о том, что данные могут утеряться».
Сохранять данные, конечно, всегда идеальное решение, но предупредить пользователя и дать ему возможность вернуться назад до уничтожения его данных – это отличное вторичное решение и, конечно, уж гораздо лучше простого уничтожения данных пользователя без предупреждения; более того, оно дает пользователю возможность отменить разрушительное действие. Эта альтернатива может оказаться особенно правильной при менее привычной навигации, где внедрение сохраняемых данных занимает слишком много времени, принимая во внимание то, на какое малое количество пользователей оно влияет.
Это также могло бы повлечь что-то вроде сохранения покупательской корзины пользователя или данных при переключении между полной и мобильной версиями вебсайта. В этих случаях приемлемо просто уведомить пользователя, что в дальнейшем они потеряют свои данные, а затем дать им возможность продолжить делать то, что они желают (и потерять данные) или остаться (и сохранить их).
Понятно, что обеспечение сохранности данных – сложное дело, особенно когда учитываешь ожидания пользователя относительно него. Мы наблюдали, как опрашиваемые создавали аккаунты лишь для того, чтобы гарантировать сохранность, и были свидетелями потери данных из-за случайного щелчка, и видели с тем же удивлением, что и опрашиваемый, как целая форма идеально запоминалась с помощью автозаполнения, превращая в радостное мгновение потенциально ужасную потерю данных. Постоянство данных – штука хитрая, но делать ее правильно очень важно.
3. Добавьте внизу страницы с товаром основную кнопку
Проблема: Пользователи склонны неправильно понимать кнопки корзины в нижнем колонтитуле страницы, если внизу каждой страницы с продуктом отсутствует кнопка добавления в корзину.
У многих протестированных вебсайтов было множество идентичных призывающих к действию первостепенных кнопок на страницах с продуктами (например, две кнопки «Положить в корзину»), одна либо вверху, либо посреди страницы с продуктом а вторая – внизу.
На сайте Best Buy один из участников опроса прочел все описание товара и склонялся к тому, что «Да, этот товар я хочу купить». Он увидел иконку продуктовой корзины внизу страницы вебсайта (второе изображение вверху) и щелкнул на нее, считая, что это была кнопка «Положить в корзину». Он логически рассудил, что продукт будет добавлен в его корзину и продолжил поиск прочих товаров, и только гораздо позже во время покупки заметил, что вебсайт «удалил» содержимое его корзины (телевизор не добавился с самого начала).
На сайте Amazon опрашиваемая сочла, что иконка продуктовой корзины была кнопкой добавления выставленного товара в ее корзину.
Оказалось, что на вебсайтах с одной побуждающей к действию кнопкой на странице с товаром участники опроса сталкивались с серьезными проблемами даже при добавлении продукта в корзину — что в некоторых случаях вело к полному отказу от покупки. Иконки корзины в заголовке или нижнем колонтитуле страницы часто принимались за кнопку «Положить в корзину».
И Best Buy, и Amazon’у не удалось сделать очевидными и доступными основные кнопки, что заставляло участников опроса интерпретировать разные иконки на странице, включая иконку корзины, как видно из двух вышеприведенных примеров. В поисках кнопки «Положить в корзину» опрашиваемые часто прокручивали страницу с товаром до самого низа (поведение, подтвержденное еще одним исследованием).
Эта участница опроса искала кнопку «Положить в корзину», прокрутив до низа страницы, затем обратно к ее верху, думая, что могла ее просмотреть и, наконец, снова терпеливо прокручивала вниз, пока не обнаружила кнопку «Положить в корзину» в середине страницы.
Чтобы согласовать такое поведение и уменьшить неправильное понимание иконок продуктовых корзин, добавьте внизу всех страниц с товарами вторую кнопку «Положить в корзину». Она, кроме того, будет поддерживать более естественный порядок взаимодействия, так как пользователь сначала читает описание продукта, затем его характеристики, затем отзывы и так далее, а потом в конце страницы решает, купить его или нет. Только если страница с товаром совсем короткая (высотой в одно-два окна просмотра), будет достаточно одной кнопки.
4. Будьте осторожны с анимированными «каруселями»
Проблема: Пользователям не удается обнаружить важные свойства, показанные только в «карусели» изображений, и им сложно взаимодействовать с самими каруселями.
Анимированные карусели вызвали проблемы взаимодействия у половины участников тестирования. Для некоторых опрошенных они просто слишком быстро сменялись, мешая им прочесть и выбрать опцию.
Участник опроса собрался было щелкнуть на слайд “Mega Sale”(на изображении слева), но в этот момент на карусели анимировался следующий слайд, заставив опрашиваемого дожидаться появления нужного слайда.
Во многих случаях участники опроса находили слайд карусели интересным и пытались дотронуться до него. Однако в этот момент карусель менялась, отчего загружался ненужный слайд. Иногда участники замечали это, а иногда нет, и тут же покидали страницу, на которую перешли, потому что не находили на ней соответствия тому, что искали.
Интересно, что кнопки “Prev” и “Next” карусели на Toys “R” Us не использовались ни одним участником тестирования, несмотря на следующие проблемы:
Карусель изменилась в ту же секунду, когда эта участница ее коснулась, зарегистрировав щелчок на “Bike Blast” вместо нужного ей “Mega Sale”. Опрашиваемая так этого и не заметила и решила, что “Bike Blast” и был распродажей.
Обе проблемы взаимодействия также встречались (и все еще существуют) в ранних версиях каруселей полноформатных сайтов, но так как карусели на домашних страницах сайтов электронной коммерции в последние несколько лет стали безумно популярными, они немного эволюционировали и большая их часть останавливает анимацию при проведении пользователем мышью над опцией.
И у большей их части также имеется индикатор, дающий пользователю возможность видеть, сколько слайдов в карусели и, что почти так же важно, перейти на определенный слайд (например, обратно к тому, который привлек внимание, но слишком быстрой сменился). Эти проблемы нельзя с легкостью решить на мобильных устройствах, так как в них нет состояния проведения мышью и намного меньше места на экране.
На домашней странице Toys “R” Us’ опрашиваемые сосредоточенно изучали меню, чтобы отыскать мастер подсказок “Gift Guide”, но не смогли его найти (изображение слева). Оказывается, там есть мастер, но добраться до него можно только через определенный слайд во вращающейся карусели вверху страницы.
Возможно, еще более критичный вопрос юзабилити состоит в том, что большинство участников тестирования, взглянув на первый слайд, затем просто игнорировали карусель. Некоторые ждали и просматривали два-три слайда перед тем, как сосредоточить свое внимание на чем-нибудь. Это доказало свою важность на некоторых вебсайтах, таких как Toys “R” Us’, потому что большинство участников отчаянно искали традиционную навигацию определенных свойств (таких как «Найти подарок»), получить к которым доступ можно было только через карусель. При этом некоторые опрашиваемые говорили о том, что вебсайту действительно требуется какой-нибудь «путеводитель по подаркам», полностью покидая вебсайт после того, как его не удалось отыскать.
Пользователи игнорируют анимированные карусели по многим причинам.
Во-первых, содержимое карусели может выглядеть как рекламное объявление, в зависимости от того, как оно оформлено, сильно увеличивая шансы быть незамеченным как баннер (группа участников опроса склонялась к тому, чтобы больше уделить внимания навигации, основанной на текстовой, а не графической информации).
Во-вторых, при использовании для просмотра полной версии вебсайта большого монитора лэптопа или настольного компьютера пользователь может видеть и другие опции домашней страницы, при этом рассмотрев остальные слайды карусели по мере смены изображений.
Однако в мобильных устройствах экран настолько мал, что карусель займет значительную часть окна, причем при просмотре слайдов карусели увидеть какую-либо навигацию или опции категорий будет практически невозможно (что-либо из них всегда будет частично или полностью вне поля зрения). Следовательно, если пользователь увидит на мобильном устройстве все опции карусели, ему придется просмотреть ее всю (как видеоклип).
Вне зависимости от причин(ы), важно именно то, что подавляющее большинство участников полностью игнорировали анимированные карусели и, находясь на домашней странице, вместо этого сосредоточивали внимание на навигации по категориям и функциях поиска. Поэтому, полагаясь при передаче важного содержимого на карусель, будьте очень осторожны и никогда не делайте ее единственным способом передачи определенной функциональности.
5. Будьте осторожны при показе информации о товаре или изображений на отдельных субстраницах
Проблема: Пользователям невероятно сложно разобраться во множестве субстраниц товара.
На мобильном устройстве пользователям гораздо сложнее разобраться в возможностях текущей страницы из-за очень маленького экрана. Мобильным страницам часто не хватает мелких, но важных деталей, которые всегда присутствуют на полноразмерных страницах, таких как полный набор цепочек навигации «хлебные крошки», обзор текущей страницы и полных путей URL’ов, видимые в течение сессии браузера.
Этот недостаток обзорности на мобильных устройствах делает очень рискованным делом любые подэтапы или субстраницы, ссылающиеся на главную страницу, потому что пользователю придется полностью разобраться в возможностях текущей страницы для того, чтобы понять различия между субстраницей и основной страницей.
Когда пользователи желают рассмотреть укрупненное изображений товара на Amazon’е (слева), они перенаправляются на субстраницу (посредине). Участники нашего тестирования четко видели, что все еще находятся на странице определенного товара (из-за его увеличенного изображения), но не понимали, куда девается остальная страница этого товара (справа).
Это немедленно выяснялось при тестировании вебсайтов, предлагающих увеличенные изображения, которые перемещали пользователей на отдельную субстраницу продукта, как на вышеприведенном примере сайта Amazon. Из-за видимого отсутствия доступа к важному контенту, такому как «Описание товара», «Характеристики товара» и «Отзывы пользователей» (которые доступны только на главной странице товара), опрошенные, не заметившие изменения области видимости, приходили к выводу, что такого контента для данного продукта просто не существует, и продолжали искать другие товары, к которым есть такая информация, отбрасывая идеально подходящие.
На Amazon субстраницы также применяются для показа полных списков характеристик, вызывая в точности ту же проблему, за исключением того, что на этот раз участники опроса не смогли определить кое-чего важного, типа кнопки «Положить в корзину».
На мобильном устройстве, а особенно на субстраницах, понимание текущих возможностей гораздо сложнее. Вместо этого отображайте галереи увеличенных изображений, подробные характеристики товаров и подобное (например, весь существенный контент) прямо на основной странице товара. Также можно было бы применить прогрессивное раскрытие путем свертывания по умолчанию каждого раздела содержимого, во избежание слишком длинных страниц; но убедитесь потом, что ваши спусковые индикаторы ясны и понятны. Подобная стратегия минимизирует необходимость отображения дополнительной информации и изображений на субстраницах и возникающие в результате проблемы обзорности.
В особенности в случае галереи изображений у вас имеется опция наложения, как показано выше на Foot Locker. Под наложением пользователь видит страницу товара и легкий способ на нее вернуться.
6. Тщательно обдумайте дизайн и сочетание трех опций выбора аккаунта
Проблема: Пользователям оказалось трудно догадаться, как запускается «Войти как гость» и разобраться в отношениях полей, выборе опций и кнопок на этапах выбора аккаунта.
В мобильном устройстве выбор пользователем типа входа — «Создать аккаунт» «Войти в свой аккаунт» или «Войти как гость» — будет отдельным этапом (в отличие от полных версий вебсайтов, где он может являться частью первого этапа). Более половины участников тестирования (60%) столкнулись с серьезными трудностями при идентификации, просмотре и выборе опции гостевого входа на этапе выбора аккаунта во время входа на сайт.
Много раз недопонимание вело участников к убеждению, что требуется регистрация, несмотря на то, что это опция по выбору, и несло все отрицательные стороны принудительной регистрации аккаунта (включая решительный отказ от нее). Следовательно, дизайн экрана выбора аккаунта для мобильных устройств настолько же важен, как создание опции гостевого входа вообще.
К серьезному непониманию вели несколько разных схем дизайна, как показано на следующих скриншотах-иллюстрациях.
На Macy’s участники увидели этап выбора аккаунта (вверху слева) после выбора корзины. Некоторые щелкнули на «Быстрый вход», считая, что пройдут быструю регистрацию (как гость), и получили ошибки проверки формы в двух полях лишь оттого, что «Быстрый вход» требует аккаунта на Macy’s (вверху посредине). Некоторые обнаружили опцию «Войти как гость» ниже на странице (справа) только после получения такой ошибки валидации, тогда как прочие так и не заметили опцию гостевого входа и зарегистрировали аккаунт, считая, что он необходим.
На многих вебсайтах (Amazon, Toys “R” Us, REI, GAP, Best Buy) опрошенные начали взаимодействовать с полями, такими как подтверждение адреса своей электронной почты (вверху). На REI каждый участник первым делом взаимодействовал с полем адреса электронной почты, считая, что это и есть опция гостевого входа.
В большинстве случаев участники замечали ошибку до отправки формы (обычно добравшись до поля ввода пароля и догадавшись, что находятся в форме входа в аккаунт или его создания). В подобных случаях проблемы не выявит ни детальный анализ вашей веб-статистики, ни журнал регистрации ошибок, потому что сообщений об ошибке валидации вообще не случается.
На Buy.com все обстоит еще хуже. Подавляющее большинство участников опроса просто не смогли выяснить отношения между четырьмя методами входа (войти в аккаунт, создать аккаунт, войти как гость и войти в PayPal), двумя полями формы, тремя радиокнопками и двумя основными кнопками. Потратив некоторое время на попытку разобраться в странице, все нажимали опцию «Войти как гость».
Далее, название кнопки «Войти с помощью безопасного сервера» полностью сбивало участников с толку, потому что они пытались войти как гость (и, следовательно, активно старались ни на что не подписываться). Это особенное название годами использовалось на Amazon и даже выделялось, как лучший способ обозначения безопасного входа в аккаунт, как же оно привело к такому общему непониманию?
Причина в том, что оно означает вход пользователя в аккаунт, что имеет смысл, только если тот у него есть, или он его создаст, но не гостевой вход. (Amazon не предлагает опции гостевого входа, поэтому название в этом контексте имеет смысл.) Из-за названия кнопки один из участников заключил, что другая единственная на этой странице выделяющаяся кнопка, «Войти через PayPal», должна при выборе запустить «Войти как гость».
Остальные, наконец, нажали кнопку со странным названием — но ничего не произошло. Оказывается, рядом с меткой «Введите адрес своей электронной почты» появился встроенный текст «Обязательно для заполнения» (смотрите выше), но никто его изначально не заметил. Опрашиваемые обычно ждали некоторое время просто на случай, если вебсайт не загрузился, нажимали ее снова, и на этом этапе многие понимали, что им нужно заполнить еще данные. К этому моменту некоторые, особенно те, кто не заметил ошибку валидации, заключали, что войти как гость нельзя, и вместо этого продолжали создавать аккаунт.
Один объяснил свое впечатление так: «Обычно я бы не подумал, что можно воспользоваться гостевым входом без создания аккаунта. Но тут мне нужно ввести свою почту, оттого я не могу понять, зачем нужна эта опция. Чтобы обезопасить себя, я затем выберу «Нет, я новый покупатель», потому что меня вынуждают создать аккаунт, и уж во всяком случае можно было бы сделать это как следует».
Сделать процесс выбора аккаунта понятным так же важно, как предложить опцию гостевого входа. Предотвратить эти серьезные проблемы поможет следование двум основным принципам дизайна:
Всегда помещайте опцию гостевого входа наверху с отдельной кнопкой продолжения процесса, чтобы пользователю на этом этапе не приходилось заполнять поле электронной почты. (Если нужно, можно проверить, есть ли у пользователя аккаунт, на следующем этапе, когда вы запрашиваете адрес его почты, чтобы гарантировать, что он не выбрал гостевой вход только оттого, что это первая опция списка.)
Сверните все поля и описание всех трех опций — «Войти как гость», «Войти» и «Создать аккаунт» — выстроив их вниз в один столбик, чтобы можно было видеть все в окне просмотра без необходимости прокрутки или растяжения. При нажатии динамически увеличивайте их, показывая поля и описания. Так будет, кроме того, понятно, какие поля связаны (и нужны) с каждой опцией.
Ниже мы создали простой макет для иллюстрации того, как упростить выбор аккаунта путем сочетания этих двух принципов:
Все три возможности выбора аккаунта отражены в свернутом виде (с гостевым входом вверху), чтобы пользователь постоянно мог видеть доступные опции. Они могут либо увеличиваться (на изображении справа), либо перенаправлять на следующий этап процесса входа. Прогрессивное раскрытие также хорошо поясняет отношения между опцией и ее полями.
7. Отключите автозамену при неэффективном словаре
Проблема: Плохая автозамена разочаровывает, когда пользователь ее замечает, и может навредить, когда не замечает.
Автозамена обычно плохо работает с аббревиатурами, названиями улиц, адресами электронной почты и прочими словами, отсутствующими в словаре. Во время тестирования она вызывало значительные проблемы, а ее результатом оказалось большое количество ошибочных отправленных данных по мере завершения участниками своих покупок.
Когда этот участник напечатал название своей улицы — westheimer – телефон сделал неверную автокоррекцию на weathermen (слева). Однако участник опроса этого не заметил, отправил форму и получил ошибку валидации (справа).
Одна из основных проблем автозамены – то, что опрашиваемые часто не замечали исправлений (потому что были сосредоточены на том, что печатают, а не на том, что напечатано). Это нормально, когда коррекция правильная, а если нет, она может оказаться губительной. Например, во многих случаях правильный адрес автоматически заменялся на неверный и отправлялся, потому что участник этого не замечал.
На вебсайтах без валидации в результате отправлялись неправильные адреса, если только опрашиваемый не был особенно внимателен на странице просмотра своего заказа. В конце концов, адрес пользователя часто заменялся на что-нибудь очень похожее, но неверное. Вдобавок к примеру с “weathermen”, аббревиатуры официальных адресов, таких как “Rd” (сокр. От Reverend — преподобный – прим. переводчика), автоматически корректировались на “Ed.”
В общем, автозамена сильно помогала, когда хорошо работала. Поэтому не отключайте ее во всех полях. Применяйте ее осторожно и отключайте там, где словари работают слабо. Обычно сюда включаются различные названия (улица, город, пользователь) и прочие идентификаторы (такие как адрес электронной почты).
Отключить автозамену можно, добавив атрибут autocorrect в тэг input и установив его на off, как здесь:
1 |
<input type="text" autocorrect="off" /> |
8. Делайте поля достаточно длинными для полного показа обычных данных (и ставьте над полями метки)
Проблема: Пользователи нелегко замечают ошибки, и тем более исправляют их, когда поле слишком короткое и не может показать все введенные данные.
Из-за маленьких размеров экранов мобильных устройств поля формы часто слишком коротки и не позволяют пользователям проверить себя перед отправкой данных, и исправить ошибки валидации очень трудно, потому что не видно все введенные данные полностью.
«Не вижу, что напечатал. Черт. Значит, все удалю и напишу заново». На сайте REI ошибка валидации поля адреса электронной почты, которое было слишком коротко для полного показа введенных данных, сделало для пользователя невозможным видеть саму ошибку. Попытавшись просмотреть введенный текст, участник опроса случайно отключил как инструмент выбора текста iOS, так и инструмент замены текста.
Слишком короткие поля формы представляли проблему для многих опрошенных, которые пытались проверить правильность своих данных перед их отправкой. Они часто жаловались примерно так: «Не могу рассмотреть, одинаковая ли почта, когда поле ввода адреса недостаточно длинное». Некоторые примеры приведены внизу.
Слева: поле ввода электронной почты Amazon слишком короткое, несмотря на изобилие белого пространства. Посредине: поле кредитной карты United показывает только 15 символов, несмотря на то, что номера большинства карт состоят из 16 цифр. Справа: поля ввода почты Macy’s слишком коротки для проверки данных теми пользователями, которые хотят убедиться, что два введенных ими адреса совпадают.
Так как сделать ошибку при печатании на мобильном устройстве легко, недостаточно длинные поля, не дающие пользователям возможности проверить свои данные перед отправкой, очень плохо влияют на их впечатление. Еще хуже то, что они бесконечно затрудняют исправление любых ошибок валидации.
Обратите внимание, что в случае с Amazon и более ранним примером с REI, белого пространства достаточно для того, чтобы сделать поле гораздо длиннее, тогда как в двух других примерах нет дополнительного места для увеличения полей из-за выровненных по левой стороне меток. Именно по этой причине метки должны быть помещены над полями форм, чтобы можно было использовать все пространство и отобразить данные пользователя полностью (при нормальном размере шрифта). Показывать метки слева от полей можно только когда устройство развернуто в альбомной ориентации (что подробно объясняется в «Юзабилити мобильных форм: располагайте метки над полями» (Mobile Form Usability: Place Labels Above the Field)).
Адекватная ширина строк для почты и адреса – во весь экран. Затем настройте размер шрифта полей, чтобы можно было полностью показать данные разумной длины, такие как imya.familiya@kompaniya.com. (Распределение длины символов нашего списка рассылки показывает, что 96% адресов электронной почты состоят из 30 и менее символов.)
9. Дайте пользователям возможность проверить введенный день и дату
Проблема: Применение текстовых полей для дат требует от пользователя ненужного обдумывания и при выборе может вызвать серьезные ошибки.
Во время тестирования вебсайты, предоставляющие для выбора даты только простое текстовое поле или выпадающий диалог, представляли трудность для 80% участников.
Эта участница оказалась в числе 80%, которые не были уверены, каким числом была «эта пятница». Поэтому она решила сосчитать дни на пальцах, желая убедиться, что выбрала верный.
Так произошло и с Southwest (на котором для выбора месяца и дня применяются выпадающие диалоги), и с United (который показывает текстовое поле для написания ММ/ДД/ГГГГ). На обоих этих вебсайтах случились следующие сцены:
Некоторым участникам пришлось считать дни на пальцах (как показано выше).
Половина опрошенных вышли из сайта и открыли встроенное приложение-календарь телефона, чтобы проверить дату своей поездки на выходных (подтвердить «эту пятницу»). В вышеприведенном случае проверка по календарю не удалась, потому что участница проверила 15 июня вместо 15 июля и в итоге приобрела билет на самолет на «эти выходные», который вылетал в воскресенье и возвращался во вторник.
Наконец, некоторые боролись с набором с клавиатуры и использованием инструмента выбора текста для введения правильной даты на вебсайте, где для выбора даты применяется текстовое поле.
По контрасту, на трех тестируемых вебсайтах, обеспечивших графический интерфейс ввода дат в виде календаря (а именно: Enterprise, Avis и 1-800-Flowers – смотрите выше), не возникло ни единой из этих проблем, а участникам в основном понравилась возможность проверить выбираемые день и дату. Потенциально это уберегло покупателей от неправильного высчитывания и «проверки» неправильных выходных (о чем писалось выше) и, таким образом, бронирования на неправильную дату.
Хотя на настольном компьютере это тоже ужасно раздражает (так как пользователь замечает на нем ошибки ненамного лучше), серьезность влияния на впечатление пользователя мобильного устройства намного сильнее, когда дело доходит до исправления ошибочных данных, потому что редактировать урезанные данные на трех-четырехдюймовом сенсорном экране гораздо тягостнее, чем применить мышь или клавиатуру на десктопе. Более того, заказ билетов на неправильный день на настольном компьютере менее вероятен, потому что форма бронирования и отдельное приложение-календарь можно отображать рядом — тогда как на мобильном устройстве зараз можно видеть только что-нибудь одно.
Следовательно, всегда обеспечьте такой интерфейс, который позволяет пользователю проверить день недели на выбранную дату. Одной из возможностей является отображение календарного интерфейса, где пользователь спокойно выберет нужную ему дату. Так действительно упростится интерфейс выбора и, что еще более важно, пользователю будет дан шанс проверить день недели. Если вы уже используете для ввода дат выпадающее меню и не хотите его менять, то могли бы вместо этого присоединить к каждой опции даты день недели (например, «15 марта — понедельник»); хотя это потребует включения месяца в каждое значение выпадающего меню с днями недели или, в случае применения отдельного выпадающего меню для выбора месяца, вам понадобится динамически обновлять названия дней в зависимости от текущего выбранного месяца.
10. Сделайте отчетливую область касания для каждого пункта списка
Проблема: В некоторых списках пользователи просто не понимают, где нужно нажать для выбора пункта.
Можно ли дотронуться до всего элемента? Или только до названия товара? И как насчет пиктограммы? В течение тестирования возникало множество проблем, так как участники не были уверены, где нужно дотронуться, чтобы выбрать пункт из списка. Общепризнанно хуже всего это происходило на тех вебсайтах, где высота пунктов списка была больше рекомендуемой половины экрана. Фактически одна из опрашиваемых полностью застряла и так и не смогла закончить покупку.
Проблема ни в коем случае не ограничилась теми вебсайтами, где пункты списка были слишком высокими; на них она просто увеличилась. Вопрос также распространяется на вебсайты, пункты списка которых были нормальными по размеру, но область касания была нечетко выражена, что серьезно ограничивало участников, и даже приводило к отказам от дальнейшей покупки.
Опрашиваемым было просто неясно, что на этой странице можно щелкнуть, а что нет. Обратите внимание на очень непоследовательные стили ссылок. Оранжевый цвет иногда применяется для заголовка, иногда для элемента списка. Разграничители применяются как для разделения элементов списка, так и разделения элементов текста. Какой-то текст одного оттенка синего цвета, что иногда означает ссылку, тогда как остальные ссылки более темного синего цвета и подчеркнуты. Уже запутались? Участники тоже.
Заметьте, что участник пытался щелкнуть на метку «Самая низкая цена», считая, что это кнопка выбора показанного рейса. Кроме того, первостепенная кнопка видна нечетко, а пункт списка слишком длинен. В сочетании эти две дизайнерских находки – верный способ оставить некоторых пользователей в недоумении относительно дальнейшего продвижения.
Слева: Этот участник не знал, что нажать на вебсайте United для продолжения. Предположительно, это было вызвано единственным результатом. Когда нет опций, между которыми можно сравнивать и выбирать, участнику опроса непонятно, что выбрать. Справа: Многие участники на вебсайте Fandango не поняли иконку билета и ее значение. Вместо этого они пришли к мнению, что фильм шел только в тех кинотеатрах, где показана кнопка «Купить» (что было неверно).
На изображениях вверху показаны всего несколько из множества случаев, когда участникам было непонятно, на какие из элементов можно нажимать, каково различие между разными областями касания и, еще более важно, куда нажать, чтобы выбрать пункт в списке. Вебсайты с наименьшим количеством подобных проблем отвечали многим из этих рекомендаций:
Сделайте так, чтобы можно было нажать всю область элемента. В частности, пиктограмма, заголовок продукта и стоимость должны нажиматься и вести к странице товара.
Определите заголовку стили ссылки (с помощью своего основного стиля для текстовых ссылок).
Обозначьте виртуальное пространство со стрелкой или похожий визуальный ключевой элемент, показав, что весь пункт списка перенаправит пользователя к следующему этапу процесса.
Обдумайте отдельные кнопки «Купить сейчас» или «Выбрать» для очень длинных пунктов списка — например, когда элемент списка можно легко спутать с фрагментами информации, а не собирательным целым, на которое можно нажать.
Избегайте множества областей нажатия в пределах одного визуального элемента — особенно ссылок или кнопок внутри пункта списка, ведущих к разным страницам.
Дизайн вебсайтов мобильной коммерции
Отдельно от их практического применения, эти 10 рекомендаций, надеемся, дали вам представление о том, как действительно сложно создать дизайн сайта мобильной коммерции. Это не просто вопрос масштабирования и добавления медиазапросов; это полностью новая платформа, и вести процесс балансирования особенно трудно из-за выполнения сложных задач, таких как поиск продукта и его сравнение, и многоэтапных процессов вроде входа на сайт. Во многом создание и оптимизация вебсайта мобильной коммерции гораздо сложнее и зачастую требует более «интеллектуальных» свойств, чем традиционный сайт электронных продаж для настольного компьютера. Неудивительно, что IBM отчитывается о среднем уровне показателей эффективности мобильной коммерции, которые составляют примерно половину от уровня показателей эффективности электронной коммерции на настольных компьютерах.
В общем, чем более сложны характеристики мобильного вебсайта, тем чаще впечатление от него будет значительно отличаться от его настольного собрата. Чем больше между ними разница, тем сильнее аргументация в пользу отдельного мобильного вебсайта. Конечно, поддержка двух версий одного и того же сайта достаточно проблематична, особенно их поддержание (содержимого, кода и дизайна). В некоторых случаях адаптивный дизайн – самое лучшее решение, но он сильно зависит от размера и сложности сайта, а также от возможностей вашей организации. Это проблема со множеством неисследованных белых пятен и хорошими аргументами как за, так и против отдельного мобильного вебсайта.
Если вам удастся этого добиться, создав дизайн mobile first, то адаптивный дизайн может оказаться реально великолепным — не только в деле его поддержания, но и пользовательского впечатления. Однако отдавайте себе отчет в том, что если ваш существующий сайт сложный, то простого масштабирования его к разным устройствам для обеспечения отличного впечатления мобильных пользователей будет недостаточно. И если путаница с существующей структурой полной версии сайта и контентом – это не выход, то вам, возможно, придется создать отдельный мобильный сайт для того, чтобы произвести достойное впечатление — хотя параллельное поддержание содержимого и кода на двух отдельных платформах может оказаться дорогим и малоприятным занятием.
Итак, правильное создание вебсайта мобильной коммерции имеет тенденцию быть очень ресурсоемким делом, так как вам нужно просчитать все нюансы. Но возможности представляются отличные. Это целый новый мир, и установление наилучших методик займет некоторое время. Не нужно тратить время и деньги на заурядный вебсайт мобильной коммерции. Да, создание отличного сайта потребует значительных инвестиций, но его потенциальная отдача тоже велика. Мобильная коммерция открывает окно возможностям; она дает вам способ отличиться от конкурентов и великолепно позиционировать себя для захвата сегмента рынка, который по прогнозам достигнет оборотов в 86 млрд. долларов к 2016г.
Примечание: Прочесть еще о правилах юзабилити мобильной коммерции можно в (небесплатном) отчете «Юзабилити мобильной коммерции (M-Commerce Usability) автора этой статьи.
Автор: Christian Holst
Источник: //uxdesign.smashingmagazine.com/
Редакция: Команда webformyself.
Комментарии (2)