10 «розчарувань» користувачів інтернетом та як їх виправити
Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!
Я — Євгеній Вінійчук, у розробці вже понад 7 років. У компанії Youshido виріс від Trainee до Lead Front-end Developer. Створював сайти та застосунки як для стартапів, так і для бізнес-гігантів — Viasat, Jacobs, Pepsi, Tuborg тощо. Зараз поєдную функції тімліда та Senior Software Engineer.
У цій статті я хочу поділитися рейтингом
1. Автозаповнення форм
Це проблема, з якою ми стикаємося чи не щодня. Щоб спростити процес оплати товарів і послуг в мережі, браузери пропонують автоматично заповнити поля з іменем, картковими даними тощо. Однак, автозаповнення деяких значень хронічно не спрацьовує.
Перше, що спадає на думку — автозаповнення та copy/paste номеру телефону. Так, вставка у форматі +38 здебільшого відбудеться неправильно. При цьому відредагувати перші цифри номеру неможливо, адже курсор відскакує в кінець. Доводиться видаляти та вводити всі цифри спочатку.
Також поля для вводу імені можуть не сприймати латинку та вимагати кирилицю. Подібні дрібниці постійно крадуть час і псують настрій користувачів.
Деякі поля можуть містити обмеження, через які їх неможливо заповнити навіть вручну. Наприклад, у поле «поштовий індекс» програма дозволяє ввести виключно п’ятизначне число. Водночас у Нідерландах до числових індексів також додають літери, а у США існує формат з тире та додатковими знаками. І добре, якщо це зроблено навмисно (бо сервіс, наприклад, не підтримує роботу зі США, про що повідомили користувача), а не тому, що розробники банально не врахували регіональні особливості. Разом із обмеженням на введення літер часом поля також можуть ненавмисне блокувати копіювання та вставку, або ж взагалі переміщення курсору стрілочками. Відтак, через недоладну маску продукт автоматично відсікає частину потенційних клієнтів.
Проблеми виникають і з «розумними» полями, які намагаються передбачити, що саме буде вводити користувач. Наприклад, вони можуть не дозволяти вписати шосту годину ранку в форматі 06. Натомість користувач мусить ввести цифру без нуля та сподіватися, що програма ідентифікує її як шосту ранку, а не шосту вечора. Ще цікавіше, коли таке поле автоматично конвертує введене значення з
2. Втрата початкового наміру після виконання обов’язкової додаткової дії
Наприклад, щоб поставити «лайк», додати товар у «обране» чи оформити замовлення, деякі сайти вимагають авторизації. Однак після виконання цієї додаткової дії користувач потрапляє на стартову сторінку та мусить заново шукати товар, який хотів придбати. Тобто початковий намір зруйновано, і зовсім не факт, що спантеличений клієнт матиме бажання завершити покупку.
3. Push-сповіщення
Перехід за push-сповіщенням часто не відображає тієї інформації, про яку в ньому написано. Наприклад, доставка їжі пропонує оновлене меню в ресторані, або техномаркет — акційну ціну. Однак при спробі перейти за сповіщенням замість цього запускається стартова сторінка застосунку. Тобто користувачеві так і не показали того, що пропонували. Ба більше, після цього сповіщення зникне, а розчарований клієнт з великою вірогідністю не запам’ятав назву закладу чи модель продукту. Коли така ситуація повторюється, перестаєш довіряти та просто ігноруєш повідомлення, або ж вдаєшся до хитрощів, щоб попри все отримати бажану інформацію.
4. Примусове відкриття додатку замість веб-сторінки
Типова ситуація — користувач на смартфоні пише пошуковий запит «придбати пилосос Київ» й отримує перелік магазинів. Багато великих торгових мереж мають власні додатки, які до того ж пропонують «mobile only price», тобто знижку при купівлі через застосунок. Далі користувач переходить за посиланням, і в нього відкривається встановлений додаток замість веб-сторінки. І тут починається — замість певного товару чи категорії застосунок може відкрити головну сторінку, або ж там може бути менше інформації, ніж на мобільній веб-версії магазину. Таким чином, ми застрягли, і єдине розв’язання проблеми — видалення додатку.
Найцікавіший приклад, який стався зі мною — з мобільного телефону я перейшов за посиланням з листа, де мав заповнити певну інформацію. Звичайно, мені відкрився додаток, в якому написано: «Для продовження заповнення інформації відкрийте веб-версію застосунку». Завіса :)
5. Контекстна реклама
Може перетворитися на підступну проблему, здатну зіпсувати найкращий сюрприз. Шукаєте подарунок близьким на свято? Спливаючі вікна у вашому браузері неодмінно повідомлять їм, яку модель телефону вони отримають на день народження або Новий рік. Таке сталося зі мною, тому я більше не ризикую обирати подарунки без режиму приватного перегляду.
6. Потрапляння листа у спам
Проблема, що стала буденністю. Надсилаючи користувачеві листа, сервіси майже завжди попереджають, що слід перевірити спам. Мені дуже подобається висловлювання, що технологіями неможливо повністю розв’язати проблеми людської ментальності, що виливається у значні кошти, які деякі компанії витрачають на розв’язання цього питання.
7. «Час дії сесії вийшов»
Свіжий приклад — заповнення складної форми на отримання візи на веб-сторінці посольства. Система вимагала заповнити дані про рідних, для чого потрібно було їм зателефонувати. І поки ми шукали документи, термін поточної сесії сплив, і довелося півгодини заново заповнювати форму.
8. Різні версії сайтів
Внаслідок A/B-тестування, або ж коли користувачі знаходяться в різних країнах, один і той самий додаток може виглядати зовсім по-різному. Через це часом трапляються конфузи, коли у відповідь на фразу «натисни на кнопку зверху» можна почути від співрозмовника «у мене немає цієї кнопки».
9. Відсутнє повідомлення про отримання інформації від користувача
Особливо, якщо це придбання товару з сайту маловідомої компанії або в іншій країні. Не отримавши лист-відповідь з номером заявки, користувач не має впевненості, що продавець дійсно отримав замовлення та зв’яжеться з ним щодо доставки. Це чимось схоже на те, коли офіціант повторює ваше замовлення, перш ніж передати його на кухню. Інакше завжди є ризик, що вас не так почули й приготують щось інше.
10. Підтвердження небезпечних дій
Натискання деяких кнопок викликає у користувачів панічний страх щось «зламати». Уявіть, що ви витратили кілька годин, обираючи важливі для вас покупки. В момент, коли ви нарешті вирішили оформити замовлення, вона вже заповнена десятками відкладених «про всяк випадок» товарів. Деякі з них більше не актуальні. Однак, прибираючи зайве, існує ризик ненароком видалити потрібні речі. І тоді доведеться починати все з початку. Але якщо товар ще можна знову знайти, то деякі дії призводять до більших неприємностей. Так, це може бути платіжна інформація (так званий payment method), instance серверу в чомусь на кшталт Google Cloud, чи випадковий «свайп вліво» на сторінці, на якій ви вже заповнили багато інформації. Або ж мій особистий приклад із спортивним додатком нижче.
Під час тренування з бігу я зупинився на світлофорі та поставив тренування на паузу на спортивному годиннику. Однак натомість випадково натиснув кнопку «стоп». В результаті, замість десятикілометрової пробіжки, я отримав два тренування по 6 і 4 км. Через це я втратив реальну картину тренування, що особливо неприємно, коли маєш 6 занять на тиждень та постійно слідкуєш за своїм прогресом. Щоб виправити проблему, довелося придбати інший застосунок за $12, що допоміг «склеїти» розірване тренування.
По-справжньому зручне розв’язання цієї проблеми реалізували в іншому додатку для бігу, де необхідно кілька секунд утримувати кнопку «стоп», перш ніж тренування завершиться. Цим розробники унеможливили випадкове завершення тренування. Більшості «небезпечних» дій в Інтернеті також можна запобігти, уточнивши у користувача, чи підтверджує він власне рішення.
Як уникнути цих помилок
На мою думку, більшість проблем виникають через те, що ми, розробники, забуваємо ставити себе на місце користувача та не відтворюємо реальні сценарії використання продукту.
Ось кілька практичних порад, які я використовую в своїй роботі, щоб поглянути на неї «сторонніми очима»:
- Мати власний перелік «граблів», на які ви неодноразово натикались, та щоразу проходитись цим переліком під час розробки відповідної категорії функціоналу. Такий список може мати як компанія, так і розробник індивідуально. З мого досвіду, такі списки особливо корисні у випадку систематичного повторення помилок.
- «Вимкнути» мозок розробника і ввімкнути «користувача недумаючого». Тобто, почати натискати на все, на що можливо натиснути, та заповнювати поля першим, що спаде на думку: спробувати перевести від’ємну суму коштів, ввести емейл з двома знаками «@», заповнити поле одним дуже довгим словом, відкрити модальне вікно й натиснути в браузері на кнопку «назад». У такий спосіб ви дозволяєте мозку будувати зв’язки, які ви нізащо б не отримали, виконуючи «розумне» тестування. Під час цього процесу ви можете знайти багато різних помилок або непродумані сценарії користування системою, оскільки дозволили мозку експериментувати й зняли всі обмеження.
Якщо кожен робитиме «як для себе» та відповідатиме на запитання «а яким є наш користувач», ми можемо значно підвищити зручність використання сервісів, а відтак їхню монетизацію.
29 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів