Як UX-дизайнеру комунікувати з командою, стейкхолдерами та користувачами

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

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

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

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

Взаємодія з маркетинговою командою

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

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

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

Потім зʼявляються коментарі. Наприклад, у цьому завданні отримав запит «А можна зробити форму більш user-friendly?», на що я зі здивуванням відреагував, бо почув знайоме слово. Дізнавшись, що саме має на увазі стейкходер під «більш user-friendly», виявилось, що вони намагаються продати послугу з першого екрану, але маємо дати можливість користувачу закрити форму. Тому було прийнято рішення перенести форму з першого екрану в попап, який відкривався відповідною кнопкою на цьому екрані.

Що ж, з цієї історії можемо виокремити наступні рекомендації:

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

Співпраця з продуктом і розробниками

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

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

Як же ми усунули довгі онлайн-зустрічі? Важливим інструментом у процесі роботи став чейндж-лог у Figma, який структурував всі внесені зміни. Це впровадження стало дійсно актуальним під час редизайну платформи. Коли вже тривала розробка, у дизайн вносилися коригування після тестувань або нових бізнес-вимог. Для розробників було критично розуміти, що саме змінилося, оскільки вони працювали з початковою версією макетів. Тому ми почали фіксувати всі оновлення в історії файлу, що значно полегшило процес адаптації дизайну та допомогло уникнути втрати важливих деталей (використовували саме Version History як базовий чейндж-лог).

Комунікація з користувачами

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

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

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

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

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

Робота зі стейкхолдерами

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

Для самоаналізу також використовую такий же підхід, як і в роботі: проблема, вплив та можливі рішення.

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

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

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

• Що зараз не працює або викликає складнощі у користувачів?
• Які метрики чи показники ми хочемо покращити цим редизайном?
• Чи є якісь технічні обмеження, які варто врахувати?

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

Висновки

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

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

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