Як перевірити UX дизайн сервісу на FTC-ризики: що варто виправити до релізу

Коли команда готує реліз на ринок США, увага зазвичай зосереджена на продукті, конверсії та швидкості онбордингу. Юридичну перевірку інтерфейсу відкладають «на потім» – до скарги користувача, chargeback або листа від платіжного провайдера. І саме тоді з’ясовується, що для Федеральної торгової комісії США (FTC) екран оплати, кнопка «Продовжити» і шлях скасування підписки – це не питання смаку дизайнера. Це спосіб, у який компанія розкриває умови угоди і отримує згоду на списання грошей.

Помилка в UX коштує дорожче за правку макета. Вона здатна перетворити звичайну підписку на оманливу або несправедливу практику в розумінні FTC Act, порушити Restore Online Shoppers’ Confidence Act (ROSCA) і відкрити серію спорів у банках. Принципи, на які спирається Комісія, є наступними: істотні умови мають бути видимими до оплати, а згода на регулярні списання – явною і усвідомленою. Нижче – універсальний чеклист, яким варто пройтися до релізу, якщо сервіс доступний користувачам у США.

Чому перевіряти треба інтерфейс, а не лише Terms of Use

FTC перевіряє, що користувач реально бачить у момент рішення. Якщо істотна умова живе тільки в Terms of Use, а на екрані оплати її немає, для регулятора цього розкриття може бути недостатньо. Користувач не зобов’язаний шукати ціну наступного списання, факт автопродовження чи шлях скасування в окремому документі.

Це однаково стосується сайту, де компанія сама приймає оплату через Stripe чи інший платіжний сервіс, мобільного застосунку з таким самим власним checkout і продукту, який продається через App Store або Google Play. Різниця не в самих правилах FTC, а в тому, хто саме показує користувачу умови і збирає згоду на списання.

Якщо підписку оформлюють через Apple або Google, людина підтверджує покупку вже на системному екрані платформи: бачить ціну, період, автопродовження і натискає «Subscribe». Цей екран закриває значну частину вимоги про явну згоду. Компанія все одно відповідає за те, що написано в самому застосунку на цьому екрані: чи не обіцяє вона одне, а списує інше, і чи не ховає істотні умови.

Якщо ж оплату приймає сама компанія – на сайті, у веб-checkout або напряму через платіжний сервіс – системного екрана Apple чи Google немає. Тоді саме компанія має показати ціну, періодичність і автопродовження до платежу, окремо отримати згоду на регулярні списання і дати зрозумілий спосіб керувати підпискою. Відповідальність за цей шлях повністю на ній.

Окремо варто пам’ятати, що ринок США – це не лише федеральні правила FTC. У багатьох штатах уже діють власні закони про підписки з автопродовженням. Каліфорнія, Нью-Йорк і низка інших штатів вимагають, щоб користувач заздалегідь бачив: підписка продовжиться сама, скільки з нього спишуть і як це зупинити. 

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

Блок 1. Екран оплати: чи зрозуміло, за що саме списують гроші

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

Поруч із кнопкою підтвердження варто поставити короткий дисклеймер: сума, частота, автопродовження, де скасувати. Рекомендовано, щоб кнопка називалася відповідно до дії – «Subscribe», «Start paid plan», «Buy» – а не нейтральним «Continue» чи «Next», за яким ховається перше списання. 

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

Окремо перевірте пробний період. На екрані має бути видно, скільки триває trial, яка ціна після нього, коли відбудеться перше платне списання і як встигнути скасувати. Рекомендована практика – надсилати нагадування до кінця безкоштовного періоду. Це може бути лист або пуш-повідомлення, де видно дату і суму першого списання.

Чеклист до першого блоку:

