Мета роботи

Навчитися використовувати генеративний ШІ для швидкого візуального проєктування низькодеталізованих каркасів (wireframes), інтерактивних карт сайтів (sitemaps) та автоматизованого створення базових елементів дизайн-системи (UI-набір) в графічному редакторі Figma.

Стек інструментів для роботи

Раніше на проектування інформаційної архітектури, створення каркасів, підбір шрифтів та ручне вимальовування станів кнопок (Default, Hover, Active) йшли тижні. Сьогодні ШІ допомагає автоматизувати цю рутину за лічені хвилини. ШІ надає швидкість, але архітектором інтерфейсу залишається розробник.

Лабораторна робота №4 навчить студентів мислити системно, керувати ШІ-інструментами прототипування та закладати фундамент професійної дизайн-системи безпосередньо на платформі Figma.

  • Figma. Провідна хмарна платформа для UI/UX-дизайну та спільного проектування інтерфейсів, яка допомагає командам в реальному часі створювати, тестувати та передавати в розробку інтерактивні прототипи сайтів і додатків. Вона активно інтегрує інструменти штучного інтелекту (Figma AI), що автоматизують рутинне проектування, генерацію контенту та створення дизайн-систем.
  • ШІ-плагіни для Figma (Musho AI, Wireframer та їхні сучасні аналоги). Інтелектуальні асистенти, які за текстовим запитом миттєво генерують готові UI-набори, структуровані низькодеталізовані каркаси та адаптивні веб-дизайни. Вони виконують всю рутину від підбору гармонійних палітр і контенту до побудови складної сітки інтерфейсу, допомагаючи майбутнім фахівцям фокусуватися виключно на унікальному користувацькому досвіді (UX) та архітектурі продукту.
  • Relume AI. Потужний ШІ-інструмент для веб-дизайнерів та розробників, який за лічені секунди автоматично генерує детальні карти сайту та каркаси сторінок на основі простого текстового запиту. Сервіс є ідеальним стартовим майданчиком для проектування інтерфейсів, надає можливість миттєво експортувати готову структуру компонентів в Figma або конструктор сайтів для подальшої кастомізації.
  • Uizard. Інноваційний ШІ-інструмент для швидкого прототипування, який допомагає миттєво створювати інтерактивні макети сайтів і мобільних додатків на основі текстових запитів, сканів намальованих від руки ескізів або скріншотів готових інтерфейсів. Він кардинально зменшує поріг входу в UI/UX-дизайн, автоматизуючи рутинну роботу та перетворюючи ідеї в клікабельні прототипи за лічені хвилини.

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

Еволюція прототипування, від паперу до ШІ-генерації

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

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

Паперове прототипування

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

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

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

Низькодеталізовані каркаси

З появою цифрових інструментів паперові ескізи поступово трансформувалися в низькодеталізовані каркаси (Low-fidelity Wireframes) — прості схематичні моделі сторінок, які відображають розміщення основних елементів інтерфейсу.

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

На цьому етапі визначаються:

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

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

Високодеталізовані прототипи

Наступним етапом еволюції стали високодеталізовані прототипи (High-fidelity Prototypes), які є максимально наближеними до фінального вигляду продукту. Вони містять реальні кольори, шрифти, зображення, іконки, анімації та інтерактивні елементи.

Сучасні інструменти прототипування допомагають створювати інтерактивні макети, де користувач може натискати кнопки, переходити між сторінками, відкривати меню та виконувати типові дії. Це надає можливість проводити тестування UX ще до написання програмного коду.

ШІ-прототипування

Сучасний етап еволюції пов’язаний з появою штучного інтелекту в процесі проєктування інтерфейсів. ШІ-інструменти, такі як Relume AI, Uizard та інші, автоматизують рутинні завдання та значно скорочують час створення початкових макетів.

Дизайнеру достатньо описати майбутній сайт за допомогою текстового запиту, наприклад: «Створити головну сторінку сайту онлайн-школи з hero-секцією, описом курсів, відгуками студентів і формою реєстрації».

ШІ аналізує великі масиви даних про поширені шаблони вебдизайну та генерує логічну структуру сторінки: хедер, меню, перший екран (hero секція), блоки переваг, картки контенту, форми, заклики до дії (Call To Action, CTA) та футер.

Основні переваги ШІ-прототипування.

  • Значне прискорення створення першого варіанту макету.
  • Генерація різних варіантів структури сторінки.
  • Використання перевірених UX-шаблонів.
  • Допомога дизайнерам-початківцям у формуванні логічної структури.
  • Можливість швидкого внесення змін через нові текстові запити.

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

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

Компонентний підхід та атомарний дизайн в Figma

Сучасна розробка цифрових інтерфейсів значною мірою базується на компонентному підході та концепції атомарного дизайну (Atomic Design). Замість створення кожного елемента інтерфейсу окремо дизайнери розглядають інтерфейс як систему взаємопов’язаних блоків, які можна повторно використовувати, змінювати та масштабувати. Такий підхід покладено в основу сучасних дизайн-систем та UI-наборів.

Концепція атомарного дизайну

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

Основні рівні атомарного дизайну

  • Атоми (Atoms) — найпростіші елементи інтерфейсу, які не можна розділити на менші функціональні частини. До них належать кнопки, іконки, поля введення, кольори, типографічні стилі, відступи та інші базові елементи.
  • Молекули (Molecules) — групи атомів, які працюють разом та виконують певну функцію. Наприклад, поле пошуку може складатися з поля введення, іконки пошуку та кнопки запуску пошуку.
  • Організми (Organisms) — більші функціональні блоки інтерфейсу, що складаються з кількох молекул і атомів. Прикладом можуть бути шапка сайту (Header), картка товару, панель навігації або форма реєстрації.
  • Шаблони (Templates) — структура сторінки, яка визначає розташування організмів і загальну композицію інтерфейсу без наповнення реальним контентом.
  • Сторінки (Pages) — завершені макети з реальними текстами, зображеннями та даними, які демонструють, як виглядатиме фінальний продукт.

