«Дай палець і почнемо». Як писати діалоги в інтерфейсах

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Я Антон Чернічко, інтерфейсний письменник у ПУМБ, автор каналу про інтерфейсні тексти «Оплата пройшла успішно». Працював протягом 15 років як копірайтер і сценарист, а останні 3,5 роки — інтерфейсним письменником у кількох застосунках.

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

Тут не все добре з текстом, нижче розкажу, чому

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

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

Дай палець і почнемо

Ми стикаємося з діалогами щоразу, коли заходимо в банк із Touch ID.

Цей діалог повідомляє нам, що далі ми не пройдемо, якщо не проскануємо палець. Ну, він цього не повідомляє прямо, але ви зрозуміли.

Діалог при вході в ПУМБ

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

Ми бачимо діалоги, коли закриваємо незбережений документ у Ворді.

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

Також діалоги повідомляють нам іншу важливу інформацію для застосунку (бізнесу). Наприклад, щоб ми вимкнули блокування реклами.

Словник.юа

Або зареєструвалися, щоб користуватися всіма функціями застосунку.

Instagram

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

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

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

Діалог після спроби закриття публікації на Фейсбуці

Структура діалогу

У діалогу класична структура: заголовок, основний текст і кнопки.

OLX

Як правило, заголовки діалогів пишуться у вигляді запитань. Адже на те він і діалог: нас запитують, ми відповідаємо. Але не обов’язково — стверджувальні заголовки також гарні, все за ситуацією.

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

Кнопки — це дії користувача, якими він відповідає на запитання заголовка. Одну з них кнопка має підтверджувати, іншу, як правило, скасовувати.

Тепер трохи докладніше про кожен елемент діалогу.

Заголовок

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

Запитання в заголовку — чудовий приклад діалогу між користувачем і застосунком, коли застосунок запитує (заголовком), а користувач відповідає (кнопками).

Фейсбук

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

Наприклад, на скрині нижче в заголовку два запитання. Це робить його двозначним і може збити користувача. Краще прибрати «впевнені», залишивши тільки «вийти з магазину?»

iHerb

Основний текст

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

Chrome

Зазвичай тут слід розповісти про наслідки дій у робочому процесі, доступ до інформації та іншу важливу інформацію. Основний текст повинен не повторювати заголовок, але підтримувати і доповнювати його.

Ліміту на основний текст немає, але бажано вкластися в 1-3 рядки

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

iHerb

Кнопки

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

Підтверджувальні кнопки

Наприклад, «Видалити» або «Вийти».

Відхиляючі кнопки

Наприклад, «Скасувати», «Продовжити» або «Залишитися».

Підтверджувальні кнопки

Наприклад, «Зрозуміло» або «Добре».

Ось кілька рекомендацій щодо кнопок у діалозі.

1. Не слід називати кнопки «Так» або «Ні»

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

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

2. У діалогах має бути максимум дві дії

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

3. Кнопки повинні відповідати повідомленню заголовка

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

Слово в заголовку «Видалити» узгоджується з кнопкою «Видалити»

Щоб дізнатися більше про те, як писати кнопки, прочитайте мою статтю на цю тему.

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

У заголовку ми використовуємо запитання, а в запитанні слово, що відповідає за дію — «Вийти».

В основному тексті пояснюємо користувачеві, що буде, коли він вийде з публікації — «усі зміни будуть втрачені».

У кнопках ми даємо користувачеві варіанти, як відповісти на цей діалог: «Вийти» та «Продовжити».

Наостанок

Дякую, що прочитали цей гайд, — я вже готую наступний про пуш-повідомлення. Буде цікаво! А поки що прочитайте гайд, як писати помилки та кнопки. Заходьте на мій телеграм-канал «Оплата пройшла успішно». Там я розбираю вдалі і невдалі приклади інтерфейсних текстів та всяке різне про тексти в інтерфейсах.

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

Заходьте в гості до української спільноти юікс-райтерів «UX-райтери» — там обговорюють, поширюють, радяться та нетворкаються.

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Спасибо, интересно пишете!

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

Про кнопки приходит в голову еще парочка нюансов: их очередность и выделение.

С выделением все, кажется, просто — подсвечиваем жирностью текста/заливкой кнопки/ваш вариант то действие, которое хочется сделать желательным.

А вот с очередностью кнопок не очевидно — всегда ли утвердительное действие должно быть крайним справа (самым нижним в случае с вертикальной компоновкой)? Есть ли в этом какая-то логика?

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

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

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

