Новий користувач Вашого продукту — як йому допомогти?



чи зрозумілий користувачеві інтерфейс Вашого продукту, як Вам здається?

користувач Зможе швидко оцінити його переваги і залишитися з Вами надовго?

У статті нижче я розгляну концепцію «навчання у взаємодії» на прикладі абстрактної web-системи. Даний підхід добре можна пояснити прикладом сучасного ігрового світу. Спочатку ви проходите tutorial. Вам на плечі не вішають відразу кілотонни навчального матеріалу. Вас ведуть на ранній стадії гри, в потрібний час видаючи підказки. Наприклад, при першому взаємодії з новим об'єктом гри. Нагромаджується позитивний досвід. Ви навчаєтеся взаємодіяти. Ризикну припустити, що швидше за все Ви вважаєте себе просунутим користувачем, коли мова стосується додатків. Як і більшість із них ви миттєво тиснете на кнопку «Пропустити» / «Приступити до роботи»…



Насправді, я теж майже завжди відразу тисну на кнопку «Пропустити». Це нормально, тому що в даний момент я не готовий багато запам'ятовувати. А після натискання я іноді шкодую про содяном)) І точно таким же поглядом, як дівчина вище починаю «дивуватися в екран». Тому режим навчання «про-всім-відразу» перед стартом роботи з системою — слабоэффективен. На щастя, не всі системи вимагають навчання. Є досить очевидні (airbnb), а є й такі, з якими спершу доведеться повозитися (bitrix). Це не означає, що така система погана. Це означає, що вона вирішує настільки складні задачі, що це призвело до непростого інтерфейсу. Вам просто потрібно витратити опереденное час, щоб освоїтися. Можливо пізніше Ви зрозумієте, що це і «правда зручно»…

Давайте розглянемо декілька потенційних сценаріїв видачі підказок на прикладі абстрактного інтерфейсу web-системи.



Користувач входить в систему. Припустимо, ваша мета з головної сторінки залучити користувача в екшн. Якщо багато, то можливо Ви хочете, щоб спочатку він отримав досвід взаємодії з фільтрами. І ви вважаєте, що вони складні, тоді праву частину можна використовувати для допомоги.



Користувач бачить інформацію тільки про фільтри. Оскільки вони відіграють основну роль у даному розділі. Ми будемо вважати, що він все прочитав, після того, як зробив перший клік по будь-якому елементу в фільтрі. Якщо він зробив onfocus по першій формі, значить він готовий починати роботу. Вважаємо, що неможливо читати текст і одночасно клікнути по елементам фільтра :) Все-таки нарешті він зробив свій перший клік. Готовий! Тепер саме час показати йому першу видачу результатів.



Альтернативний варіант опису роботи з фільтрами: показати, що фоном є контент. Змусити до прочитання підказки, щоб unlock-нути контент, взаємодіючи з фільтрами. Це можна вважати нагородою за дії. Досить агресивний режим підказки, що вимагає в 100% випадків підтвердження від користувача (клік на «Поїхали!»).



Актуально до використання для випадків, коли без нових знань ви не хочете дати можливість користувачу продовжити. У обох варіантів є свої переваги. У будь-якому випадку нас ведуть до отримання першого контенту. Отже, ми бачимо картки. Давайте вважати, що знизу кожної є абстрактний функціонал, призначення якого ми хочемо уточнити. Цю проблему вирішить блок-підказка, розташована в контексті.



«Добре, якщо мені потрібно це знати прямо зараз, тоді спасибі, що повідомили і підкреслили це!» — як би подумки промовляю я. А що якщо другий інструмент теж потенційно може викликати питання? Тоді, спробуємо опинитися в балансі подачі підказок і покажемо другу трохи нижче. Ми починаємо скролл нижче і натикаємося на другу.



Всі. Нарешті цей крок пройдено. Нам дають свободу у фільтрах. Ми підбираємо критерії і отримуємо видачу. Давайте будемо вважати, що тепер у нас з'явилося пошукове поле вгорі. Звичайний пошук. Наприклад, по заголовкам карток. Але це занадто просто. Давайте будемо вважати, що у нас пошук такий же крутий, як у Google. Тоді по кліку на пошукове поле нам розкажуть про те, як можна скористатися розширеними перевагами пошуку.