Такий поділ надає можливість створювати складні інтерфейси поступово — від простих елементів до повноцінних сторінок.

Компоненти в Figma

В платформі Figma центральним елементом компонентного підходу є компонент (Component) — багаторазово використовуваний елемент інтерфейсу, який служить шаблоном для всіх своїх копій.

Існують два основних поняття

  • Головний компонент (Main Component) — оригінальний елемент, в якому задаються всі основні характеристики: форма, колір, розміри, типографіка, відступи, стани взаємодії тощо.
  • Екземпляр (Instance) — копія головного компонента, яка використовується на різних сторінках або екранах проєкту. Екземпляри зберігають зв’язок з головним компонентом і автоматично отримують його оновлення.

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

Принцип наслідування та централізоване оновлення

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

Наприклад, якщо дизайнер вирішує:

  • змінити основний колір кнопки;
  • змінити радіус заокруглення кутів;
  • змінити шрифт або розмір тексту;
  • скоригувати внутрішні відступи;
  • додати новий стан кнопки (наприклад, при наведенні курсору або неактивну),

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

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

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

Варіанти компонентів в Figma

Окрім звичайних компонентів, Figma підтримує варіанти — різні стани одного й того самого компонента.

Наприклад, для кнопки можна створити такі варіанти:

  • Primary (основна кнопка).
  • Secondary (додаткова кнопка).
  • Hover (стан наведення курсору).
  • Pressed (стан натискання).
  • Disabled (неактивний стан).

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

Переваги компонентного підходу
  • Повторне використання елементів — один компонент може застосовуватися багато разів.
  • Швидкість розробки — дизайнери не створюють однакові елементи повторно.
  • Стилістична єдність — всі екрани мають однаковий вигляд і поведінку.
  • Легкість внесення змін — оновлення одного компонента автоматично змінює всі його екземпляри.
  • Ефективна командна робота — дизайнери та розробники працюють з єдиною бібліотекою компонентів.
  • Масштабованість — інтерфейс можна легко розширювати без втрати якості та узгодженості.

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

Теорія станів та мікровзаємодій в інтерфейсному дизайні

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

Мікровзаємодії

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

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

Такі невеликі деталі створюють відчуття «живого» інтерфейсу та значно покращують користувацький досвід.

Теорія станів

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

1. Default (Звичайний стан)

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

Для кнопки це може бути

  • основний колір бренду;
  • стандартний розмір;
  • звичайна тінь або контур;
  • типовий стиль тексту.

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

2. Hover (Стан наведення)

Hover виникає тоді, коли користувач підводить курсор миші до елемента. Цей стан характерний переважно для настільних пристроїв, де використовується курсор. Основна мета Hover — показати користувачу, що елемент є інтерактивним і з ним можна виконати дію.

Типові зміни в цьому стані:

  • Колір стає на 10–15% світлішим або темнішим.
  • Збільшується контрастність.
  • З’являється або змінюється тінь.
  • Кнопка може трохи збільшуватися.
  • Змінюється форма курсора (наприклад, на значок руки).

Такі ефекти створюють чіткий сигнал: «Цей елемент можна натиснути».

3. Active/Pressed (Стан натискання)

Active або Pressed — це короткочасний стан, який виникає в момент натискання кнопки мишею або торкання екрана на мобільному пристрої. Його призначенням є надання користувачу відчуття фізичної взаємодії з об’єктом, ніби кнопка дійсно натискається.

Візуально цей ефект може реалізовуватися через:

  • Невелике зменшення масштабу елемента (наприклад, до 95–98%).
  • Зміну внутрішньої або зовнішньої тіні.
  • Затемнення кольору.
  • Зменшення відстані між елементом та його тінню.

Такі зміни імітують фізичне натискання кнопки та роблять взаємодію більш природною.

4. Focus (Стан фокусування)

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

Найчастіше він позначається:

  • Кольоровою рамкою навколо елемента.
  • Підсвіткою (outline або glow).
  • Зміною кольору межі.

Наявність чіткого стану Focus є важливою вимогою доступності (Accessibility), оскільки допомагає користувачам, які працюють з клавіатурою або спеціальними пристроями введення.

5. Disabled (Неактивний стан)

Disabled означає, що елемент є тимчасово недоступним для взаємодії. Наприклад, кнопка «Надіслати» може бути неактивною, поки користувач не заповнить всі обов’язкові поля форми.

Ознаки цього стану:

  • Зменшена яскравість або прозорість.
  • Сірий колір.
  • Відсутність реакції на наведення чи натискання.

Головна вимога — користувач повинен розуміти, що елемент існує, але наразі недоступний.

6. Loading (Стан завантаження)

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

Типові приклади:

  • Анімація обертання (spinner).
  • Індикатор прогресу.
  • Скелетон-завантаження (skeleton screens).
  • Зміна тексту кнопки на «Завантаження…».

Цей стан допомагає уникнути невизначеності та запобігає повторним натисканням кнопок.

Роль мікровзаємодій в сучасному UX

Якісно реалізовані мікровзаємодії виконують кілька важливих функцій.

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

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

Теорія станів і мікровзаємодій є невід’ємною частиною сучасного UI/UX-дизайну. Інтерактивний елемент повинен мати зрозумілі стани Default, Hover, Active, Focus, Disabled та Loading, які повідомляють користувачу про поточний стан системи. Правильно спроєктовані мікровзаємодії роблять інтерфейс більш інтуїтивним, зручним і створюють відчуття живої взаємодії між людиною та цифровим продуктом.

Колірний контраст та вимоги доступності

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

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

