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

Що балансує UX-дизайнер у щоденній роботі?

У індустрії цей баланс іноді жартома називають «табуретом Нормана»: рівновага тримається, поки всі три ніжки на місці. Прибрати одну — і конструкція розвалюється.

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

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

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

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

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

Куди веде UX-стратегія?

UX-стратегія описує шлях з точки А, де продукт зараз, у точку Б, де він має опинитися. Формулювання цих двох точок визначає, які інструменти знадобляться далі.

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

А тепер уявімо гіпотетичний сценарій: покращити вже наявний інтерфейс Airbnb. Зробити бронювання зручнішим, фільтри точнішими, без революцій. Точка Б тут відома заздалегідь: персоналізація, мобільний досвід, конверсія бронювання. Кожен параметр відстежується метрикою, і саме тому ще до макетів варто прорахувати user flow — логіку кожного кроку користувача. Стратегія перетворюється на серію маленьких валідованих кроків і A/B-тестів.

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

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

Чому слова користувачів розходяться з їхньою поведінкою?

Класична ситуація: на інтерв'ю користувач каже, що натискає певну кнопку. Аналітика під час тестування показує протилежне. Жоден із цих сигналів ігнорувати не можна. Вони належать до різних типів даних.

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

Дизайн-рішення варто будувати на поведінці. Розбіжність з інтерв'ю: сигнал копнути глибше, а не привід відкинути дані. Робочий інструмент тут: модерований тест. Дати користувачу завдання, поспостерігати за поведінкою наживо, а потім прямо запитати, чому він діяв інакше, ніж розповідав.

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

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

Що робити, коли бізнес хоче зашкодити користувачу?

Йдеться про темні UX-патерни (dark patterns): рішення, які приховано підштовхують користувача до дії, вигідної бізнесу і невигідної йому самому. Прихована кнопка відписки. Поміняні місцями кнопки підтвердження й скасування. Ускладнена відмова від платного плану. Усе це особливо люблять казино та передплатні сервіси.

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

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

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

Редизайн чи ітерація: що обрати?

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

Укрзалізниця пройшла через масштабний ребрендинг після багатьох років на ринку. Стара версія сайту роками збирала скарги на незручний пошук і купівлю квитків, а масштабування продукту вимагало нового фундаменту. Логіка й справді застаріла. Тут повний редизайн був виправданим.

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

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

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

Як досліджувати аудиторію, якої ви не знаєте?

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

Джерела непрямих даних доступні майже завжди: відгуки в App Store і Google Play на свій продукт і на конкурентів, форуми та спільноти на кшталт Reddit, де критика буває різкою, зате багатою на конкретні деталі поведінки, і служба підтримки з коментарями в соцмережах. Разом це цілий, хоч і неструктурований банк реальних скарг користувачів.

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

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

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

Як застосувати це на практиці?

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

• Запис до лікаря. 70% користувачів залишають застосунок одразу після вибору лікаря, не завершивши запис. На якому кроці й чому саме вони йдуть?
• Фільтри в маркетплейсі одягу. Фільтри є, але 90% користувачів їх ігнорують і гортають каталог вручну. Що варто з'ясувати перш, ніж чіпати розташування чи вигляд?
• Порівняння тарифів. Клієнт хоче заплутати порівняння і візуально виділити найдорожчий варіант. Як аргументувати, що спершу потрібно зрозуміти справжню проблему клієнта?

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

Роль UX-дизайнера, стратегія руху з точки А в точку Б і кожна із ситуацій вище — це, по суті, форми роботи з обмеженнями: бізнесовими, технічними, дослідницькими. Дослідниця Патрісія Стоукс вивчала творчість Пабло Пікассо і виявила: деякі з найвідоміших його робіт з'явились саме тоді, коли він свідомо обмежував собі палітру, розмір полотна чи кількість кольорів, і саме ці рамки, судячи з усього, підштовхували до рішень, до яких він інакше просто не додумався б. Коли Твіттер увів ліміт символів, це не завадило спілкуванню. Народився новий, стисліший жанр, який згодом перейняли Threads і Bluesky.

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