Десять аспектів юзабіліті мобільної комерції

19

Від автора: всі говорять про мобільних продажах. Деякі веб-сайти електронної комерції (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’е (ліворуч), вони перенаправляються на субсторінку (посередині). Учасники нашого тестування чітко бачили, що все ще знаходяться на сторінці певного товару (із-за збільшеного зображення), але не розуміли, куди дівається решта сторінка цього товару (праворуч).

Це негайно з’ясовувалося при тестуванні web-сайтів, що пропонують збільшені зображення, які переміщали користувачів на окрему субсторінку продукту, як на вищенаведеному прикладі сайту 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, як тут:

<input type=»text» autocorrect=»off» />

8. Робіть поля досить довгими для повного показу звичайних даних (і ставте над полями мітки)

Проблема: Користувачі нелегко помічають помилки, і тим більше виправляють їх, коли поле занадто коротке і не може показати всі введені дані.

З-за маленьких розмірів екранів мобільних пристроїв поля форми часто занадто короткі і не дозволяють користувачам перевірити себе перед відправкою даних, і виправити помилки валідації дуже важко, тому що не видно всі введені дані повністю.

«Не бачу, що надрукував. Рис. Значить, все видалю і напишу заново». На сайті REI помилка валідації поля адреси електронної пошти, яке було дуже коротко для повного показу введених даних, зробило для користувача неможливим бачити саму помилку. Спробувавши переглянути введений текст, учасник опитування випадково вимкнув як інструмент вибору тексту iOS, так і інструмент заміни тексту.

Занадто короткі поля форми представляли проблему для багатьох опитаних, які намагалися перевірити правильність своїх даних перед їх відправкою. Вони часто скаржилися приблизно так: «Не можу розглянути, чи однакова пошта, коли поле вводу адреси недостатньо довга». Деякі приклади наведені внизу.

Зліва: поле введення електронної пошти Amazon занадто коротке, незважаючи на достаток білого простору. Посередині: поле кредитної картки United показує тільки 15 символів, незважаючи на те, що номери більшості карт складаються з 16 цифр. Праворуч: поля введення пошти macy’s занадто короткі для перевірки даних тими користувачами, які хочуть переконатися, що два введених ними адреси збігаються.

Так як зробити помилку при друкуванні на мобільному пристрої легко, недостатньо довгі поля, не надають користувачам можливості перевірити свої дані перед відправкою, дуже погано впливають на їх враження. Ще гірше те, що вони нескінченно ускладнюють виправлення будь-яких помилок валідації.

Зверніть увагу, що у випадку з Amazon і більш раннім прикладом з REI, білого простору достатньо для того, щоб зробити полі набагато довше, тоді як у двох інших прикладах немає додаткового місця для збільшення полів з-за вирівняних по лівій стороні міток. Саме з цієї причини мітки повинні бути поміщені над полями, щоб можна було використовувати весь простір і відобразити дані користувача повністю (при нормальному розмірі шрифту). Показувати мітки зліва від полів можна тільки коли пристрій розгорнуто в альбомній орієнтації (що докладно пояснюється в «Юзабіліті мобільних форм: розташовуйте мітки над полями» (Mobile Form Usability: Place Labels Above the Field)).
Адекватна ширина рядків для пошти та адрес – на весь екран. Потім встановіть розмір шрифту полів, щоб можна було повністю показати дані розумної довжини, такі як [email protected] (Розподіл довжини символів нашого списку розсилки показує, що 96% адрес електронної пошти складаються з 30 і менше символів.)

9. Дайте користувачам можливість перевірити введений день і дату

Проблема: Застосування текстових полів для дат вимагає від користувача непотрібного обмірковування і при виборі може викликати серйозні помилки.

Під час тестування вебсайти, надають для вибору дати тільки просте текстове поле або випадаючий діалог, представляли труднощі для 80% учасників.

Ця учасниця виявилася в числі 80%, які не були впевнені, яким числом була «ця п’ятниця». Тому вона вирішила порахувати дні на пальцях, бажаючи переконатися, що обрала вірний.

Так сталося і з Southwest (на якому для вибору місяця і дня застосовуються випадають діалоги), і з United (який показує текстове поле для написання ДД/ММ/РРРР). На обох цих вебсайтах трапилися такі сцени:

Деяким учасникам довелося рахувати дні на пальцях (як показано вище).

Половина опитаних вийшли з сайту і відкрили прикладна програма-календар телефону, щоб перевірити дату своєї поїздки на вихідних (підтвердити цю п’ятницю»). У вищенаведеному випадку перевірка за календарем не вдалася, тому що учасниця перевірила 15 червня замість 15 липня і в підсумку придбала квиток на літак на «ці вихідні», який вилітав в неділю і повертався у вівторок.

Нарешті, деякі боролися з набором з клавіатури і використанням інструменту вибору тексту для введення правильної дати на вебсайті, де для вибору дати застосовується текстове поле.

За контрастом, на трьох тестованих вебсайтах, забезпечили графічний інтерфейс вводу дат у вигляді календаря (а саме: Enterprise, Avis та 1-800-Flowers – дивіться вище), не виникло жодної з цих проблем, а учасникам в основному сподобалася можливість перевірити обрані день і дату. Потенційно це вберегло покупців від неправильного вираховування і «перевірки» неправильних вихідних (про що писалося вище) і, таким чином, бронювання на неправильну дату.

Хоча на настільному комп’ютері це теж жахливо дратує (так як користувач помічає на ньому помилки ненабагато краще), серйозність впливу на враження користувача мобільного пристрою набагато сильніше, коли справа доходить до виправлення помилкових даних, тому що редагувати спрощені дані на трьох-четырехдюймовом сенсорному екрані набагато тяжче, ніж застосувати мишу або клавіатуру на десктопі. Більш того, замовлення квитків на неправильний день на настільному комп’ютері менш імовірний, тому що форма бронювання та окремий додаток-календар можна відображати поруч — тоді як на мобільному пристрої зараз можна бачити тільки щось одне.

Отже, завжди забезпечте такий інтерфейс, який дозволяє користувачеві перевірити день тижня на обрану дату. Однією з можливостей є відображення календарного інтерфейсу, де користувач спокійно вибере потрібну йому дату. Так дійсно спрощено інтерфейс вибору і, що ще більш важливо, користувачеві буде дано шанс перевірити день тижня. Якщо ви вже використовуєте для введення дат випадаюче меню і не хочете його міняти, то могли б замість цього приєднати до кожної опції дати день тижня (наприклад, «15 березня — понеділок»); хоча це потребуватиме включення місяця в кожне значення випадаючого меню за днями тижня або, у разі застосування окремого випадаючого меню для вибору місяця, вам знадобиться динамічно оновлювати назви днів в залежності від поточного місяця.

10. Зробіть виразну область дотику для кожного пункту списку

Проблема: В деяких списках користувачі просто не розуміють, де потрібно натиснути для вибору пункту.

Можна доторкнутися до всього елемента? Або тільки до назви товару? І як щодо піктограми? Протягом тестування виникало безліч проблем, так як учасники не були впевнені, де потрібно доторкнутися, щоб вибрати пункт зі списку. Загальновизнано найгірше це відбувалося на тих вебсайтах, де висота пунктів списку була більше рекомендованої половини екрана. Фактично одна з опитуваних повністю застрягла і так і не змогла закінчити покупку.

Проблема ні в якому разі не обмежилася тими вебсайтами, де пункти списку були надто високими; на них вона просто збільшилася. Питання також поширюється на сайти, пункти списку яких були нормальними за розміром, але область дотику була нечітко виражена, що серйозно обмежувало учасників, і навіть призводило до відмов від подальшої покупки.

Опитуваним було просто незрозуміло, що на цій сторінці можна клацнути, а що ні. Зверніть увагу на дуже непослідовні стилі посилань. Помаранчевий колір іноді застосовується для заголовка, іноді для елемента списку. Разграничители застосовуються як для розділення елементів списку, так і поділу елементів тексту. Якийсь текст одного відтінку синього кольору, що іноді означає посилання, тоді як решта посилання більш темного синього кольору і підкреслені. Вже заплуталися? Учасники теж.

Зауважте, що учасник намагався натиснути на позначку «найнижча ціна», вважаючи, що це кнопка вибору показаного рейсу. Крім того, першочергова кнопка видно нечітко, а пункт списку надто довгий. У поєднанні ці дві дизайнерських знахідки – вірний спосіб залишити деяких користувачів в подиві щодо подальшого просування.

Зліва: Цей учасник не знав, що натиснути на вебсайті United для продовження. Ймовірно, це було викликано єдиним результатом. Коли немає опцій, між якими можна порівнювати і вибирати, учаснику опитування незрозуміло, що вибрати. Праворуч: Багато учасників на вебсайті Fandango не зрозуміли іконку квитка та її значення. Замість цього вони прийшли до думки, що фільм йшов тільки в тих кінотеатрах, де показана кнопка «Купити» (що було невірно).

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

Зробіть так, щоб можна було натиснути всю область елемента. Зокрема, піктограма, заголовок продукту і вартість повинні натискатися і вести на сторінці товару.

Визначте заголовку стилі посилання (з допомогою свого основного стилю для текстових посилань).

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

Обміркуйте окремі кнопки «Купити зараз» або «Вибрати» для дуже довгих пунктів списку — наприклад, коли елемент списку можна легко сплутати з фрагментами інформації, а не збірним цілим, на яке можна натиснути.

Уникайте безлічі областей натискання в межах одного візуального елемента — особливо посилань або кнопок межах пункту списку, що ведуть до різних сторінок.

Дизайн веб-сайтів мобільної комерції

Окремо від їх практичного застосування, ці 10 рекомендацій, сподіваємося, дали вам уявлення про те, як дійсно складно створити дизайн сайту мобільної комерції. Це не просто питання масштабування і додавання медиазапросов; це повністю нова платформа, і вести процес балансування особливо важко з-за виконання складних завдань, таких як пошук продукту і порівняння, і багатоетапних процесів ніби входу на сайт. У чому створення та оптимізація web-сайту мобільної комерції набагато складніше і часто вимагає більш «інтелектуальних» властивостей, ніж традиційний сайт електронних продажів для настільного комп’ютера. Не дивно, що IBM звітує про середній рівень показників ефективності мобільної комерції, які становлять приблизно половину від рівня показників ефективності електронної комерції на настільних комп’ютерах.

Загалом, чим більш складні характеристики мобільного вебсайту, тим частіше враження від нього буде значно відрізнятися від його настільного побратима. Чим більша між ними різниця, тим сильніше аргументація на користь окремого мобільного сайту. Звичайно, підтримка двох версій одного і того ж сайту досить проблематична, особливо їх підтримку (вмісту, коду та дизайну). У деяких випадках адаптивний дизайн – найкраще рішення, але він сильно залежить від розміру і складності сайту, а також від можливостей вашої організації. Це проблема з безліччю недосліджених білих плям і хорошими аргументами як за, так і проти окремого мобільного сайту.

Якщо вам вдасться цього досягти, створивши дизайн mobile first, то адаптивний дизайн може виявитися реально прекрасним — не тільки в його підтримки, але і користувальницького враження. Однак віддавайте собі звіт в тому, що якщо ваш існуючий сайт складний, то простого масштабування його до різним пристроям для забезпечення відмінного враження мобільних користувачів буде недостатньо. І якщо плутанина з існуючою структурою повній версії сайту контентом – це не вихід, то вам, можливо, доведеться створити окремий мобільний сайт для того, щоб справити гідне враження — хоча паралельне підтримання вмісту та коду на двох окремих платформах може виявитися дорогим і малоприємних заняттям.

Отже, правильне створення вебсайту мобільної комерції має тенденцію бути дуже ресурсномістким справою, так як вам потрібно прорахувати всі нюанси. Але можливості представляються відмінні. Це цілий новий світ, і встановлення найкращих методик займе деякий час. Не потрібно витрачати час і гроші на пересічний вебсайт мобільної комерції. Так, створення чудового сайту потребуватиме значних інвестицій, але його потенційна віддача теж велика. Мобільна комерція відкриває вікно можливостей; вона дає вам спосіб відрізнитися від конкурентів і чудово позиціонувати себе для захоплення сегмента ринку, який за прогнозами досягне обертів на 86 млрд. доларів до 2016г.

Примітка: Прочитати ще про правила юзабіліті мобільної комерції можна в (небесплатном) звіті «Юзабіліті мобільної комерції (M-Commerce Usability) автора цієї статті.