Колірний контраст — це ступінь відмінності між двома кольорами, найчастіше між кольором тексту та кольором фону. Чим вищий контраст, тим легше користувачеві прочитати інформацію. Наприклад:

  • Чорний текст на білому фоні має дуже високий рівень контрастності та легко сприймається.
  • Світло-сірий текст на білому фоні має низький контраст і може бути важким для читання.
  • Яскраві кольори, які добре виглядають в палітрі, не завжди є достатньо контрастними при використанні в інтерфейсі.

Недостатній контраст створює проблеми не лише для людей з порушеннями зору, але й для користувачів, які працюють з сайтом:

  • на екранах з низькою якістю передачі кольору;
  • на мобільних пристроях під яскравим сонячним світлом;
  • в стані втоми або при тривалому читанні великої кількості тексту.
Стандарти доступності WCAG

Для забезпечення доступності цифрових продуктів використовуються міжнародні рекомендації WCAG (Web Content Accessibility Guidelines) — набір правил, що розроблений для створення вебресурсів, зручних для всіх користувачів.

Однією з ключових вимог WCAG є дотримання мінімального рівня контрастності між текстом і фоном.

Основні вимоги до контрастності:

  • Звичайний текст (розмір менше 18 рх або менше 14 рх жирним шрифтом) повинен мати співвідношення контрастності щонайменше 4.5:1.
  • Великий текст (від 18 рх або від 14 рх жирним шрифтом) може мати нижчий рівень контрастності — не менше 3:1.
  • Елементи інтерфейсу та графічні об'єкти (кнопки, поля введення, іконки, межі форм) також повинні забезпечувати мінімальний контраст 3:1.

Вищий рівень контрастності покращує зручність використання інтерфейсу для всіх категорій користувачів.

Роль штучного інтелекту у виборі кольорів

Сучасні ШІ-плагіни можуть значно прискорити процес створення дизайн-системи. Вони здатні:

  • Генерувати кілька варіантів кольорових схем.
  • Підбирати гармонійні поєднання основних та додаткових кольорів.
  • Адаптувати палітру до стилю бренду.
  • Пропонувати сучасні трендові рішення.

Однак генеративний ШІ не повинен розглядатися як остаточний арбітр якості дизайну. Наприклад, модель може запропонувати дуже стильне поєднання світло-блакитного тексту на білому фоні, яке виглядає мінімалістично, але не відповідає вимогам читабельності.

Тому професійний процес дизайну має виглядати так:

ШІ-генерація палітри → Аналіз дизайнером → Перевірка доступності → Затвердження кольорової системи.

Перевірка контрастності у Figma

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

В середовищі Figma для цього використовуються плагіни-валідатори контрасту, які автоматично обчислюють співвідношення контрастності між кольорами та показують відповідність стандартам WCAG. Такі інструменти спроможні:

  • Перевірити контраст тексту та фону.
  • Знайти проблемні колірні комбінації.
  • Отримати рекомендації щодо покращення контрастності.
  • Оцінити відповідність рівням доступності.

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

Типові помилки при роботі з кольорами

Найпоширеніші проблеми, які зустрічаються у вебінтерфейсах:

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

Хороший дизайн повинен залишатися зрозумілим навіть для користувачів з частковою втратою зору або порушенням сприйняття кольорів.

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

Інженерна етика та критичне мислення при роботі з ШІ

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

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

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

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

Такі нюанси потребують людського аналізу, дослідження користувачів та розуміння контексту використання.

Типові помилки генерації ШІ в UI/UX-дизайні

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

1. Недостатній розмір тексту

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

  • Текст розміром менше 12 px може бути складним для сприйняття на мобільних пристроях.
  • Занадто малий міжрядковий інтервал ускладнює читання.
  • Недостатній контраст між текстом і фоном робить інформацію майже непомітною.

Тому, дизайнер повинен перевіряти типографіку на реальних розмірах екранів.

2. Погане розташування елементів керування

Згенерований інтерфейс може не враховувати ергономіку використання пристрою. Наприклад:

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

Дизайнер повинен враховувати принципи мобільної ергономіки, розміри зон дотику та природні рухи користувача.

3. Порушення принципів доступності (Accessibility)

ШІ може створити красивий, але недоступний інтерфейс:

  • Використання недостатнього контрасту кольорів.
  • Застосування тексту на складному фоновому зображенні.
  • Застосування занадто маленьких кнопок.
  • Передавання інформації лише за допомогою кольору.

Тому, всі ШІ-згенеровані рішення необхідно перевіряти на відповідність вимогам доступності, зокрема стандартам WCAG (Web Content Accessibility Guidelines).

4. Відсутність логіки користувацьких сценаріїв

ШІ добре генерує окремі екрани, але інколи не враховує повний шлях користувача (User Journey). Наприклад, сторінка реєстрації може виглядати чудово, але не враховувати:

  • Що станеться при неправильному введенні пароля?
  • Як користувач відновить забутий пароль?
  • Які повідомлення отримає після успішної реєстрації?
  • Як система поводитиметься при відсутності інтернет-з’єднання?

Саме такі сценарії визначають якість реального користувацького досвіду.

Роль UX-експерта в епоху штучного інтелекту

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

  • Критичний аналіз результатів генерації.
  • Розуміння психології поведінки користувачів.
  • Перевірка зручності та доступності інтерфейсу.
  • Адаптація дизайну під реальні сценарії використання.
  • Тестування та покращення взаємодії.

Фактично дизайнер перетворюється на редактора та архітектора ШІ-згенерованих рішень.

Практичний підхід: ШІ → Аналіз → Покращення → Тестування

Професійний процес роботи з ШІ-дизайном повинен складатися з кількох етапів:

  1. Генерація ідеї за допомогою ШІ. Створення початкового макета, структури сторінки, кольорової палітри або набору компонентів.
  2. Експертний аналіз. Перевірка логіки інтерфейсу, читабельності, доступності та відповідності бізнес-цілям.
  3. Адаптація та доопрацювання. Корекція розмірів елементів, кольорів, текстів, навігації та користувацьких сценаріїв.
  4. Тестування з реальними користувачами. Збір зворотного зв’язку, виявлення проблем та подальше покращення продукту.