☐ До введення картки на екрані прямо написано, що користувач оформлює підписку з регулярними списаннями, а не разову покупку. Факт автопродовження не схований лише в Terms of Use. ☐ До підтвердження оплати видно: скільки спишуть зараз, скільки спишуть наступного разу, з якою періодичністю і що підписка триває, доки її не скасують. ☐ Повна ціна з податками, доставкою та іншими зборами стоїть на цьому ж екрані й не з’являється лише на останньому кроці. ☐ Поруч із кнопкою підтвердження є короткий текст: сума, частота списань, автопродовження і де скасувати підписку. ☐ Кнопка називається за дією — «Subscribe», «Start paid plan», «Buy». Не «Continue» і не «Next», якщо за цим натисканням ховається перше списання. ☐ Якщо тарифів кілька, біля кожної ціни вказано період списання і, за потреби, порівняння в одній базі — скільки це на місяць або на день. ☐ Для пробного періоду на екрані видно чотири речі: скільки триває trial, яка ціна після нього, коли буде перше платне списання і як встигнути скасувати. Перед кінцем trial користувач отримує нагадування з датою і сумою.

Блок 2. Згода, яка справді є згодою

Другий блок – express informed consent. FTC вимагає не мовчазної, а явно вираженої згоди на саме регулярне списання. Її не можна «зашити» в загальне прийняття Terms of Use і Privacy Policy. Не можна ставити заздалегідь позначений чекбокс. Не можна робити так, щоб відмова від підписки вимагала зняття галочки, яку система проставила сама.

На практиці достатньо окремої активної дії: чекбокс, який користувач ставить самостійно, або кнопка, текст якої прямо пов’язаний із платною підпискою після того, як умови вже показано на цьому ж екрані. Платіжні провайдери нерідко вимагають, щоб була окрема згода на збереження платіжного методу, якщо сервіс зберігає картку для майбутніх списань. Потрібне формулювання на кшталт «Save my payment method for future use». Інакше може бути складно обґрунтувати наступні списання з уже збереженої картки, коли користувача немає на екрані оплати.

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

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

Чеклист до другого блоку:

☐ Згода саме на регулярні списання зібрана окремою дією. Галочки «I agree to Terms of Use / Privacy Policy» для цього недостатньо. ☐ Чекбокс автопродовження не стоїть уже позначеним. Система не проставляє галочку сама, і щоб відмовитися від підписки не треба її знімати. ☐ Користувач сам ставить галочку або натискає кнопку, у тексті якої прямо сказано про платну підписку. Умови показано на цьому ж екрані — до натискання. ☐ Якщо картка зберігається для наступних платежів, окремо зібрана згода на збереження методу оплати — формулювання на кшталт «Save my payment method for future use».

Блок 3. Скасування не може бути складнішим за підписку

Третій блок – cancel flow. Якщо підписку можна оформити за два натискання, а скасувати – лише через чат підтримки, лист і три екрани з питанням «ви впевнені?», FTC розглядає це як несправедливу практику навіть тоді, коли на старті все було розкрито чесно. Принцип простий: той самий канал, порівнянна кількість кроків, однозначна кнопка «Cancel subscription».

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

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

Чеклист до третього блоку:

☐ Скасувати підписку можна через той канал, де її оформили. ☐ Кроків до скасування не більше, ніж до оформлення. На екрані є однозначна кнопка «Cancel subscription», а не лише «зв’язатися з нами». ☐ Скасування можна завершити з того самого екрана, де користувач керує підпискою, без переходу в інший розділ чи очікування відповіді підтримки. ☐ Після скасування майбутні списання зупиняються. На пошту приходить лист: підписку скасовано, з якої дати це діє і що буде з уже оплаченим періодом.

Блок 4. Dark patterns: що саме варто прибрати з макета

У звіті Bringing Dark Patterns to Light FTC описала прийоми дизайну, які підштовхують людину до дії, якої вона не планувала. Для продуктової команди це зручна карта ризиків. Перед релізом варто пройтися ключовими екранами так, ніби ви бачите продукт уперше: онбординг, вибір плану, оплата, скасування тощо. Якщо на якомусь кроці людину підштовхують купити швидше, ховають ціну або ускладнюють відмову – це вже не «так зручніше для конверсії». Саме такі прийоми FTC давно описала і перевіряє в реальних справах. Їх краще прибрати до запуску, а не пояснювати після скарги.

