Чи так зрозумілий користувачеві інтерфейс Вашого продукту, як Вам здається? Чи зможе користувач швидко оцінити його гідності і залишитися з Вами надовго?
У статті нижче я розгляну концепцію «навчання у взаємодії» на прикладі абстрактної web-системи. Даний підхід добре можна пояснити прикладом із сучасного ігрового світу. Спочатку ви проходите tutorial. Вам на плечі не вішають відразу кілотонни навчального матеріалу. Вас ведуть по ранній стадії гри, в потрібний час видаючи підказки. Наприклад, при першій взаємодії з новим об'єктом гри. Накопичується позитивний досвід. Ви навчаєтеся взаємодіяти. Ризикну припустити, що швидше за все Ви вважаєте себе просунутим користувачем, коли мова стосується додатків. Як і більшість з них ви миттєво тиснете на кнопку «Пропустити »/« Приступити до роботи»...
До речі, якщо ви використовуєте Figma, я рекомендую звернути увагу на наші готові дизайн-системи. Вони допомагають фрілансерам завершувати більше замовлень на місяць, програмістам дозволяють створювати красиві додатки самостійно, а тимліди «пробігають» спринти швидше, використовуючи готові дизайн-системи для командної роботи.
А всі у вас серйозний проект, то наша команда готова розгорнути дизайн-систему всередині організації на базі наших напрацювань і підігнати під конкретні завдання, використовуючи Figma. Web/desktop, так і будь-який мобайл. З React/React Native ми теж знайомі. Пишіть у Т: @kamushken
Насправді, я теж майже завжди відразу тисну на кнопку «Пропустити». Це нормально, тому як в даний момент я не готовий багато запам'ятовувати. А після натискання я іноді шкодую про содяне)) І точно таким же поглядом, як дівчина вище починаю «дивуватися в екран». Тому режим навчання «про-все-відразу» перед стартом роботи з системою - слабоефективний. На щастя, не всі системи вимагають навчання. Є досить очевидні (airbnb), а є й такі, з якими спершу доведеться повозитися (bitrix). Це не означає, що така система погана. Це означає, що вона вирішує настільки складні завдання, що це призвело до непростого інтерфейсу. Вам просто потрібно витратити випереджений час, щоб освоїтися. Можливо Ви пізніше зрозумієте, що це і «правда зручно»...
Давайте розглянемо кілька потенційних сценаріїв видачі підказок на прикладі абстрактного інтерфейсу web системи.
Користувач входить до системи. Припустимо, ваша мета з головної сторінки залучити користувача в екшн. Якщо даних багато, можливо Ви хочете, щоб спочатку він отримав досвід взаємодії з фільтрами. І ви вважаєте, що вони складні, тоді праву частину можна використовувати для допомоги.
Користувач бачить інформацію тільки про фільтри. Тому що вони грають основну роль у цьому розділі. Ми будемо вважати, що він все прочитав, після того, як зробив перший клік по будь-якому елементу у фільтрі. Якщо він зробив onfocus за першою формою, значить він готовий починати роботу. Вважаємо, що неможливо читати текст і одночасно клацнути за елементами фільтра:) Все-таки нарешті він зробив свій перший клік. Готовий! Тепер саме час показати йому першу видачу результатів.
Альтернативний варіант опису роботи з фільтрами: показати, що тлом є контент. Змусити до прочитання підказки, щоб unlock-нуть контент, взаємодіючи з фільтрами. Це можна вважати нагородою за дії. Досить агресивний режим підказки, що вимагає в 100% випадків підтвердження від користувача (клік на «Поїхали!»).
Актуально до використання для випадків, коли без нових знань ви не хочете дати можливість користувачеві продовжити. У обох варіантів є свої переваги. У будь-якому випадку нас ведуть до отримання першого контенту. Отже, ми бачимо картки. Давайте вважати, що знизу кожної є абстрактний функціонал, призначення якого ми хочемо уточнити. Цю проблему вирішить блок-підказка, розташована в контексті.
«- Добре, якщо мені потрібно це знати прямо зараз, тоді спасибі, що повідомили і підкреслили це!» - як би подумки вимовляю я. А що якщо другий інструмент теж потенційно може викликати питання? Тоді, спробуємо опинитися в балансі подачі підказок і покажемо другу трохи нижче. Ми починаємо скролити нижче і натикаємося на другу.
Все. Нарешті цей крок пройдено. Нам дають свободу у фільтрах. Ми підбираємо критерії і отримуємо видачу. Давайте будемо вважати, що тепер у нас з'явилося пошукове поле нагорі. Звичайний пошук. Наприклад, за заголовками карток. Але це занадто просто. Давайте будемо вважати, що у нас пошук такий же крутий як у Google. Тоді по кліку на пошукове поле нам розкажуть про те, як можна скористатися розширеними перевагами пошуку.
Бачите? Ми отримали підказку ні раніше ні пізніше потрібного нам моменту. У нас є чергове знання - в цій системі пошук як у Google:А ще можна застосувати трюк «раптового ускладнення». Нас спочатку заманюють простою пошуковою формою, але при введенні перших символів вже «залякують» вимогою конкретики. Можливо тут ще й виграш у звільненні шапки від додаткових контролів.
Таким чином ми вказуємо системі за яким типом контенту проводити пошук. Зрештою завжди можна клікнути повз цього попапу, якщо хочемо шукати скрізь. А якщо він потрібен, то onhover-дія маніпулятором мишу поверх пошукової форми його знову покаже. Упс. Мене вже понесло в іншому напрямку. Адже ми ж зараз тільки про підказки.
Давайте тепер підемо в інший розділ. Наприклад у «Карта світу». Взагалі UX майже всіх карт в наші дні ідентичний. Але якщо у Вашій карті є щось особливе про що повинен знати Ваш користувач, то саме час зараз про це сказати.
Цей вид підказки є опціональним. І він не скасовує взаємодію з картою. Швидше за все клік в будь-яку зони карти буде апріорі вважатися фактом прочитання нами зеленого попапу і він закриється. На свій страх і ризик використовуйте режим, коли без кліка підтвердження взаємодіяти з картою не можна. Раптом про щось треба обов'язково попередити.
Підказка також може мати таймінг, після якого вона автоматично зникне з екрану. Це середній випадок, який підійде для ситуацій, коли потрібно щось повідомити користувачеві, але немає необхідності переривати його сценарій. Нехай він зробить клік на карті. Таймінгова підказка з'являється зверху. Якщо таких підказок багато в системі, то через кілька ітерацій виробиться досвід про те, що таймінгові випадають вгорі. І якщо ті, хто вимагає реакції - завжди знизу, то це теж може запам'ятатися. Звичку «закривати на автоматі» ніхто не відміняв.
Якщо після першого кліка нам важливо пояснити, що існують додаткові комбінації завершення сценарію, то застосовуємо більш агресивний стиль підказок. Такий підхід має право, якщо є інші шляхи досягнення мети користувачем. Коли вони рівнозначно хороші, можна описати кожен з них. А вибір залишиться за користувачем.
Необхідність такого підходу може пояснюватися необхідністю повністю захопити увагу користувача після першого кліка. Але є і компромісний і менш агресивний варіант виконання.
Попап потішається контекстуально. Показує зв "язок з подією - клік. Але можливість працювати з картою не пропадає. Судячи з усього закрити такий попап можна як кліком в «ОК» так і кліком в будь-яку частину карти.
Ну і так далі для всієї системи за подібною логікою. Головне не втрачати з уваги важливу деталь: спочатку подія, потім підказка по конкретному елементу. Так ви зберігаєте контекст зв'язку. Подією може бути як onclick, так і onhover. Друге варто застосовувати у випадках, коли у вас є максимальна впевненість, що потягнувшись до елемента, швидше за все користувач клікне. Варто також дотримуватися балансу. Загострюйте увагу підказками тільки на важливих деталях системи, які допоможуть користувачам ефективніше досягати їх цілей. Будь-які ефекти анімації посилюють залученість на тлі повністю статичного інтерфейсу.
Давайте тепер узагальнимо типи підказок, які я описав вище. Пропоную розташувати їх в порядку зростання від самих лояльних, до максимально агресивних. Ступінь агресивності буде вимірюватися в нашому бажанні залучити користувача до вивчення вмісту підказки.
Підказка-таймінг. Найлояльніший спосіб. Не потребує залучення користувача для закриття користувача. Після закінчення таймера підказка сама зникає. Не потребує уваги користувача на пересування курсора, щоб її позбутися.
Попап-підказка. Середній ступінь лояльності. Дозволить сильніше залучити користувача, якщо породження відбувається в місці події, наприклад попап поруч з кліком. Вимагає від користувача дії щодо закриття натисканням на підтверджувальну кнопку або кліком за межами попапу.
Підказка-блок. Дозволяє інформувати користувача в режимі середньої агресивності. Не перешкоджає взаємодії з функціоналом системи, але з іншого боку, часто вимагає від користувача дії, щоб підказку приховати.
Блокуюча підказка. Найагресивніший режим подачі інформації. Використовується поверх необхідного функціоналу з подальшим його блокуванням, поки не послідує підтверджуюча дія від користувача.
Вивід
Режим «навчання у взаємодії» є безумовно оптимальним, якщо порівнювати з режимом «все-і-відразу». Ви не перевантажуєте користувача інформацією, показуючи підказки суворо контекстуально потенційній першій взаємодії.
Залежно від важливості підказки ви можете використовувати різні способи привернення уваги: від найбільш лояльного, до найбільш агресивного (коли без вимушеного кліка не отримати контент або функціонал).
PS: Та й не забувайте «вішати» спливаючі тултіпи про онховер на елементи, що вимагають цього. Хто принаймні про це пам "ятає, той робить наш світ кращим!