Етичні аспекти використання ШІ

Інженерна етика також передбачає відповідальне використання штучного інтелекту. Дизайнер повинен:

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

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

Покроковий хід виконання роботи

Лабораторна робота виконується на основі вебпроєкту, розробленого під час попередніх лабораторних робіт.

В роботі необхідно використовувати результати:

  • Лабораторна робота №1. Концепція вебпроєкту, цільова аудиторія, структура проєкту.
  • Лабораторна робота №2. Контент, структура та SEO-матеріали.
  • Лабораторна робота №3. Логотип, іконки, графічні та мультимедійні UX/UI-активи.

Основним середовищем роботи є Figma. Для генерації інформаційної архітектури та початкових каркасів можна використовувати Relume AI, Uizard або інші доступні ШІ-інструменти прототипування.

Етап 1. Аналіз проєкту та підготовка UX-вимог

Перед початком створення макету необхідно визначити, що саме користувач повинен зробити на сайті. ШІ не повинен одразу генерувати дизайн сторінки. Спочатку потрібно сформувати UX-вимоги.

  1. Визначити основну мету вебпроєкту. На основі матеріалів попередніх лабораторних робіт сформулювати:
    • основну мету сайту;
    • цільову аудиторію;
    • основну потребу користувача;
    • головну дію (Primary CTA);
    • другорядні дії;
    • основні сторінки;
    • ключові функції.
  2. Приклад промпту
  3. Дій як senior UX architect. Проаналізуй наступний веб-проект:
    Проект: [назва проекту]
    Опис: [опис]
    Цільова аудиторія: [цільова аудиторія]
    Основна бізнес-ціль: [мета]
    Потреби користувача: [потреби користувачів]
    Зміст: [короткий опис контенту]
    На основі цієї інформації визнач:
    1. Основна мета користувача.
    2. Основна бізнес-ціль.
    3. 3–5 ключових потреб користувача.
    4. Первинний Заклик до дії (CTA).
    5. Вторинні заклики до дії.
    6. Необхідні сторінки сайту.
    7. Ключові блоки контенту для головної сторінки.
    8. Потенційні ризики UX.
    Поки не розробляй візуальний інтерфейс. Зосередься лише на інформаційній архітектурі та взаємодії з користувачем.
    
  4. Студент отримує UX-вимоги, які використовуватиме на наступних етапах.
Етап 2. Проєктування Шляху Користувача (User Flow)
  1. Після визначення цілей необхідно спроєктувати шлях користувача.
    • Наприклад, Головна → Каталог → Сторінка послуги → Форма → Підтвердження.
    • або Головна → Курс → Деталі → Реєстрація → Оплата → Підтвердження.
  2. Сформувати основні користувацькі сценарії, створити щонайменше 2–3 основні шляхи користувача.
  3. Приклад промпту
  4. Дій як UX-дизайнер. 
    На основі цього вебсайту: [опис проєкту]
    Створи 3 критично важливі сценарії взаємодії користувача (user flows).
    Для кожного сценарію визнач:
    1. Мета користувача.
    2. Початкова точка.
    3. Послідовність екранів.
    4. Дії користувача.
    5. Реакції системи.
    6. Стан успішного завершення.
    7. Можливий стан помилки.
    Використовуй просту покрокову структуру. Зосередься на реалістичній поведінці користувача, а не на візуальному дизайні.
    
  5. Студент повинен отримати схему користувацьких сценаріїв і перевірити:
    • Чи немає зайвих кроків?
    • Чи зрозуміло, куди переходить користувач?
    • Чи є завершення сценарію?
    • Чи передбачено помилки?
Етап 3. Створення Карти сайту (Sitemap)
  1. Згенерувати структуру сайту. Використати Relume AI, Uizard або інший доступний ШІ-інструмент.
  2. Розроби чітку карту сайту для проєкту:
    Проєкт: [назва]
    Мета: [мета]
    Цільова аудиторія: [аудиторія]
    Сайт повинен містити такі розділи:
    1. Головна
    2. Про нас
    3. Послуги
    4. Деталі послуги
    5. Блог
    6. Контакти
    Визнач ієрархію сторінок і логічну навігацію між ними. Структура має бути простою та придатною для адаптивного сайту. Надай пріоритет потребам користувачів та інтуїтивно зрозумілій навігації.
    
  3. Для реального проєкту студент повинен замінити згенеровані сторінки на власні.
  4. Проаналізувати карту сайту. ШІ-згенеровану структуру не можна приймати автоматично, потрібно перевірити:
    • Чи присутні всі необхідні сторінки?
    • Чи немає дублювання сторінок?
    • Чи є ієрархія логічною?
    • Чи навігація є зрозумілою?
    • Чи відповідає структура Шляху Користувача?
  5. Приклад коригувального промпту
  6. Проаналізуй запропоновану карту сайту з погляду UX.
    Визнач:
    - зайві сторінки;
    - відсутні сторінки;
    - заплутану навігацію;
    - дубльований контент;
    - сторінки, для переходу на які потрібно забагато кліків.
    Запропонуй вдосконалену карту сайту. Не додавай сторінки, якщо вони не сприяють досягненню конкретної мети користувача.
    