Не показуйте активність і дефіцит, яких насправді немає. Лічильник «127 людей купили це сьогодні» або напис «залишилося 2 місця» можна ставити лише тоді, коли цифра правдива. Якщо ліміту немає, а таймер потрібен лише, щоб людина швидше натиснула «купити», його краще прибрати. Те саме з акцією «останній день»: якщо знижка живе постійно і щоранку починається знову, це вже не обмежена пропозиція, а тиск. Закреслена «стара ціна» теж має бути реальною. Не можна показувати $29.99 як знижку з $79.99, якщо продукт за $79.99 ніколи не продавався.

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

Не ховайте фінальну ціну і не робіть одну кнопку помітною, а іншу майже невидимою. Сума, яку людина сплатить зараз, має бути найяснішим числом на екрані. Не можна великими літерами писати «$4.99», а податки, доставку чи наступне списання ховати дрібним текстом унизу. На екрані скасування кнопка «залишити підписку» і кнопка «скасувати» мають виглядати рівнозначно. Якщо «залишити» яскрава, а «скасувати» – сіре посилання в кутку, інтерфейс уже підказує «правильний» вибір.

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

Чеклист до четвертого блоку:

☐ На екрані оплати немає вигаданого дефіциту й активності (наприклад, «залишилося 2 місця»). Такі елементи можна ставити лише якщо цифри правдиві. ☐ Напис «останній день» або «пропозиція згорає сьогодні» стоїть лише тоді, коли акція справді обмежена в часі. Якщо знижка живе постійно і щоранку починається знову, такого напису не повинно бути. ☐ Закреслена «стара ціна» — це ціна, за якою продукт реально раніше продавався. ☐ Сума, яку людина сплатить зараз, — найбільш помітне число на екрані. Податки, доставка й наступне списання не сховані дрібним текстом внизу. ☐ На екрані скасування кнопки «залишити підписку» і «скасувати» виглядають рівнозначно. «Скасувати» не зроблене сірим посиланням у кутку, поки «залишити» підсвічене як основна дія. ☐ Кнопка відмови сформульована нейтрально: «Ні, дякую». Немає формулювань, які соромлять людину за відмову, на кшталт «Ні, я не хочу покращити своє життя».

Блок 5. Коли змінюються ціна, план або обіцянка продукту

Цей блок часто згадують пізно – коли треба підняти тариф. Якщо змінюється ціна, періодичність чи склад плану, користувача треба попередити заздалегідь і дати підтвердити нові умови. За цей час людина має встигнути вирішити: лишається на нових умовах або йде.

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

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

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

Чеклист до п’ятого блоку:

☐ Перед зміною ціни попередили заздалегідь і дали час скасувати підписку до нового списання. ☐ Нову суму не знімають із уже збереженої картки лише на підставі Terms. Якщо тариф змінився, людину окремо попередили і дали можливість скасувати підписку. ☐ Якщо на онбордингу чи екрані оплати продукт обіцяє дохід, лікування, «гарантовану» сумісність або «точний прогноз», поруч із обіцянкою стоїть попередження: на чому вона тримається, чого продукт не робить і що рішення залишається за людиною. ☐ Якщо в продукті є штучний інтелект, це сказано на екрані одразу, а не лише в документі. Користувач розуміє, що говорить із моделлю, а не живою людиною.

Як пройти чеклист

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

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

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

Компаніям, які запускають сервіс для користувачів у США, перевірку інтерфейсу на ризики FTC варто закладати так само рано, як перевірку шляху користувача до оплати. Виправити текст на екрані оплати і шлях відмови до запуску дешевше, ніж потім пояснювати регулятору, банку і клієнту, чому підписка продовжилася, а людина цього не очікувала. Універсального макета на всі продукти немає. Перед релізом є сенс залучити юристів, які вміють зіставити конкретні екрани з регуляторною рамкою і сказати, що саме треба змінити, щоб умови були видимі до оплати, згода була явною, а піти з сервісу можна було так само просто, як до нього зайти. З цими питаннями радо допоможе команда Legal IT Group.

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