UX/UI дизайн сайту: процес від дослідження до передачі

UX і UI: у чому різниця і чому вона коштує грошей

UX — це те, як сайт працює. UI — це те, як він виглядає. Дизайн починається не з картинки, а з розв'язання задачі людини. Якщо відвідувач не розуміє, куди натиснути, найкрасивіший інтерфейс не врятує: він просто закриє вкладку й піде до конкурента, у якого кнопка була на видноті.

Формально користувацький досвід (user experience) — це весь шлях людини: як вона потрапила на сайт, що шукала, що знайшла, скільки кроків зробила, де перечепилася, що відчула наприкінці. UI (user interface) — візуальний шар цього шляху: типографіка, колір, сітка, стани кнопок, іконки, відступи. Шари пов'язані, але розв'язують різні задачі.

Чому різниця комерційна, а не теоретична

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

Звідси проста формула: UX відповідає за те, чи дійде людина до мети, UI — за те, чи повірить вона вам дорогою. Потрібні обидва шари. Але якщо доводиться обирати, що лагодити першим, лагодьте логіку.

Чого дизайн НЕ робить

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

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

Крок 1. Дослідження, цілі та розбір конкурентів

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

Що з'ясовуємо на старті

• Бізнес-мета. Заявки? Замовлення? Записи на прийом? Резюме на вакансію? Головна мета одна, решта — другорядні.
• Цільова дія. Конкретна кнопка, яку людина має натиснути. Якщо їх п'ять і всі «головні» — не натиснуть жодної.
• Аудиторія. Хто ці люди, наскільки вони розуміються на темі, з якого пристрою заходять, що вже знають про вас.
• Заперечення. Чому людина вагається: дорого, довго, незрозуміло, «а раптом обдурять», «а чи зроблять під мою задачу».
• Обмеження. Терміни, бюджет, наявна CRM, айдентика, вимоги юристів.

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

Розбір конкурентів — не для копіювання

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

Евристичний аудит

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

Крок 2. Сценарії користувачів замість «сторінок»

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

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

Скільки сценаріїв потрібно

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

Різні стани — різні екрани

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

• Порожній — фільтр нічого не знайшов, кошик порожній, замовлень ще немає. Що людина тут бачить і куди йде далі?
• Завантаження — що показуємо, поки дані їдуть.
• Помилка — сервер упав, оплата не пройшла, поле заповнене неправильно.
• Переповнення — назва на три рядки, 40 товарів, відгук на 2000 знаків.
• Успіх — заявку надіслано. Що далі? «Дякуємо» — це не відповідь, людина хоче знати, коли їй зателефонують.

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

Крок 3. Інформаційна архітектура

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

Робота проста на словах і марудна на ділі: зібрати весь контент, згрупувати за змістом, назвати групи словами клієнта, вибудувати пріоритет. Ключове — словами клієнта. Розділ «Рішення» зрозумілий вам, але людина шукає «ремонт холодильників». Внутрішня структура компанії не має протікати в меню.

Правила, які економлять час

• Меню — не звалище. П'ять–сім пунктів верхнього рівня. Якщо не вміщається — отже, групування хибне.
• Глибина ≤ 3 кліків до будь-якої важливої сторінки. Далі починаються втрати.
• Один зміст — одна сторінка. Дві схожі сторінки конкурують одна з одною і в навігації, і в пошуку.
• Назва = запит. Пункт меню має збігатися з тим, як про це думає й говорить людина.

Пріоритет на сторінці

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

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

Перевірка архітектури без макета

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

Крок 4. Wireframes: скелет без косметики

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

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

Що має бути у вайрфреймі

• Справжні заголовки й підписи, а не «Lorem ipsum». Текст-риба бреше і про довжину, і про зміст.
• Реальна кількість елементів: якщо в каталозі 12 позицій, не малюйте три.
• Усі ключові стани з попереднього кроку.
• Мобільна й десктопна версії ключових екранів — одразу, а не «потім адаптуємо».

Скільки екранів малювати

Не всі. Малюють типи сторінок: головна, сторінка послуги, каталог, картка, форма, стаття, контакти, службові (404, «дякуємо»). Решта збирається з тих самих блоків. Якщо для кожної нової сторінки потрібен новий макет — у вас немає системи, у вас набір картинок.

Погодження на цьому етапі — найдешевше

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

Крок 5. UI-концепція: як виглядає довіра

Коли структуру погоджено, з'являється візуальний шар. Його задача — не «прикрасити», а зробити структуру очевидною і викликати довіру.

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

З чого складається UI-концепція

• Типографіка. Шрифтова пара, розміри, інтерліньяж, довжина рядка. Це 80% відчуття від сайту, бо сайт — це здебільшого текст.
• Колір. Нейтральна база, один акцент під цільову дію, службові кольори для помилок і успіху. Акцентний колір витрачається лише на головне — інакше він перестає працювати.
• Сітка й ритм. Єдиний крок відступів (наприклад, кратний 4 або 8) замість «на око».
• Фото і графіка. Власні знімки процесу й людей працюють краще за ідеальні стоки, бо стокам ніхто не вірить.
• Тон. Інтерфейс говорить: суворо, дружньо, технічно. Це теж рішення, а не випадковість.

Концепція — це один екран, а не весь сайт

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

І головне: концепція оцінюється не «подобається/не подобається», а «чи працює на задачу». Про це — у розділі про зворотний зв'язок.

Крок 6. Дизайн-система і компоненти