Етап 4. Створення низькодеталізованого Каркасу (Low-fidelity Wireframe)

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

  1. Визначити структуру головної сторінки, наприклад: Header, Navigation, Hero, Features, Benefits, Content section, Testimonials, CTA, Footer.
  2. Приклад промпту
  3. Створи схематичний каркас (wireframe) низької деталізації для головної сторінки цього вебсайту:
    Проєкт: [назва]
    Цільова аудиторія: [аудиторія]
    Основна мета: [мета]
    Основний заклик до дії (CTA): [CTA]
    Обов’язкові розділи:
    - Шапка (header) з навігацією
    - Головний екран (hero section)
    - Функціональні можливості (features)
    - Переваги (benefits)
    - Основний контент
    - Відгуки
    - Заклик до дії (CTA)
    - Підвал (footer)
    Вимоги до UX:
    - чітка візуальна ієрархія;
    - проста навігація;
    - виразний основний заклик до дії (CTA);
    - логічна послідовність контенту;
    - адаптивна структура;
    - достатньо вільного простору.
    Використовуй схематичний макет низької деталізації у відтінках сірого. Не використовуй декоративні кольори чи деталізовані зображення.
    
  4. Перенести Каркас в Figma.
  5. В Figma створити окремий Frame: 01 — Wireframe.
  6. Використовувати прості прямокутники, текстові блоки, кнопки, placeholder-зображення, прості навігаційні елементи.
Етап 5. Аналіз Каркасу та UX-корекція

ШІ може створити візуально логічний макет, але пропустити проблеми користувацького сценарію і не врахувати повний Шлях Користувача.

  1. Провести UX-аудит та перевірити:
    • Чи зрозуміло, що робити на першому екрані?
    • Чи видно Основний заклик до дії?
    • Чи є логічна послідовність секцій?
    • Чи не перевантажена сторінка?
    • Чи є зрозумілою навігація?
    • Чи достатньо інформації для прийняття рішення користувачем?
    • Чи передбачено помилки та альтернативні сценарії?
  2. Приклад промпту для UX-аудиту
  3. Виступай в ролі старшого UX-експерта.
    Проаналізуй цей каркас (wireframe) вебсайту: [опис або зображення каркасу]
    Оціни:
    1. Інформаційну ієрархію.
    2. Навігацію.
    3. Шлях користувача (user flow).
    4. Видимість закликів до дії CTA.
    5. Пріоритетність контенту.
    6. Когнітивне навантаження.
    7. Зручність використання на мобільних пристроях.
    8. Доступність (accessibility).
    9. Відсутні стани (missing states).
    10. Потенційні UX-проблеми.
    Для кожної проблеми:
    - опиши проблему;
    - поясни, чому це важливо;
    - запропонуй конкретне покращення.
    Поки що не займайся редизайном інтерфейсу. Зосередься на UX-проблемах.
    
  4. Після аналізу внести необхідні зміни в Каркас.
Етап 6. Створення UI-концепції

На цьому етапі студент переходить від UX до UI.

  1. В роботу перенести результати Лабораторної роботи №3: логотип, колірну концепцію, іконки, Hero-графіку, інші візуальні активи.
  2. Сформувати UI-напрям в кольорах. Визначити: Основний, вторинний та акцентний кольори, кольори фону та елементів, кольори простого та приглушеного текстів, успіху, попередження, помилки.
  3. Приклад промпту
  4. Виступай в ролі професійного UI-дизайнера. Розроби концепцію сучасного візуального дизайну для цього вебпроєкту:
    Проєкт: [назва]
    Цільова аудиторія: [аудиторія]
    Характер бренду: [3–5 характеристик]
    Наявні кольори бренду: [кольори]
    UI-система має визначати:
    1. Основний колір.
    2. Додатковий колір.
    3. Акцентний колір.
    4. Кольори фону.
    5. Кольори поверхонь (surface colors).
    6. Основний колір тексту.
    7. Додатковий колір тексту.
    8. Кольори для станів успіху, попередження та помилки.
    9. Поєднання шрифтів.
    10. Радіус заокруглення кутів.
    11. Стиль кнопок.
    12. Стиль карток.
    13. Стиль тіней.
    Надавай перевагу читабельності, цілісності та доступності, а не декоративним ефектам.
    
Етап 7. Формування Дизайн-компонентів (Design Tokens)

Перед створенням великої кількості компонентів необхідно зафіксувати базові параметри дизайн-системи.

  1. В Figma Створити основні дизайн-компоненти.
  2. Приклад промпту
  3. Розроби масштабовану систему дизайн-токенів для сучасного адаптивного вебсайту.
    Використовуй такий візуальний стиль: [опис стилю]
    Визнач токени для:
    Кольорів: основний (Primary), вторинний (Secondary), акцентний (Accent), фон (Background), поверхня (Surface), текст (Text), приглушений (Muted), успіх (Success), попередження (Warning), помилка (Error).
    Типографіки: Display, H1, H2, H3, Body, Small, Caption.
    Відступів: 4, 8, 12, 16, 24, 32, 48, 64 px.
    Також визнач:
    - радіус заокруглення кутів (border radius);
    - стилі меж (border styles);
    - рівні тіней (shadow levels);
    - ширину контейнера.
    Зроби систему простою та придатною для багаторазового використання. Не створюй окремих стилів для конкретних сторінок.
    
Етап 8. Перевірка доступності кольорів
  1. Перед створенням створення компонентів необхідно перевірити палітру (їх контрастність, поєднання).
    • текст/фон;
    • кнопка/фон;
    • текст кнопки/кнопка;
    • іконки;
    • межі полів;
    • стан фокусу (кнопка, посилання).
  2. Приклад промпту
  3. Проведи аудит цієї колірної палітри інтерфейсу на відповідність вимогам доступності.
    Перевір:
    - контрастність звичайного тексту;
    - контрастність великого тексту;
    - контрастність тексту на кнопках;
    - контрастність інтерактивних елементів;
    - індикатори фокусу.
    Цільовий стандарт: WCAG 2.2 AA.
    Для кожної проблемної комбінації:
    1. вкажи на проблему з контрастністю;
    2. запропонуй колір на заміну;
    3. збережи загальний фірмовий стиль.
    Не змінюй кольори, які вже відповідають вимогам.
    
  4. Результат ШІ необхідно додатково перевірити спеціальним інструментом перевірки контрастності, а не покладатися лише на відповідь моделі.