Ещё диалоги делятся на модальные и немодальные. Немодальные — это если контекст управления можно переключить без закрытия диалога. Раньше под вендой такое часто писали. Пока не изобрели концепт газетного интерфейса.

А давайте скажемо розробникам мобільних додатків для банків і рітейлу страшний секрет — логінитись в додаток не дуже потрібно завжди як і використовувати інтернет:
1. коли я стою на касі і в мене питають QR/bar-code — то не треба в цей час логінитись через інтернет і пропонувати оновити додаток, просто покажи одразу той довбаний штрихкод або QR, особливо якщо супермаркет розташовано десь в підвалі торгового центру (непривіт Сільпо).
2. якщо мені треба глянути останні операції або дані картки в мобільному додатку банку — для чого інтернет? Наприклад в моно можна зайти без інтернету і глянути баланс, останні операції і базові налаштування, більшість інших банків — з мого списку приват, ексім, ощад, sense, abank, таском живуть в якійсь інакшій країні, де мабуть покриття інтернетом 110%.
Діалогові вікна не так бісять, як відсутній елементарний UX.

Це у «налаштуваннях» чекнути чекбокс «Не оновлювати»
Але буває що треба оновити бо інакше не працюватиме функція.
Тоді треба повідомлення на пів екрану — яка функція не працюватиме, якщо не оновити.
Проте складність реалізації мабуть відміняє всі ці зручності.

Дякую за класну статтю!

Звернула увагу на

«ви впевнені, що хочете...?» — це робить його двозначним і може збити користувача.

Дуже часто в англомовних інтерфейсах зустрічала «Are you sure you...», тому незрозуміло яким чином це збиває користувача. Мені здається посил доволі простий для розуміння.

а якщо я не впевнений, яку кнопку натискати?)

2. У діалогах має бути максимум дві дії

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

А якщо мені треба більше дій?

(1/1) Stage this hunk [y,n,q,a,d,s,e,?]? ?
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

Все переліковане іде у радіо-кнопки і у кінці дві кнопки: Proceed і Cancel.

🤣
🤣
😢😢

А ніяк. Пєвстці ізіотизму скажуть, що не має бути взагалі таких складних пропозицій.
web.archive.org/...​com/index.php/archives/38 (десь з середини)

Тут не все добре з текстом, нижче розкажу, чому

І не розказав

розказав: ..Водночас не варто використовувати фрази на кшталт «вибачте, що перериваємо», «увага, важлива інформація» або «ви впевнені, що хочете...?», тому що вони зайві або недоречні.

Наприклад, на скрині нижче в заголовку два запитання. Це робить його двозначним і може збити користувача. Краще прибрати «впевнені», залишивши тільки "вийти з магазину?..

У заголовку ми використовуємо запитання, а в запитанні слово, що відповідає за дію — «Вийти».

А я б написав «Вийти і втратити».

Бо для половини користувачів основний текст задовгий :(

Це все мале порівняно з тим, що регулярно бачиш щось таке:
«Дозвольте нотифікації, щоб бути на звʼязку» з варіантами «дозволити» і «ні, дякую» або «ні, потім».

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

Якщо впізнали себе — записуйтесь зарані до дантиста :)

так, маніпулятивненько

Агов, Гугле, я хочу десь чекбокс «Я не використовую чернеток. Ніде. Ніколи. У жодному разі»
Ніщо не дратує мене більше чим ця пропозиція «Зберегти як чернетку?»
А-а-а-а-а!!!
Втім, це досить солідно підвищує сердцебиття. Немов випита чашка кави кожна така пропозиція.

Дякую за корисний текст. Дуже цікаво написано. Інтерфейсні тексти не варто недооцінювати. Інтерфейсні дизайнери + письменники = сила

дякую за відгук

Неодноразово в роботі натикався на діалог з двома кнопками:
[ Cancel ] [ Cancel ]

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

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

До основної операції додавайте що, власне, відміняється. Наприклад, Cancel request. А звичайний Cancel в такому випадку замінюйти чимось типу Dismiss, Quit etc.

В одному дууже відомому банківському додатку (не ПУМБ) певний час тому періодично випадало повідомлення, яке я вважаю найкоротшим і найневдалішим одночасно. Пам’ятаєте — «Вам виставлено форму»? Яку форму? Куди виставлено?? Банківський додаток має бути розрахований на пересічних громадян, а не на опердень-розробників. Дяка Ктулху, швидко виправили.

Підписатись на коментарі