Дизайн-система — це набір готових цеглин і правила, як із них будувати. Кнопки, поля, картки, заголовки, відступи, стани — описані один раз і перевикористані всюди.

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

Що входить у систему

• Токени. Кольори, шрифтові розміри, радіуси, тіні, крок сітки — як іменовані змінні, а не як значення «по місцю».
• Компоненти. Кнопка з усіма станами (звичайна, наведення, фокус, натискання, завантаження, вимкнена), поле введення з помилкою і підказкою, картка, модалка, таблиця, пагінація.
• Правила композиції. Коли який заголовок, скільки повітря між блоками, як поводяться елементи при переповненні.
• Патерни. Форма, фільтр, оформлення замовлення — типові збірки з компонентів.

Навіщо це клієнту, а не лише дизайнеру

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

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

Крок 7. Прототип, передача в розробку і дизайн-QA

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

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

Що входить у передачу розробнику

• Макети у двох-трьох ключових ширинах: мобільна, планшет/проміжна, десктоп.
• Усі стани компонентів і екранів.
• Токени і правила: кольори, шрифти, крок сітки, поведінка при переповненні.
• Поведінка: що клікабельне, що відкривається, що анімується і скільки мілісекунд.
• Тексти — фінальні, а не приблизні. Ассети — іконки, зображення, логотипи в потрібних форматах.
• Крайні випадки: дуже довга назва, відсутність фото, нуль результатів.

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

Дизайн-QA: перевірка після збірки

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

Мобільні пристрої та доступність простими словами

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

Mobile-first — це дисципліна пріоритетів. На маленькому екрані не можна показати все одразу, тому доводиться чесно відповісти, що важливіше. Відповідь на це питання потім покращує і десктопну версію.

Що перевіряють у мобільній версії

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

Доступність: чотири речі, які дають 80% результату

• Контраст. Світло-сірий текст на білому гарний на макеті й нечитабельний надворі на сонці. Контраст потрібен і людям зі слабким зором, і вам — на дешевому екрані в дорозі.
• Фокус. При навігації з клавіатури видно, на якому елементі ви перебуваєте. Прибирати обведення фокуса «заради краси» — поширена і груба помилка.
• Клавіатура. Усю форму можна заповнити й надіслати, не торкаючись миші. Модалку можна закрити, з меню можна вийти.
• Alt-тексти. Короткий опис змісту зображення. Допомагає незрячим користувачам і заразом пошуку.

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

Текст — це теж дизайн

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

Звідси правило: дизайн без готового контенту — це гадання. Дизайнер вигадує заголовок на три слова, а в клієнта він на дванадцять. Вигадує три переваги, а справжніх дві й вони інші. Макет розвалюється на етапі наповнення, і всі дивуються.

Слова, які лагодять інтерфейс

• Кнопка описує результат. «Отримати розрахунок» краще, ніж «Надіслати». Людина має розуміти, що станеться після натискання.
• Заголовок відповідає, а не інтригує. «Розробка сайтів для медичних центрів» працює; «Ми створюємо майбутнє» — ні.
• Помилка пояснює, що робити. «Невірний формат» — погано. «Введіть телефон у форматі +380…» — добре.
• Підписи замість здогадок. Якщо поле потребує специфічних даних, скажіть це до помилки, а не після.
• Менше слів на тому самому змісті. Кожне зайве речення знижує шанс, що прочитають потрібне.

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

Як давати корисний зворотний зв'язок і скільки правок нормально

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

Формула робочого коментаря

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

Правила, які пришвидшують погодження

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

Скільки ітерацій — нормально

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

Типові помилки, які дорого коштують

• Дизайн без контенту. Макет по «рибі» розвалюється при наповненні. Завжди.
• Копіювання конкурента. Ви копіюєте картинку, не знаючи, чи працює вона в нього.
• Прикрашання замість ясності. Анімації, паралакс і слайдери замість відповіді на питання «що ви продаєте».
• Багато цілей на одному екрані. П'ять рівнозначних кнопок = нуль натискань.
• Дизайн заради журі. Макет для конкурсу і макет для продажів — різні жанри.
• Ніхто не відповідає за приймання. Проєкт без власника рішень тягнеться місяцями.

Чек-лист: як оцінити дизайн до передачі в розробку

Перш ніж віддавати макети у верстку, пройдіть список. Кожен пункт — це правка ціною у хвилини зараз і в дні потім.

Зміст

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

Структура

• Блоки йдуть у логіці «відповідь → подробиці → докази → дія».
• Навігація: 5–7 пунктів, назви — словами клієнта, важливе в ≤3 кліках.
• Немає двох сторінок про одне й те саме.

Повнота макетів

• Є мобільна версія кожного типу сторінки, а не лише десктоп.
• Намальовані стани: порожньо, завантаження, помилка, успіх, довгий текст, багато елементів.
• Тексти фінальні, зображення справжні, «Lorem ipsum» відсутній.
• Є службові сторінки: 404, «дякуємо», сторінка помилки оплати, якщо вона потрібна.

Система і доступність

• Кнопки, поля й картки — з одного набору, а не намальовані наново на кожному екрані.
• Відступи кратні єдиному кроку, кольорів рівно стільки, скільки потрібно.
• Контраст тексту достатній, фокус видно, форму можна пройти з клавіатури.
• У зображень є alt-описи, у полів — підписи, у помилок — зрозумілий текст.

Готовність до збірки

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

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

Часті запитання