Етап 9. Створення бібліотеки компонентів (UI Kit)

Бібліотека має відповідати підходу Атомарний дизайн: Атоми → Молекули → Організми → Шаблони → Сторінки.

  1. Створити окремий Frame: 02 — UI Kit / Design System
  2. Створити базові компоненти, принаймні мінімальний набір:
    • Атоми: логотип, іконка, кнопка, поле введення, прапорець, радіокнопка, бейдж.
    • Молекули: поле пошуку, поле форми, елемент навігації, заголовок картки.
    • Організми: шапка, навігація, картка, форма, підвал.
Етап 10. Створення компонента Кнопка (Button) та її станів
  1. Створити Основний компонент (Main Component)
    • В Figma створити компонент: Button/Primary.
    • Задати: макет, відступи, типографіка, радіус, колір, іконка, вирівнювання.
  2. Створити Варіанти (Variants).
    • Мінімально: Default; Hover; Active/Pressed; Disabled; Focus.
    • Додатково: Loading.
  3. Приклад промпту
  4. Розроби стани взаємодії для основної кнопки з закликом до дії (CTA).
    Стани:
    1. Стандартний (Default)
    2. Наведення курсору (Hover)
    3. Натискання (Pressed)
    4. Фокус (Focus)
    5. Неактивний (Disabled)
    6. Завантаження (Loading)
    Вимоги:
    - зберегти незмінні розміри;
    - дотримуватися візуальної ієрархії;
    - забезпечити чіткий візуальний відгук;
    - забезпечити достатній рівень контрастності для доступності;
    - уникати надмірної анімації;
    - дотримуватися наявного фірмового стилю.
    Опиши візуальні зміни для кожного стану.
    
Етап 11. Створення компонентів карток та навігації
  1. На основі контенту ЛР №2 та графіки ЛР №3 створити компонент картки.
    • Наприклад: Картка/Послуга
    • Містить: Зображення/іконка, заголовок, опис, метадані, заклик до дії.
    • Створити кілька Екземплярів (Instances), а не копії звичайних груп.
  2. Приклад промпту
  3. Розроби багаторазовий компонент картки послуги.
    Картка повинна містити:
    - іконку або зображення;
    - заголовок;
    - короткий опис;
    - додаткові метадані (за потреби);
    - основну дію.
    Вимоги:
    - адаптивна верстка;
    - узгоджені відступи;
    - чітка ієрархія;
    - доступний контраст тексту;
    - структура компонента, придатна для багаторазового використання;
    - підтримка різного обсягу контенту.
    Створи простий сучасний інтерфейс, що підходить для адаптивного вебсайту.
    
Етап 12. Створення Шапки (Header) та Навігації (Navigation)
  1. Створити компонент Шапки (Header)
    • Хедер повинен містити: логотип, навігацію, первинний заклак до дії, трігер мобільного меню.
    • Передбачити: вигляд на десктоп та мобільному екрані.
  2. Приклад промпту
  3. Розроби адаптивний хедер вебсайту.
    Десктопна версія:
    - логотип ліворуч;
    - основна навігація по центру;
    - заклик до дії (CTA) праворуч.
    Мобільна версія:
    - логотип ліворуч;
    - кнопка меню праворуч;
    - навігація відкривається як зручне мобільне меню.
    Вимоги:
    - чітка ієрархія;
    - достатні відступи;
    - доступність для керування з клавіатури;
    - видимий стан фокусу;
    - адаптивність;
    - відповідність наявній дизайн-системі.
    
Етап 13. Створення візуального макету сторінки (Mockup)

Після проходження попередніх етапів студент переходить до створення повноцінного візуального макета.

  1. Створити головну сторінку
  2. В Frame: 03 — Homepage перенести: шапку, головний блок (Hero), переваги, картки, контент, відгуки, заклик до дії (СТА), підвал.
  3. Використовувати Екземпляри (Instances) створених компонентів. Не створювати повторювані елементи по новій вручну.
Етап 14. Адаптивні версії
  1. Створити щонайменше два варіанти макетів: Desktop: 1440 px та Mobile: 390 px. За можливості створити макет для Tablet: 768 px.
  2. Перевірити в кожному макеті: навігацію, розмір шрифту, кнопки, картки, зображення, відступи, порядок блоків.
  3. Приклад промпту
  4. Проаналізуй цей інтерфейс для десктопа та запропонуй адаптивний варіант для мобільних пристроїв.
    Ширина області перегляду (viewport): 390 пікселів.
    Визнач:
    - елементи, що мають розташовуватися один під одним (стеком);
    - елементи, розмір яких має змінюватися;
    - зміни в навігації;
    - зміни в типографіці;
    - зміни у відступах;
    - поведінку зображень;
    - розміщення елементів із закликом до дії (CTA).
    Збережи інформаційну ієрархію та основну мету користувача. Не просто масштабуй десктопний макет, а адаптуй його для взаємодії на мобільному пристрої.
    
Етап 15. Створення інтерактивного прототипу
  1. Додати з’єднання прототипів (Prototype connections)
    • Зв'язати основні екрани: Головна → Послуги → Деталі послуги → Контакти або відповідно до Шляху Користувача власного проєкту.
    • Реалізувати: переходи, кнопки, навігацію, відкривання меню, повернення назад, основний заклик до дії (CTA).
  2. Додати мікровзаємодії. Для ключових елементів передбачити: Hover; Pressed; Focus; Loading; Success/Error.