Бачите? Ми отримали підказку ні раніше ні пізніше потрібного нам моменту. У нас є чергове знання — в цій системі пошук у Google :) А ще можна застосувати трюк «раптового ускладнення». Нас заманюють простий пошуковою формою, але при введенні перших символів «залякують» вимогою конкретики. Можливо тут ще й виграш у звільненні шапки від додаткових контролів.



Таким чином ми вказуємо системі за яким типом контенту проводити пошук. Зрештою, завжди можна клікнути повз цього попапу, якщо хочемо шукати скрізь. А якщо він потрібен, то onhover-дія маніпулятором миша поверх пошукової форми його знову покаже. Упс. Мене вже понесло в іншому напрямку. Адже ми ж зараз тільки про підказки.

Давайте тепер підемо в інший розділ. Наприклад в «Карта світу». Взагалі UX майже всіх карт в наші дні ідентичний. Але якщо у Вашій карті є щось особливе про що повинен знати Ваш користувач, то саме час зараз про це сказати.



Цей вид підказки є опціональним. І він не скасовує взаємодія з картою. Швидше за все клік в будь-яку зони карти буде апріорі вважатися фактом прочитання нами зеленого попапу і він закриється. На свій страх і ризик використовуйте режим, коли без кліка підтвердження взаємодіяти з картою не можна. Раптом про щось треба обов'язково попередити.



Підказка також може мати таймінг, після якого вона автоматично зникне з екрана. Це середній випадок, який підійде для ситуацій, коли потрібно щось повідомити користувачеві, але немає необхідності переривати його сценарій. Нехай він зробить клік на карті. Таймінгова підказка з'являється зверху. Якщо таких підказок багато в системі, то через кілька ітерацій виробиться досвід про те, що тайминговые випадають вгорі. І якщо вимагають реакції — завжди знизу, то це теж може запам'ятатися. Звичку «закривати на автоматі» ніхто не відміняв.



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



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



Попап пораждается контекстуально. Показується зв'язка з подією — клік. Але можливість працювати з картою не пропадає. Судячи з усього закрити такий попап можна кліком в «ОК» так і кліком в будь-яку частину карти.

Ну і так далі за подібною логікою. Головне не упускати з уваги важливу деталь: спочатку подія, потім підказка по конкретному елементу. Так ви зберігаєте сполучний контекст. Подією може бути як onclick, так і onhover. Друге варто застосовувати у випадках, коли у вас є максимальна впевненість, що потягнувшись до елементу, швидше всього користувач клацне. Варто також дотримуватися баланс. Загострюйте увагу підказками тільки на важливих деталях системи, які допоможуть користувачам ефективніше досягати їхніх цілей. Будь-які ефекти анімації підсилюють залученість на тлі повністю статичного інтерфейсу.

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


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


Попап-підказка. Середня ступінь лояльності. Дозволить сильніше залучити користувача, якщо породження відбувається в місці події, наприклад попап поруч з кліком. Вимагає від користувача дії щодо закриття натисканням на що підтверджує кнопку або кліком за межами попапу.


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


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

Висновок
Режим «навчання у взаємодії» є, безумовно, оптимальним, якщо порівнювати з режимом «все і відразу». Ви не перевантажуєте користувача інформацією, показуючи підказки суворо контекстуально потенційному першому взаємодії.
Залежно від важливості підказки ви можете використовувати різні способи залучення уваги: від лояльного до найбільш агресивного (коли без вимушеного кліка не отримати контент або функціонал).

PS: Так і не забувайте «вішати» спливаючі зринаючі підказки. про онховере на які вимагають цього елементи. Хто хоча б про це пам'ятає, той робить наш Світ кращим!


PPS: Я готовий до співпраці! Якщо Ви хочете поліпшити свою систему, зробити її інтерфейс більш зрозумілим і дружнім для користувача — пишіть в скайп creativiter, або на пошту kamushken@gmail.com
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.