Один день UI/UX-дизайнера: між логікою продукту та правками керівника
Якщо вірити курсам, рекламним роликам і людям, які бачили Figma двічі, UI/UX-дизайнер проводить день приблизно так: сідає біля вікна з красивою чашкою, пересуває кілька акуратних прямокутників, добирає відтінок зеленого, а потім отримує подяку від бізнесу, користувачів і, ймовірно, самої цивілізації. Надвечір продукт стає зручнішим, конверсія зростає, розробники аплодують стоячи. Усе це існує. Зазвичай у презентації курсу, на слайді перед вартістю навчання.
У реальній компанії дизайнер починає день не з творчості, а з розслідування. У нього є повідомлення керівника з трьох слів, завдання в трекері з п’яти слів, макет попередньої версії, який уже давно не відповідає робочому продукту, і десяток людей із різними уявленнями про те, що взагалі потрібно зробити. Один хоче збільшити продажі. Другий хоче, щоб було «як в Apple». Третій уже пообіцяв клієнту реліз у п’ятницю. Четвертий прийшов повідомити, що на розробку є два дні й один втомлений програміст. Користувач у цих зборах не бере участі. Він узагалі рідко отримує запрошення на зустріч, присвячену його щастю.
Тому звичайний день UI/UX-дизайнера проходить не між красивим і некрасивим. Він проходить між логікою продукту, обмеженнями розробки, показниками бізнесу, звичками користувачів і смаком людини, у календарі якої написано «затвердити дизайн». Останній чинник іноді важить більше, ніж усі інші разом узяті. Не тому, що керівник обов’язково поганий чи дурний. Просто посада має власну гравітацію: що вище людина перебуває в структурі, то швидше її особисте «мені не подобається» перетворюється на завдання на два робочі дні.
Розберімо один такий день без декоративної димової завіси. Не зразковий день із методички й не катастрофу, після якої дизайнер оновлює резюме в туалеті. Звичайний робочий день у продуктовій команді, де люди загалом компетентні, дедлайни загалом існують, а вимоги загалом нагадують живий організм, який живиться коментарями й розмножується поділом.
08:47. Спочатку дизайнер дізнається, що вчорашнє рішення вже застаріло
Робочий день починається з месенджера. Поки завантажується Figma, дизайнер бачить повідомлення, надіслане о 22:36: «Переглянув ще раз. Здається, треба повністю переробити перший екран». О 22:41 до нього додалося уточнення: «Тільки без значних змін, терміни залишаємо». Це важливий жанр корпоративної літератури. У двох реченнях автор знищує вчорашній день і водночас забороняє витрачати новий.
Поруч лежать коментарі від продакт-менеджера, розробника й маркетолога. Продакт просить спростити сценарій реєстрації. Розробник пише, що запропонована перевірка даних потребуватиме додаткового методу на сервері. Маркетолог хоче додати ще три переваги, промокод і яскраву плашку, тому що користувач, вочевидь, зобов’язаний увійти в продукт уже поінформованим, мотивованим і трохи засліпленим. У макеті з’являються різнокольорові курсори. Кожен курсор представляє людину, яка прийшла зробити інтерфейс зрозумілішим. Інтерфейс починає нагадувати місце злочину.
Перша професійна дія дизайнера полягає не в тому, щоб відкрити потрібний фрейм. Спочатку він відновлює контекст. Що змінилося після вчорашнього обговорення? З’явилися нові дані чи хтось просто подивився на макет свіжим поглядом? Яке рішення вже погодили? Хто має право його скасувати? Є технічне обмеження чи лише тривога перед незвичним варіантом? Якщо почати виправляти все одразу, до полудня вийде бездоганна відповідь на запитання, якого ніхто не ставив.
Тут проходить перша межа між людиною, яка вміє користуватися графічним редактором, і дизайнером продукту. Перша реагує на вхідний коментар. Другий з’ясовує, яку подію цей коментар відображає. Фраза «зробіть перший екран переконливішим» може означати низьку конверсію, страх керівника перед запуском, скаргу одного важливого клієнта, новий рекламний офер або особисту неприязнь до порожнього простору. Візуально ці проблеми можуть виглядати однаково: хтось просить додати велику зелену кнопку. По суті це п’ять різних завдань, і лише одне з них, можливо, лікується кнопкою.
Дизайнер відкриває аналітику, завдання, запис учорашньої зустрічі та робочий продукт. Уже минуло двадцять хвилин. Жодного прямокутника не намальовано. Збоку здається, що робота ще не почалася. Насправді саме зараз вирішується, чи доведеться команді через тиждень повністю переробляти екран.
09:15. Дейлі, де кожен говорить дві хвилини, а дизайнер отримує роботи на пів дня
Щоденна зустріч потрібна, щоб команда швидко синхронізувалася. Теоретично кожен повідомляє, що зробив, що робитиме і що йому заважає. На практиці розробник розповідає про проблему з авторизацією, аналітик шукає потрібний звіт, продакт згадує вчорашню розмову з керівником, а дизайнер розуміє, що його макет уже обговорили без нього. Це не змова. Змови зазвичай організовані краще.
На дейлі з’ясовується, що перший екран хочуть змінити через нову гіпотезу: користувачі не розуміють цінності функції до реєстрації. Доказів поки немає. Є кілька звернень до служби підтримки, спостереження відділу продажів і впевненість керівника. Відмахуватися від цього не можна. Підтримка й продажі часто першими бачать реальну проблему, поки продуктова команда милується чистими дашбордами. Сприймати формулювання буквально теж не можна. Користувач може розуміти цінність функції й однаково не реєструватися, тому що форма вимагає номер телефону, пароль, підтвердження електронної пошти, ім’я кота та згоду отримувати новини до кінця природного життя.
Дизайнер ставить запитання. На якому кроці люди йдуть? З якого джерела вони приходять? Що обіцяє реклама? Чи є записи сесій? Що кажуть користувачі, які все-таки зареєструвалися? Чи можна показати функцію до створення облікового запису? У цей момент він ризикує здатися людиною, яка ускладнює просте прохання. Адже прохання було зрозумілим: зробити переконливіше. Тільки «переконливіше» не можна помістити в макет. Це не компонент, не стан і не властивість тексту. Це слово, яким зручно прикривати відсутність діагнозу.
Хороший дизайнер на зустрічі не захищає кожен піксель як сімейну реліквію. Він захищає зв’язок між проблемою та рішенням. Якщо команда довела, що обраний сценарій не працює, макет потрібно викинути без жалобної церемонії. Якщо рішення змінюють через те, що учаснику зустрічі стало нудно, дизайнер зобов’язаний це помітити. Інакше продукт поступово перетворюється на археологічний шар із чужих настроїв.
Наприкінці дейлі з’являється робоча домовленість: спочатку перевірити воронку та звернення, потім запропонувати два варіанти першого екрана. Один мінімально змінює поточний сценарій, другий дає змогу спробувати функцію до реєстрації. Дедлайн не зник, розробник не розмножився, а отже, другий варіант поки існує у статусі «розумна ідея, яку бюджет може задушити голими руками».
09:45. Завдання нарешті перестає бути набором побажань
Найбільш недооцінена частина UX-роботи називається нудно: постановка завдання. У ній немає градієнтів, анімації та красивих мокапів смартфона, зате є шанс не витратити тиждень на безглузду конструкцію. Дизайнер записує, хто стикається з проблемою, у якому місці сценарію вона виникає, що заважає людині продовжити та яка поведінка продукту має змінитися після релізу.
Це звучить елементарно, доки не доводиться робити це в реальності. Бізнес каже: «Потрібно збільшити кількість реєстрацій». Користувач каже: «Я просто хотів подивитися, що всередині». Розробка каже: «Гостьовий режим зачепить права доступу». Безпека каже: «Жодного гостьового режиму». Маркетинг каже: «Нам потрібна форма, щоб збирати ліди». Усі кажуть правду, просто кожен тримає в руках окрему частину тварини й упевнено описує її цілком.
Завдання дизайнера полягає не в тому, щоб обрати найгучнішого учасника. Потрібно зібрати обмеження в одну модель і зрозуміти, де є реальний вибір. Можливо, продукту вигідніше втратити частину реєстрацій, але отримати якісні контакти. Можливо, обов’язкова реєстрація справді вбиває знайомство з функцією. Можливо, проблема взагалі починається в рекламі, яка обіцяє безплатний інструмент, а приводить на сторінку з тарифами. Тоді новий інтерфейс стане дорогою серветкою, акуратно покладеною на трубу, що протікає.
У нормальній постановці з’являються критерії. Користувач має зрозуміти цінність сервісу до введення персональних даних. Основний сценарій має складатися не більше ніж із певної кількості кроків. Команда повинна бачити, як змінюється перехід до реєстрації. Рішення не має вимагати повної перебудови системи прав. Ці обмеження не роблять роботу менш творчою. Вони повідомляють, у якій саме кімнаті дозволено пересувати меблі, а де за стіною проходить газова труба.
Паралельно дизайнер перевіряє, що вже є в дизайн-системі. Чи можна зібрати потрібний сценарій з наявних компонентів? Чи є відповідний шаблон? Як поводяться поля, помилки, підказки й модальні вікна? Новачок часто сприймає бібліотеку компонентів як нудну перешкоду між собою та самовираженням. Досвідчений дизайнер бачить у ній інфраструктуру. Кожен новий унікальний елемент здається нешкідливим лише в макеті. Після релізу він отримує мобільну версію, темну тему, локалізацію, стани завантаження, документацію та довічне утримання. Так маленька авторська кнопка обростає витратами, наче породистий кінь.
До десятої години завдання стає точнішим. Дизайнер іще майже нічого не намалював, зате вже знає, чого малювати не варто. Це одна з головних форм професійної ефективності. Її важко покласти в портфоліо, тому що порожнє місце погано виглядає в кейсі, хоча іноді саме воно заощадило компанії місяць розробки.
10:20. Дослідження, яке рідко виглядає як дослідження
Слово «дослідження» викликає образ лабораторії, довгого звіту й людей, які вимовляють слово «вибірка» з виразом державної важливості. У продуктовій роботі дослідження часто виглядає скромніше. Дизайнер відкриває записи звернень до служби підтримки, переглядає кілька сесій, читає відгуки, порівнює поведінку сегментів і телефонує аналітику. Іноді на пошук рішення є тиждень і окремий дослідник. Іноді є сорок хвилин і працівник підтримки, який пам’ятає користувачів краще, ніж система аналітики.
Головна небезпека тут полягає не в нестачі даних. Нестачу принаймні видно. Значно гірші дані, які відповідають не на те запитання. Наприклад, команда бачить, що половина відвідувачів не завершує реєстрацію. Це факт. Далі починаються версії: форма надто довга, цінність незрозуміла, люди бояться залишати телефон, кнопка недостатньо помітна. Остання версія зазвичай отримує напрочуд багато прихильників, тому що кнопку легко перефарбувати й приємно обговорювати. Страх користувача, якість трафіку та відповідність обіцянок вимагають менш фотогенічної роботи.
Дизайнер переглядає записи сесій. Частина людей кілька разів натискає на неактивний елемент. Інші повертаються вгору, щоб перечитати опис. Треті йдуть після поля з телефоном. Кілька користувачів проходять усе без труднощів. Із цього вже не можна чесно зробити один висновок. Зате можна розділити проблему: цінність справді зчитується не одразу, а обов’язковий телефон створює додатковий бар’єр. Перефарбувати кнопку все ще можна, якщо в команди нудний квартал і залишилася зайва фарба.
Потім дизайнер читає звернення. Користувачі не розмовляють мовою продуктової команди. Вони не пишуть: «Інформаційна архітектура порушує мою ментальну модель». Вони пишуть: «Де подивитися приклад?», «Чому одразу потрібен номер?» або «Я натиснув, і нічого». Робота UX-дизайнера починається з перекладу цих фраз у системні проблеми. При цьому не можна перетворювати кожну скаргу на окрему функцію. Одна людина може попросити експортувати звіт у рідкісному форматі, друкувати його на пергаменті й надсилати голубом. Це зворотний зв’язок. Це ще не стратегія.
Якісне дослідження не гарантує однозначного рішення. Воно звужує простір для фантазій і показує, які припущення команда робить свідомо. За підсумками дизайнер формулює гіпотезу: якщо до реєстрації показати коротку інтерактивну демонстрацію та пояснити, навіщо потрібен телефон, більше цільових користувачів дійде до створення облікового запису. Тепер макет можна оцінювати не за рівнем колективного захоплення, а за тим, чи допомагає він перевірити цю гіпотезу.
11:10. Користувацький сценарій: та частина роботи, яку не викладеш у красиву карусель
До інтерфейсу потрібно побудувати шлях. Дизайнер розкладає сценарій: вхід зі сторінки, вибір прикладу, коротка дія всередині демонстрації, показ результату, пропозиція зберегти його після реєстрації. Потім додає відгалуження. Що станеться, якщо дані не завантажилися? Якщо користувач повернувся назад? Якщо приклад недоступний? Якщо він уже зареєстрований? Якщо відкрив посилання на маленькому екрані? Якщо з’єднання вирішило перевірити його характер?
Саме тут інтерфейс перестає бути картинкою. Картинка існує в одному ідеальному стані: дані завантажилися, користувач усе зрозумів, сервер бадьорий, текст уміщується, ім’я людини складається із семи літер. Продукт існує в усіх інших станах. Він має пережити порожні результати, помилки, довгі прізвища, повторні натискання, завершену сесію, повільну мережу й людину, яка ігнорує інструкцію, тому що саме для цього люди й отримують інструкції.
Дизайнер малює схему не заради ритуалу. Вона показує, скільки рішень приховується за одним екраном. Кнопка «Продовжити» здається простою, доки не потрібно визначити, коли вона активна, куди веде, що зберігає, як реагує на подвійне натискання та що повідомляє в разі помилки. Кожне запитання без відповіді згодом отримає відповідь від розробника. Це не обов’язково буде погана відповідь. Просто її ухвалять у момент, коли людина зайнята кодом і найменше мріє обговорювати психологію кнопки.
У сценарії виявляється конфлікт. Інтерактивна демонстрація дає користувачеві цінність до реєстрації, але для точного результату серверу потрібні дані, доступні лише в обліковому записі. Можна зробити обмежений приклад на підготовленому наборі. Можна показати відео. Можна скоротити форму реєстрації. Можна залишити поточний порядок і краще пояснити цінність. Варіантів кілька, і кожен платить своєю валютою: часом, точністю, конверсією, довірою або складністю підтримки.
Дизайнер обговорює розвилку з продактом і технічним фахівцем. Вони обирають обмежену демонстрацію на готовому прикладі. Це не найефектніше й не найповніше рішення. Зате його можна випустити, виміряти й за потреби розвинути. Продуктовий дизайн узагалі часто складається з рішень, які виглядають скромно, але виживають після знайомства з реальністю.
До одинадцятої сорока з’являється чорновий потік і кілька грубих екранів. Вони сірі, місцями некрасиві й корисні. Сірий прямокутник дає змогу сперечатися про порядок дій. Ідеально промальована картка змушує людей обговорювати радіус кутів. Мозок любить чіплятися за те, що легше оцінити. Тому ранній макет має бути достатньо зрозумілим для перевірки логіки й достатньо непривабливим, щоб ніхто не почав затверджувати відтінок тіні.
12:05. UI починається не там, де обирають колір
Коли сценарій зібрано, дизайнер переходить до інтерфейсу. Тут людині збоку нарешті стає спокійніше: на екрані з’являються знайомі елементи, сітка, типографіка, кнопки, картки. Здається, що почалася справжня робота. Попередні три години, вочевидь, були розминкою, під час якої дизайнер професійно дивився в монітор.
UI вирішує значно більше завдань, ніж прикрашання. Візуальна ієрархія показує, що важливо, що пов’язано й що можна зробити далі. Розмір, контраст, відстань і розташування елементів керують увагою. Текст пояснює наслідки дії. Стани повідомляють, що система почула користувача. Якщо інтерфейс красивий, але людина не розуміє, де вона перебуває і що станеться після натискання, перед нами якісно оформлена розгубленість.
Дизайнер збирає екран із компонентів системи. Перевіряє сітку, відступи, довжину рядків, контраст, розміри зон натискання. Дивиться, що станеться на мобільному пристрої. Не всі користувачі сидять перед дизайнерським монітором, хоча деякі макети поводяться так, наче ця умова прописана в користувацькій угоді. На екрані телефона зникає розкішний вільний простір, довгий заголовок займає чотири рядки, а дві кнопки починають боротися за територію.
Потім приходить текст. У поганому процесі його додають наприкінці, як петрушку до готової страви. У нормальному процесі текст є частиною сценарію. Формулювання «Почати» не пояснює, що саме почнеться: реєстрація, демонстрація, платний період чи новий розділ у відносинах із відділом продажів. Підпис під полем телефону має чесно повідомляти, навіщо він потрібен. Помилка повинна допомогти виправити дію, а не просто оголосити користувача винним червоним кольором.
Дизайнер пише кілька варіантів, скорочує, перевіряє на реальних даних і кличе редактора, якщо він є. Якщо редактора немає, дизайнер тимчасово стає ним. Потім він тимчасово стає аналітиком, фахівцем із доступності й людиною, яка нагадує, що інтерфейс перекладають іншими мовами. Професія називається UI/UX-дизайнер, але всередині неї регулярно відкриваються безплатні вакансії на пів ставки.
До пів на першу основний варіант готовий. Він не є витвором мистецтва й не повинен ним бути. Він показує цінність функції, дає змогу пройти коротку демонстрацію, пояснює реєстрацію та використовує знайомі компоненти. Тепер рішення потрібно винести до людей. Саме там у нього починається доросле життя.
13:00. Обід, який формально існує
У календарі є година на обід. У реальності за п’ять хвилин до нього приходить повідомлення: «Можна швидко подивитися макет?» Слово «швидко» в продуктовій команді не описує тривалість. Воно зменшує почуття провини в людини, яка призначає зустріч на час, коли ви вже відкрили застосунок доставки їжі.
Дизайнер надсилає посилання й намагається відійти від екрана. За хвилину з’являється перший коментар: «А чому тут так багато порожнього місця?» За дві хвилини другий: «Мені здається, головний блок губиться». За три хвилини продакт пропонує зідзвонитися після обіду. Організм отримує їжу, мозок продовжує розкладати аргументи. Так виглядає корпоративний велнес: людина їсть суп і подумки захищає вертикальний відступ.
Тут корисно розуміти одну річ. Дизайнер не зобов’язаний сприймати кожне зауваження як напад. Люди справді помічають проблеми, яких автор макета вже не бачить. Після кількох годин роботи око адаптується, логіка здається очевидною, а знайомий текст читається швидше, ніж його прочитає новий користувач. Свіжий погляд цінний. Навіть фраза «щось не те» може вказувати на реальний дефект, просто людина поки не вміє його назвати.
Однак коментар не дорівнює рішенню. Якщо людині здається, що блок губиться, це привід з’ясувати, який елемент вона вважала головним і куди подивилася спочатку. Прохання збільшити заголовок є однією з можливих реакцій, а не готовим технічним завданням. Дизайнеру платять зокрема за те, щоб він не плутав симптом із призначенням.
Після обіду він швидко перевіряє макет самостійно. Прибирає один другорядний текст, посилює зв’язок між демонстрацією та результатом, коригує відступ. Тобто змінює макет до зустрічі, тому що частина зауважень справедлива. Професійна позиція полягає не в урочистій відмові пересувати пікселі. Вона полягає у здатності відрізнити обґрунтоване покращення від пересування меблів під час пожежі.
14:05. Дизайн-рев’ю: вісім людей дивляться на один екран і бачать вісім продуктів
На зустрічі присутні дизайнер, продакт, керівник напряму, розробник, маркетолог, аналітик і двоє людей, чия роль спочатку незрозуміла. Один із них згодом поставить найбільше запитань. Так працює природа: вільна ніша швидко заповнюється.
Дизайнер починає не з демонстрації макета, а з контексту. Яку проблему виявлено, що показують дані, яку гіпотезу перевіряє рішення, які обмеження враховано. Це не бюрократична прелюдія. Без неї учасники оцінюють екран як афішу: подобається чи не подобається. З контекстом з’являється шанс обговорити, чи вирішує інтерфейс завдання.
Перші хвилини минають продуктивно. Аналітик уточнює подію, за якою вимірюватимуть проходження демонстрації. Розробник помічає, що один стан неможливо реалізувати в поточній архітектурі. Маркетолог пропонує точніше сформулювати цінність. Дизайнер фіксує зміни. Потім керівник запитує: «Чому кнопка не зелена?»
Запитання нормальне. Колір може впливати на помітність, відповідність бренду та розпізнавання дії. Проблема починається, коли за запитанням немає критерію, крім того, що зелена кнопка здається керівнику більш продажною. Дизайнер пояснює, що основний колір уже використовується для іншого типу дії, а нова кнопка перебуває в зоні високої уваги й має достатній контраст. Керівник дивиться ще кілька секунд і каже: «Усе одно хочеться зелену».
У кімнаті виникає знайома пауза. Формально триває обговорення дизайну. Фактично команда визначає, чи має система правил більшу вагу, ніж інтуїція людини, яка відповідає за результат. Дизайнер може негайно поступитися, може почати лекцію про когнітивне навантаження, а може поставити корисне запитання: яку проблему має вирішити зміна кольору? Якщо кнопку не помічають, це можна перевірити. Якщо вона здається недостатньо важливою, ієрархію можна посилити кількома способами. Якщо зелений потрібен через нову комунікаційну кампанію, це вже системна зміна.
Керівник відповідає, що екран виглядає надто спокійним і не підштовхує до дії. Це вже краще. Тепер обговорюється не улюблений колір, а інтенсивність акценту. Дизайнер показує варіант із виразнішим контрастом, зберігаючи логіку системи. Команда погоджується перевірити обидва рішення на прототипі. Зелена кнопка тимчасово повертається до лісу, де їй і належить жити до появи доказів.
Потім починається обговорення демонстрації. Один учасник пропонує додати більше підказок. Другий вважає, що підказки перевантажують екран. Третій просить показати всі можливості одразу, щоб користувач точно зрозумів цінність. Це популярний спосіб пояснення: якщо людина не зрозуміла одну річ, потрібно одночасно показати їй дев’ять. За тією самою логікою туристу, який заблукав, слід видати всі карти міста й трохи його струснути.
Дизайнер повертає розмову до послідовності. На першому кроці людина має побачити один зрозумілий результат. Решту можливостей можна розкрити після дії. Інакше демонстрація перетвориться на екскурсію складом функцій. Продакт підтримує рішення, маркетолог просить зберегти одну додаткову фразу, розробник нагадує про термін. Через сорок хвилин макет отримує список змін, два відкриті запитання та статус «загалом погоджено». Корпоративною мовою це означає, що конструкцію поки не знесли, але будівельна техніка залишається поруч.
15:00. Правки керівника: де закінчується зворотний зв’язок і починається керування тривогою
Після зустрічі приходить особисте повідомлення від керівника: «Нумо все-таки спробуємо яскравіший варіант. І можна зробити сучасніше?» Слово «сучасніше» посідає почесне місце поруч із «дорожче», «легше» та «вау». Усі розуміють напрям емоції, ніхто не знає одиниці вимірювання.
Правки керівника часто дратують дизайнерів не тому, що керівник втручається у священну царину кольору. Дратує руйнування причинно-наслідкового зв’язку. Дизайнер кілька годин збирав дані, сценарій та обмеження, а потім рішення може змінитися через враження, яке виникло за сім секунд. Це схоже на роботу архітектора, якому після розрахунків повідомляють, що сходи мають виглядати бадьоріше. Можливо, прохання розумне. Тільки спершу хочеться переконатися, що слово «бадьоріше» витримає вагу людей.
Водночас у керівника є те, чого може не бути в дизайнера: відповідальність за комерційний результат, знання переговорів із партнерами, розуміння стратегії, досвід попередніх запусків та інформація, яку ще не встигли додати до завдання. Його інтуїція не обов’язково є примхою. Іноді це стислий досвід, який людина поки не змогла розгорнути в пояснення. Робота дизайнера полягає не в автоматичному опорі владі, а у видобуванні критерію з розмитого формулювання.
Він ставить запитання. Що саме виглядає недостатньо сучасно: типографіка, щільність, ілюстрація, характер компонентів? З якими продуктами керівник порівнює рішення? Яке враження має отримати користувач? Що зараз заважає цьому враженню? Після кількох повідомлень з’ясовується, що керівник нещодавно показував продукт потенційному партнеру, а той назвав інтерфейс «надто утилітарним». Тепер уся компанія лікує прикметник, сказаний однією людиною на зустрічі.
Ігнорувати сигнал не можна. У B2B-продукті сприйняття партнерів може впливати на продажі. Проте перебудовувати користувацький сценарій заради невизначеної «сучасності» небезпечно. Дизайнер пропонує розділити завдання: залишити логіку демонстрації, а візуальне подання посилити через типографіку, графіку результату й характер акцентної зони. Потім показати варіант керівнику та маркетингу, не зачіпаючи компоненти, від яких залежить увесь продукт.
Так виглядає здорова робота з правкою. Не «я художник, я так бачу» і не «начальник сказав, отже, фарбуємо». Спочатку дизайнер визначає джерело запиту, потім перекладає його у властивість, яку можна спостерігати, після цього змінює мінімально необхідний рівень системи. Якщо проблема у сприйнятті бренду, не потрібно ламати сценарій реєстрації. Якщо проблема в конверсії, новий градієнт сам собою навряд чи стане комерційним директором.
Буває гірше. Керівник може наполягати на конкретному рішенні й не обговорювати критерії. Тоді в дизайнера залишаються три обов’язки. Перший полягає в тому, щоб чітко позначити ризик. Другий полягає в тому, щоб зафіксувати ухвалене рішення. Третій полягає в тому, щоб виконати його професійно, якщо воно не порушує закон, етику та базову працездатність продукту. Робота за наймом не дає дизайнеру права вето на кожну спірну кнопку.
Це неприємна, але доросла частина професії. Дизайнер впливає на рішення, однак рідко володіє ним одноосібно. Що більший продукт, то більше в нього власників, обмежень і людей, які можуть сказати «ні». Якщо фахівцю потрібна абсолютна художня автономія, продуктова команда стане для нього складним відкриттям. Тут навіть помилка в тексті може потребувати погодження з юристом, а колір іконки іноді обговорюють довше, ніж умови її появи.
З іншого боку, постійне мовчазне виконання будь-яких правок швидко перетворює дизайнера на графічний термінал. Керівник вводить команду, система видає макет. Такий фахівець зручний до першого серйозного провалу, після якого раптом з’ясовується, що саме він «мав попередити». Тому заперечувати потрібно не голосно, а точно. Не доводити, що керівник не розуміється на дизайні, а показувати наслідки: цей блок пересуває ключову дію нижче першого екрана; цей текст обіцяє функцію, якої немає; ці два однакові акценти конкурують; цей патерн суперечить поведінці інших розділів.
Хороша аргументація не гарантує перемоги. Вона робить рішення прозорим. У продукті це вже багато. Команда принаймні розуміє, яку ціну платить і чому. І якщо за місяць експеримент провалиться, обговорення почнеться з даних, а не зі спроби знайти людину, яка недостатньо натхненно обрала синій.
15:45. Перемальовування, під час якого змінюється двадцять відсотків екрана і сто відсотків деталей
Дизайнер повертається до Figma і створює новий варіант. Зберігає сценарій, посилює акцентну зону, змінює масштаб заголовка, переробляє графіку результату. Паралельно перевіряє, чи не розвалилася адаптивна версія. Будь-яке «трохи більше» живе в ланцюжку залежностей. Заголовок переноситься на додатковий рядок, картка стає вищою, наступний блок з’їжджає вниз, на маленькому екрані кнопка зникає з видимої області. Один коментар тягне за собою макет, як нитка старий светр.
Потім потрібно впорядкувати компоненти. Якщо змінити лише конкретний екран, розробник отримає унікальний виняток. Якщо змінити основний компонент, оновляться інші місця продукту. Дизайнер перевіряє варіанти, властивості та вкладені елементи. Це робота, якої не видно на фінальному зображенні, зате її відсутність чудово помітна через два місяці, коли у файлі лежать двадцять майже однакових кнопок із назвами «Button final», «Button final 2» і «Button new real».
Версії взагалі є окремою формою корпоративної археології. Потрібно зберегти початковий варіант, новий варіант, погоджений варіант і варіант, який керівник попросив повернути після перегляду нового. Якщо не підтримувати порядок, макет починає зберігати історію рішень краще, ніж команда. За шарами можна визначити періоди: ранній мінімалізм, епоху великої зеленої кнопки, коротке панування ілюстрацій і велике повернення до версії з вівторка.
Поки дизайнер працює, приходить коментар від розробника: обрана анімація результату займе більше часу, ніж планувалося. Її можна спростити або перенести. Дизайнер оцінює, чи передає анімація зміст. Якщо вона показує перехід між станами й допомагає зрозуміти результат, потрібно зберегти принаймні базовий принцип. Якщо вона існує заради приємного погойдування картки, картка переживе нерухомість. Користувач теж. Можливо, навіть швидше завершить завдання.
До пів на п’яту готовий варіант, який враховує запит керівника й не руйнує логіку. Його надсилають на коротке погодження разом із поясненням: що змінено, що збережено та які ризики залишаються. Це важливо, тому що посилання без контексту знову запускає конкурс особистих вражень. Дизайн неможливо повністю захистити поясненнями, але можна принаймні не залишати його наодинці в кімнаті з вісьмома курсорами.
16:35. Стани інтерфейсу, про які згадують після релізу
Основний екран погоджено. Починається робота, яку люблять переносити на потім: стани та винятки. Що бачить користувач до завантаження? Під час завантаження? У разі помилки? За порожнього результату? Після завершення? Під час повторного входу? Що відбувається, якщо демонстрація недоступна на конкретному тарифі? Як виглядає довге системне повідомлення? Чи може людина повторити дію?
У презентації продукту зазвичай показують щасливий шлях. Користувач приходить, натискає, отримує результат і усміхається в бік конверсії. У реальному продукті він забуває пароль, закриває вкладку, забороняє cookies, вставляє пробіл у номер телефону й натискає кнопку тричі. Інтерфейс зобов’язаний мати план на таке життя, навіть якщо команда воліє його не уявляти.
Дизайнер додає стани завантаження, помилки та порожнього результату. Перевіряє тексти. Повідомлення «Щось пішло не так» чесно описує емоційний стан системи, але не допомагає людині. Потрібно сказати, що саме не вдалося, чи збереглися дані та що можна зробити далі. Якщо виправити проблему неможливо, не варто нескінченно пропонувати «спробувати ще раз». Це вже не допомога, а маленький цифровий ритуал відчаю.
Окремо перевіряється доступність. Контраст, фокус із клавіатури, підписи для елементів, порядок читання, зрозумілість помилок без опори лише на колір. Доступність часто сприймають як додатковий шар для рідкісної групи користувачів. Насправді тимчасові та ситуативні обмеження виникають у всіх: яскраве сонце, травма руки, повільна мережа, втома, маленький екран, поганий звук. Дизайн, розрахований винятково на здорову, уважну людину в ідеальних умовах, розрахований на персонажа з технічного завдання. У природі його спостерігають рідко.
Тут знову виникає конфлікт із термінами. Повний набір станів потребує часу, а розробка хоче почати сьогодні. Дизайнер передає основний сценарій і критичні помилки, потім домовляється про час для решти станів. Це допустимий компроміс, якщо його озвучено. Якщо просто надіслати один красивий екран і сподіватися, що деталі матеріалізуються самі, вони справді матеріалізуються. Тільки обере їх той, хто першим втомиться чекати.
17:10. Передача в розробку: момент, коли картинка має стати поведінкою
Фраза «макет готовий» нічого не означає, поки розробник не може за ним зібрати продукт. Для передачі потрібні не лише розміри й відступи. Потрібні правила: як змінюється блок, які дані обов’язкові, що відбувається після дії, які стани існують, де використовується готовий компонент, а де з’являється новий. Хороший handoff зменшує кількість здогадок. Поганий перетворює розробника на співавтора інтерфейсу без виділеного на це часу.
Дизайнер упорядковує файл, дає назви фреймам, зв’язує прототип, додає пояснення. Перевіряє, чи не суперечать одне одному макети для різних розмірів. Вказує поведінку елементів під час зміни ширини. Додає тексти та вимоги до графіки. Це не бюрократія заради естетики шару. Розробник не зобов’язаний вгадувати, яку з чотирьох версій погодили та чому одна картка випадково стоїть на сім пікселів лівіше.
Потім відбувається короткий дзвінок. Розробник ставить запитання, які миттєво знаходять слабкі місця. Звідки надходить цей параметр? Чи можна повторно відкрити результат? Що робити, якщо користувач уже почав реєстрацію в іншій вкладці? Чому на мобільному пристрої порядок блоків змінюється? На частину запитань дизайнер відповідає, з рештою повертається до продакта. Макет знову виявляється не фіналом, а формою розмови.
У зрілій команді розробник долучається раніше, тому великих сюрпризів менше. У незрілій команді дизайн передають як замовлення в ресторані: ось красива фотографія, приготуйте до п’ятниці. Потім з’ясовується, що інгредієнтів немає, кухня влаштована інакше, а фотографію взагалі створили для рекламної зйомки й не передбачали, що зображене на ній споживатимуть усередину.
До шостої години завдання йде в розробку. У трекері з’являється статус, який створює приємну ілюзію завершення. Дизайнер знає, що попереду ще перевірка реалізації. Інтерфейс у Figma поводиться бездоганно, тому що пікселі дисципліновані й не працюють із базою даних. Справжнє випробування почнеться, коли рішення зустрінеться з кодом.
18:00. Дизайн-рев’ю реалізації: «майже як у макеті» та інші одиниці вимірювання
Розробник надсилає посилання на тестову збірку іншого завдання, переданого кілька днів тому. Потрібно перевірити реалізацію. На перший погляд усе схоже. На другий стає видно, що заголовок має іншу насиченість, контейнер вужчий, іконка з’їхала, текст помилки відрізняється, а кнопка стрибає після завантаження. Жоден дефект окремо не виглядає смертельним. Разом вони створюють інтерфейс, який наче пам’ятає макет із розповідей родичів.
Тут дизайнеру важливо не складати список із сорока зауважень однакової терміновості. Критична помилка сценарію та відмінність відступу на два пікселі не мають стояти поруч як рівноцінні загрози людству. Спочатку перевіряються логіка, доступність дії, коректність станів і відповідність контенту. Потім візуальна ієрархія, адаптивність і послідовність. Дрібні розбіжності виправляють, якщо вони впливають на якість або накопичують системний борг, а не тому, що дизайнеру потрібен привід завершити день у стані праведного виснаження.
Одна проблема виявляється серйозною: після помилки введені дані скидаються. Користувачеві доведеться заповнювати форму знову. Розробник пояснює технічну причину й пропонує виправити це в наступному спринті. Дизайнер показує наслідки: помилка може виникнути після кількох кроків, втрата даних підвищує ймовірність виходу й руйнує довіру. Продакт змінює пріоритет. Це і є дизайнерська робота, хоча в ній знову немає вибору шрифту.
Іншу проблему вирішують компромісом. Анімація відрізняється від прототипу, але зберігає зміст і працює швидше. Переробляти її заради точного збігу не потрібно. Здатність прийняти хорошу реалізацію, яка виглядає інакше, важливіша за здатність виміряти тривалість кожного переходу. Дизайн-система потрібна для послідовності, а не для створення маленької тоталітарної держави всередині інтерфейсу.
Зауваження фіксують у завданні зі скриншотами та пріоритетами. Розробник уточнює два пункти. Дизайнер відповідає без формулювання «ну це ж очевидно». Якщо щось очевидне лише автору макета, воно не очевидне. Телепатія досі не входить до стандартного набору інструментів команди, хоча чимало процесів оптимістично на неї розраховані.
18:40. Робочий день закінчується, а оцінювання чужих рішень залишається в голові
До кінця дня дизайнер зробив не один екран. Він розібрав суперечливий запит, зібрав дані, побудував сценарій, домовився про технічний компроміс, оформив рішення, витримав дизайн-рев’ю, переклав суб’єктивну правку в робочий критерій, підготував стани, передав макет і перевірив іншу реалізацію. Якщо дивитися лише на фінальний інтерфейс, обсяг роботи здається підозріло малим. На екрані досі кілька блоків і одна кнопка. Просто тепер відомо, чому вони розташовані саме там і що станеться після натискання.
Психологічно ця професія влаштована дивно. Дизайнер має занурюватися в рішення достатньо глибоко, щоб бачити деталі, і водночас бути готовим викинути його після появи нових даних. Потрібно мати позицію, але не перетворювати її на релігію. Потрібно приймати критику, не погоджуючись автоматично. Потрібно відрізняти зауваження до макета від оцінки себе, хоча макет кілька годин перебував просто всередині голови й вийшов звідти без захисної упаковки.
Постійний зворотний зв’язок створює втому особливого типу. Результат роботи публічно розбирають на зустрічах, у коментарях і на тестах. Користувач натискає не туди, аналітика показує падіння, розробник знаходить суперечність, керівник просить переробити. Тут неможливо роками підтримувати образ людини, яка завжди відразу знає правильну відповідь. Продукт швидко проводить розтин цієї легенди.
Тому стійкий дизайнер не той, кому байдуже до якості. Байдужість дає не стійкість, а погані макети. Стійкий дизайнер уміє розділяти три речі: власну цінність, якість поточного рішення та обмеження процесу. Рішення може бути слабким, тому що не вистачило даних. Воно може бути розумним, але програти бізнес-пріоритету. Воно може бути хорошим і все одно не спрацювати. Користувацька поведінка не підписує угоду про відповідність очікуванням команди.
Перед закриттям ноутбука дизайнер записує відкриті запитання на завтра. Потрібно перевірити події аналітики, завершити другорядні стани й переглянути оновлену збірку. У месенджері з’являється нове повідомлення від керівника: «Подивився варіант. Стало краще. А можемо все-таки спробувати зелену кнопку для порівняння?» Звичайно, можемо. Наука вимагає контрольної групи, а корпоративне життя вимагає смирення, бажано зі збереженою версією файлу.
Чим відрізняється день junior, middle і senior-дизайнера
Junior частіше отримує обмежену частину сценарію та працює всередині вже ухвалених рішень. Його головне завдання полягає в тому, щоб навчитися бачити систему: використовувати компоненти, враховувати стани, ставити запитання, пояснювати вибір і не приховувати прогалини під красивою графікою. Проблема багатьох новачків у тому, що вони намагаються довести свою цінність оригінальністю екрана. Команді в цей момент більше потрібні передбачуваність, акуратність і здатність довести рішення до розробки.
Middle веде завдання повністю. Він уміє відокремити запит від проблеми, зібрати контекст, запропонувати варіанти, провести рев’ю, домовитися з розробкою та перевірити результат. Його оцінюють не за тим, наскільки ефектно виглядає окремий фрейм, а за якістю ланцюжка рішень. Middle уже повинен розуміти, коли варто сперечатися, коли перевіряти гіпотезу, а коли прийняти обмеження, яке йому не подобається.
Senior працює не лише з інтерфейсом, а й з умовами, у яких інтерфейс з’являється. Він впливає на постановку завдання, якість даних, порядок ухвалення рішень, дизайн-систему та взаємодію функцій. Він раніше помічає, що команда лікує не ту проблему, і вміє сказати про це так, щоб зустріч не перетворилася на публічне з’ясування інтелектуальної переваги. Старший дизайнер не зобов’язаний швидше за всіх видавати найкрасивіший варіант. Його цінність часто полягає в тому, що команда не починає дорогу безглузду роботу.
Що вищий рівень, то менше часу може залишатися на спокійне малювання. Додаються зустрічі, синхронізації, розбір чужих рішень, планування та відповідальність за цілісність продукту. Людина отримує більше впливу й водночас більше способів провести день без жодного нового екрана. Для тих, хто йшов у професію заради восьми годин наодинці з візуалом, кар’єрне зростання іноді виглядає як дуже якісно спроєктована пастка.
Кому підійде ця робота, а кому швидко зіпсує характер
UI/UX-дизайн підходить людям, яким цікаво розбирати незрозумілі завдання, спостерігати за поведінкою, збирати систему з обмежень і постійно уточнювати власні рішення. Тут корисні допитливість, терпимість до невизначеності, увага до деталей і здатність розмовляти з дуже різними фахівцями. Любов до візуалу важлива, але сама собою не витягне день, половина якого минає в запитаннях, аргументах і перевірці винятків.
Робота буде важкою для людини, якій потрібна постійна зовнішня похвала. Більшість хороших рішень користувачі не помічають. Вони просто проходять сценарій без помилок. Керівник рідко пише: «Сьогодні я особливо оцінив послідовність станів форми». Зате зламана кнопка збирає аудиторію швидше за безплатний концерт. Зворотний зв’язок розподіляється нерівномірно: нормальна робота мовчить, дефект вмикає сирену.
Складно буде й тому, хто сприймає кожну правку як вторгнення на особисту територію. Продуктовий макет належить команді та бізнесу, а після релізу ще й зустрічається з користувачами, які не зобов’язані берегти авторський задум. Водночас повна відсутність позиції теж руйнівна. Якщо людина готова нескінченно пересувати елементи без запитання «навіщо», вона швидко втомиться й перестане розвиватися.
Нарешті, професія не підходить тим, хто хоче одного разу вивчити правильні правила. Правила змінюються разом із платформами, продуктами й контекстом. Навіть сталі принципи потребують інтерпретації. Не можна механічно поставити головну кнопку праворуч, скоротити сценарій до трьох кроків і оголосити перемогу. Іноді додатковий крок підвищує довіру. Іноді звичний патерн не працює для конкретної аудиторії. Іноді найкращий екран той, який команда вирішила не створювати.
То що ж дизайнер робить увесь день
Він перетворює туманне прохання на завдання, завдання на гіпотезу, гіпотезу на сценарій, сценарій на інтерфейс, інтерфейс на домовленість, а домовленість на продукт, який має пережити розробку й реальних людей. Між цими перетвореннями він пояснює, сперечається, скорочує, перевіряє, документує й іноді фарбує кнопку в зелений, тому що експеримент теж потребує матеріалу.
Робота UI/UX-дизайнера відбувається не між логікою та правками, наче одне є благородним ремеслом, а друге безглуздим покаранням. Правки теж несуть інформацію. Вони показують страхи бізнесу, прогалини в аргументації, приховані обмеження й різницю між тим, що команда збиралася сказати, і тим, що побачила інша людина. Проблема починається лише тоді, коли інформацію не розбирають, а відразу перетворюють на пікселі.
Професіоналізм тут вимірюється не кількістю відбитих коментарів і не слухняністю. Він вимірюється якістю рішень після зіткнення з реальністю. Сильний дизайнер здатний захистити принцип, змінити слабкий варіант, визнати нестачу даних, зафіксувати ризик і довести компроміс до робочого стану. Іноді після цього виходить помітне покращення продукту. Іноді виходить зелена кнопка.
Наступного дня аналітика ще нічого не покаже, керівник принесе новий приклад конкурента, розробник знайде додаткове обмеження, а користувач зробить те, чого не було в жодному сценарії. Дизайнер знову відкриє файл і почне з’ясовувати, що саме відбувається. Тому що інтерфейс можна завершити до дедлайну. Розуміння продукту до дедлайну не завершується.