Етап 16. UX-аудит готового прототипу
  1. Провести контрольну перевірку
    • UX. Чи зрозуміло, що робити? Чи є логічною навігація? Чи видно Основний заклик до дії? Чи немає зайвих кроків?
    • UI. Чи є візуальна ієрархія? Чи узгоджені компоненти? Чи однакові відступи? Чи немає випадкових стилів?
    • Accessibility. Контраст, фокус, розміри тексту та інтерактивних елементів, передача інформації не лише кольором.
    • Mobile UX. Чи зручно натискати кнопки? Чи не перевантажений екран? Чи зрозуміле меню? Чи легко читати текст?
Етап 17. ШІ-аудит прототипу
  1. Для фінальної перевірки можна передати скриншот або експортовані екрани до ШІ-моделі.
  2. Приклад промпту
  3. Дій як старший спеціаліст з UX/UI. Проаналізуй доданий прототип веб-сайту.
    Оціни його за п'ятьма категоріями:
    1. Інформаційна архітектура.
    2. Візуальна ієрархія.
    3. Зручність використання.
    4. Доступність.
    5. Адаптивність/мобільна зручність використання.
    Для кожної виявленої проблеми надай:
    Проблема:
    Чому це важливо:
    Серйозність: Низька / Середня / Висока
    Рекомендоване покращення:
    Не хвали дизайн, якщо немає конкретної причини. Зосередьтеся на проблемах, які можна вирішити. Не переробляйте весь інтерфейс.
    
  4. Після отримання результату студент повинен самостійно вирішити, які рекомендації доцільно прийняти.
Етап 18. Фінальне доопрацювання
  1. На основі UX-аудиту внести зміни в макет:
    • Виправити проблеми навігації.
    • Скоригувати відступи.
    • Змінити проблемні кольори.
    • Покращити типографіку.
    • Виправити компоненти.
    • Додати відсутні стани;
    • Виправити мобільний макет.
  2. Перевірити компонентність та переконатися, що:
    • Повторювані елементи є компонентами (Components).
    • Сторінки використовують екземпляри (Instances).
    • Стани реалізовано через варіанти (Variants).
    • Зміна Головного компонента (Main Component) впливає на його екземпляри (Instances).

Саме компонентність є одним з ключових критеріїв поточної лабораторної.

Етап 19. Організація Figma-файлу

Фінальний Figma-файл рекомендовано структурувати наступним чином:

📁 00_Cover
📁 01_User_Flow
📁 02_Sitemap
📁 03_Wireframes
📁 04_Design_System
   ├── Colors
   ├── Typography
   ├── Spacing
   ├── Buttons
   ├── Inputs
   ├── Cards
   ├── Navigation
   └── Icons
📁 05_Desktop
📁 06_Mobile
📁 07_Prototype
📁 08_UX_Audit

Зміст звіту та технічні фінальні артефакти

В результаті виконання роботи студент формує та завантажує на диск (у власну папку) звіт в форматі PDF.

  1. Титульний лист з зазначенням теми, варіанта (назви бізнес-проєкту).
  2. Пряме посилання на Figma-проєкт (налаштувати доступ "Anyone with the link can view").
  3. Розділ 1. Етап UX-проектування. Скріншот згенерованої ШІ інтерактивної карти сайту (Sitemap) та сірого каркасу сторінки.
  4. Розділ 2. Етап UI-стилізації. Скріншот сторінки в Figma після застосування ШІ-плагінів для колірної гами та шрифтів.
  5. Розділ 3. Дизайн-система та UI-набори. Скріншот окремого фрейму (сторінки) в Figma, де чітко видно створені компоненти кнопок в 3-х станах (Default, Hover, Active) та компоненти карток/навігації.
  6. Промпт-паспорт (Prompt Log). Текстовий опис запитів, які надсилалися плагінам та ШІ-генераторам каркасів.

Критерії оцінювання лабораторної роботи

  • Логіка та повнота каркасу. Чи містить згенерований каркас всі необхідні блоки (особливо секцію під майбутній JS-віджет калькулятора та форму).
  • Робота з ШІ-плагінами та колірна гармонія. Естетичність підібраної колірної схеми та шрифтових пар, відповідність стилю тематиці проєкту.
  • Створення UI-набору та компонентність. Правильність створення Figma-компонентів. Наявність трьох обов'язкових станів для кнопок (Default, Hover, Active). Якщо елементи розмножено звичайним копіюванням без використання інструменту Component — бали суттєво зменшуються.
  • Охайність та структура в Figma. Порядок в шарах (Layers), наявність окремої зони для UI-наборів, правильне іменування елементів.
  • Захист роботи. Усна бліц-відповідь на запитання: Що таке компонент в Figma? Навіщо потрібні стани елементів інтерфейсу? Як ШІ допоміг прискорити рутинні процеси?

ШІ — це реактивний двигун, але розробник є пілотом. ШІ-плагін може розфарбувати макет за секунду, але він не знає контексту користувача. Завжди перевіряти згенерований інтерфейс критично. Чи зручно буде натискати цю кнопку великим пальцем на екрані смартфона? Чи не занадто дрібний шрифт підібрав ШІ для текстових блоків? Обов’язково поєднувати ШІ-генерацію з логікою класичного UI/UX розробника.

Контрольні запитання

  1. Що таке низькодеталізований каркас (Wireframe) і на чому саме він фокусується під час проєктування?
  2. Які три обов'язкові стани (Component States) повинна мати інтерактивна кнопка в UI-наборі згідно з вимогами роботи?
  3. Поясніть головне правило UI-набору — «компонентність». Що відбувається, якщо змінити стиль «батьківського» компонента?
  4. Чому автоматично згенеровану ШІ-інструментами (наприклад, Relume чи Uizard) сітку та структуру сайту не можна вважати фінальним етапом UX-проєктування?
  5. Яку роль в даній лабораторній роботі мають ШІ-інструменти Relume AI або Uizard?
  6. Для чого потрібні плагіни, такі як Musho AI або Wireframer безпосередньо всередині Figma?
  7. На що саме, окрім красивого поєднання кольорів, повинен звернути увагу дизайнер після того, як ШІ-плагін «розфарбував» макет?
  8. Яка комбінація гарячих клавіш в Figma використовується для перетворення звичайного елемента (наприклад, намальованої кнопки) на компонент?
  9. Якщо під час перевірки виявиться, що студент розмножив кнопки на сторінках звичайним копіюванням (Ctrl+C/Ctrl+V), а не через екземпляри компонентів, як це вплине на оцінку і чому?
  10. Що входить до поняття «охайність та структура в Figma»?
  11. Які технічні артефакти та параметри доступу повинен надати студент у фінальному PDF-звіті?
  12. Як ви розумієте вираз: «ШІ — це ваш реактивний двигун, але ви — пілот» в контексті вебдизайну?

Глосарій термінів. UX/UI прототипування та створення дизайн-системи

Рекомендовано для вивчення перед захистом Лабораторної роботи №4

  • Прототипування — процес створення попередніх моделей вебсайту або цифрового продукту для перевірки ідеї, структури, розташування елементів і логіки взаємодії користувача з інтерфейсом до початку повноцінної розробки.
  • Каркас сайту (Wireframe)/Низькодеталізований каркас (Low-fidelity Wireframe) — спрощена, схематична модель сторінки (зазвичай в сірих тонах), яка фокусується виключно на розташуванні елементів, пріоритетності контенту та логіці взаємодії, без врахування фінальних кольорів, шрифтів та графіки.
  • Високодеталізований прототип (High-fidelity Prototype) — інтерактивний макет, який максимально наближений до фінального вигляду продукту і містить реальні кольори, шрифти, зображення, іконки та анімації для тестування UX перед написанням коду.
  • Карта сайту (Sitemap) — візуальна або текстова схема, що відображає повну структуру вебресурсу, ієрархію його сторінок та логіку навігаційних переходів між ними.
  • Шлях користувача (User Journey/Користувацький сценарій) — повний послідовний крок або набір дій, які здійснює користувач для досягнення своєї мети в інтерфейсі (наприклад, процес реєстрації, купівлі товару чи відновлення пароля).

  • Дизайн-система — набір багаторазових компонентів та елементів, об'єднаних єдиними правилами стилістики (колірна палітра, типографіка, відступи), що забезпечує візуальну та функціональну єдність цифрового продукту.
  • UI-набір (UI-kit) — бібліотека готових графічних елементів інтерфейсу (кнопок, полів введення, карток товарів), які використовуються для швидкого збирання макетів.
  • Атомарний дизайн (Atomic Design) — методологія створення інтерфейсів, яка передбачає поділ складного дизайну на менші, незалежні блоки: Атоми (іконки, кнопки), Молекули (поле пошуку), Організми (шапка сайту), Шаблони та Сторінки.
  • Головний компонент (Main Component) в Figma — оригінальний елемент інтерфейсу, що служить центральним шаблоном, в якому задаються всі основні характеристики (форма, колір, стани, відступи).
  • Екземпляр (Instance) в Figma — копія головного компонента, яка використовується на сторінках проєкту. Вона зберігає зв’язок з оригіналом і автоматично оновлюється при зміні "батьківського" компонента (принцип наслідування).
  • Варіанти компонентів (Variants) в Figma — набір різних станів або модифікацій одного компонента (наприклад, Primary та Secondary кнопки), об'єднаних в один набір для зручності керування.

  • Мікровзаємодія (Microinteraction) — миттєва візуальна або анімаційна реакція системи на дії користувача (наприклад, підсвічування поля введення чи плавна зміна кольору кнопки при наведенні), що створює відчуття "живого" інтерфейсу.
  • Стани UI-елементів (Component States) — візуальні зміни інтерфейсного елемента залежно від поточного статусу системи чи дій користувача. Основні стани кнопки:
    • Default — початковий, звичайний стан елемента.
    • Hover — стан елемента при наведенні курсору миші (актуально для десктопів).
    • Active/Pressed — короткочасний вигляд елемента безпосередньо в момент натискання.
    • Focus — виділення елемента, коли він стає активним для введення даних або вибирається за допомогою клавіатури.
    • Disabled — вигляд елемента (найчастіше сірий та напівпрозорий), коли він тимчасово недоступний для взаємодії.
    • Loading — стан, що сигналізує про обробку запиту системою за допомогою анімації завантаження (spinner або skeleton screens).
  • Колірний контраст — ступінь відмінності між кольором елемента (тексту, іконки) та кольором його фону, що напряму впливає на читабельність інформації.
  • Доступність (Accessibility/Web Content Accessibility Guidelines, WCAG) — міжнародні стандарти та практики проектування вебконтенту, які гарантують, що цифровий продукт буде зручним для всіх користувачів, включаючи людей з порушеннями зору, слуху або опорно-рухового апарату.

  • Генеративний ШІ в вебдизайні — технології штучного інтелекту, що здатні автоматично створювати структури, дизайн-системи, палітри кольорів, текстове наповнення та кодові фрагменти на основі аналізу великих масивів даних.
  • Промпт (Prompt) — детальний текстовий опис-інструкція, яка надсилається ШІ-інструменту для генерації необхідного результату (наприклад, структури сайту чи стилістичного оформлення).
  • Промпт-паспорт (Prompt Log) — задокументована історія або журнал всіх текстових запитів, які дизайнер використовував під час роботи з ШІ-генераторами.
  • Інженерна етика при роботі з ШІ — професійний принцип, згідно з яким штучний інтелект розглядається лише як інструмент-помічник, а остаточну відповідальність за якість, логіку, доступність і безпеку продукту завжди покладено на розробника. ШІ може створити макет за секунду, але він не знає контексту живого користувача. Потрібно поєднувати технологічну швидкість з критичним мисленням та логікою.

Застосовані інструменти