Технічна база для дизайну – те, про що соромно запитати у розробників

HTML

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

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

Ось простий приклад HTML, що показує, як зробити звичайну картку із заголовком та кнопкою – для цього створюємо контейнер (div), додаємо туди текст зі словом "Привіт" і , власне, кнопку "Натисни мене".

CSS

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

За допомогою CSS ми можемо зробити так, щоб фон нашої картки був білим, мав падінги та заокруглення. Також можемо змінити колір і розмір заголовку, який у нашій структурі відповідав за слово "Привіт". Ну і чому б не змінити кнопку всередині, наприклад, на зелену.

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

JavaScript

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

Тоді як в розробці все виглядає, я б сказав, простіше. Наступні кілька рядків JavaScript коду відповідають за те, щоб після натиску на нашу кнопку відкривалося діалогове вікно зі словом "Привіт".

Ідея всюди більш-менш схожа

На цьому моменті у вас може з'явитися логічне запитання: "Чи завжди фронтенд працює однаково, чи всюди він використовує саме HTML, CSS та JavaScript...?"

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

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

Таблиці

Таблиці – це, по суті, буквально таблиці, як, наприклад, Google Sheets. Саме в них зберігаються дані вашого додатку. І таких таблиць може бути багато, адже кожна з них відповідатиме за один тип інформації.

Формат коду відрізняється в залежності від технології чи платформи, яку ви будете використовувати для бекенду. Нижче наводжу приклад з Convex – інструменту, яким я сам користуюся, тому що він просто-напросто гарно працює з ШІ.

Схеми

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

Функції, API, автентифікація

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

• Queries – вони лише читають дані
• Mutations – вони редагують або видаляють їх
• Actions – це функції, які вміють виконувати складніші дії, наприклад, викликати API або одночасно робити і мутації, і кворі

Далі, власне, API. Це такий собі "міст", що дозволяє брати дані з однієї програми та відправляти її в іншу. За допомогою нього ми створюємо зв'язок між нашом фронтендом і бекендом (це зветься внутрішній API) або ж зʼєднуємо наш додаток з чужими програмами (зовнішній API). Популярним прикладом такого може бути Stripe, тобто інтеграція платіжної системи у ваш застосунок.

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

Env Keys

Останнім важливим поняттям є Environment keys або ж ключі середовища.

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

Важливо також звернути увагу, що під час роботи у проекті цей файл потрібно обов'язково вказати в gitignore. Таким чином він не потрапить до репозиторію в GitHub, коли ви виставлятимете свій проект в інтернет. До речі, GitHub – це цікава й доволі велика тема, яка заслуговує на окрему статтю.

Як усе це поєднується

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

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

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

Усі ж найголовніші секрети зберігаються у вигляді ключів.

UI Бібліотеки

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

Бібліотеки в коді – це майже те ж саме, що й дизайн система у Figma Community. Головна відмінність у тому, що якісні UI бібліотеки пояснюють не лише компоненти та стилі, а й логіку та їхню інтерактивність. Також вони часто заздалегідь налаштовані для accessibility, ну і найголовніше, що там відразу є код, який можна легко завантажити у ваш проект. Це просто-напросто пришвидшує розробку. До того ж більшість таких бібліотек дозволяють кастомізувати свій вигляд, щоб зрештою вдалося зробити персоналізований дизайн.

Загалом їх існує дуже багато, ви можете шукати UI бібліотеки просто в гуглі, на редіті або ж питати ChatGPT. Наприклад, я думаю, багато хто вже чув про shadcn/ui – це наразі одна з найпопулярніших UI бібліотек для створення веб додатків.

Якщо у вас дуже кастомізований дизайн, звісно, можете генерувати код з нуля, але в ідеалі варто користуватися вже готовими компонентами. Загальноприйняте правило – використовувати приблизно 80% того, що вже існує у бібліотеці, тоді як інші 20% можуть бути вашими власними нестандартними елементами дизайну. Також бажано користуватися не більше як однією бібліотекою у проекті, адже в іншому випадку це було б те ж саме, що дизайнити кількома дизайн системами в одному фігма файлі.

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

Фреймворки

Тепер поговоримо про фреймворки – адже це також важлива частина всього того, що ми вже вивчили.

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

Їх існує багато. Популярні постійно підтримуються авторами та розвиваються. Наприклад, для веб додатків та веб сайтів, одним з таких є Next.js. Це, до речі, фреймворк від творців інструменту протипування v0, яким більшість з вас точно користувалася.

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

Його особливість у тому, що він дозволяє створити один проект, який одночасно працюватиме для мобільних додатків як на iOS, так і на Android. Тобто найбільший плюс – це наявність лише однієї бази коду замість двох окремих. Також його творці мають дуже зручну програму на телефон (Expo Go), яка дозволяє з легкістю переглядати написаний чи згенерований вами код, поки ви не запаблішили його в App Store або ж Play Market.

Проте в деяких ситуаціях все ж краще використовувати спеціальні варіанти, зроблені суто під iOS та Android. Наприклад, для іOS найпопулярнішим фреймворком є SwiftUI, який надасть вам максимум кастомізації і гнучкості в плані функціоналу. Скажімо, якщо ви працюєте над healthcare апкою, SwiftUI дозволить підключити дані Apple Health до вашого застосунку, тоді як Expo може не мати такого доступу.

З мінусів те, що його не вийде переглядати настільки ж легко як Expo. Для SwiftUI треба буде виконати трішки більше дій, ніж зазвичай, аби побачити, як саме ваш код виглядає протягом створення додатку.

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

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

Термінал та DevTools

Якщо ви вже перебороли страх код едіторів, таких як, наприклад, Cursor та пробували щось у ньому генерувати, ви все одно швидше за все досі не розумієте, що ж таке термінал і DevTools. Навіщо ними користуватися, коли код едітори самі по собі складні, а тут ще два якихось нових інструменти…?

Насправді все просто.

Термінал – це стандартна програма на вашому компʼютері, яка дозволяє спілкуватися з ним за допомогою команд. Тобто замість кліків мишкою ви пишете текстові запити.

Уявіть, що вам треба створити структуру проекту з 10 папками та 20 файлами. Вручну таке займе надто багато часу, але з терміналом цю дію можна буде зробити, написавши всього кілька команд. Тим більше, якщо виконувати це з АІ, який вміє користуватися вашим терміналом, тоді такі дії взагалі займуть лічені секунди. Також за допомогою нього можна навіть запускати популярні ШІ інструменти – наприклад, Claude Code.

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

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

Зазвичай найкориснішою частиною DevTools є вкладка Console, адже у ній відображаються логи – короткі повідомлення про те, що саме відбувається під час запуску вашого коду. Вони допомагають зрозуміти, де і чому сталася проблема. Наприклад, часто буває, що ШІ довго не може виправити складну помилку. У таких випадках ви можете попросити його додати логи до вашого коду у проекті, далі скопіювати результат з консолі та відправити його назад у АІ чат – він проаналізує проблему й запропонує краще рішення.

Топ помилок при генеруванні коду з AI

З базою закінчили. Тепер кілька слів про найтиповіші помилки під час генерації коду за допомогою штучного інтелекту.

Чому АІ взагалі робить вразливий код? Тому що він міг банально навчатися на поганих прикладах. Але насправді з вашими згенерованими продуктами зазвичай усе буде окей, адже штучний інтелект постійно покращують, тим більше, якщо ви користуєтесь найновішими моделями, як от Claude Sonnet 4.5 чи Gemini 3.0.

Проте загальноприйняті правила безпеки це:

• Не писати в АІ чат ту інформацію, якою б ви не поділилися, наприклад, з незнайомцем.
• Старатися надавати ШІ доступ до найновіших версій документації інструментів чи технологій, з якими ви працюєте. Зробити це можна досить легко за допомогою спеціального безкоштовного MCP під назвою Context7.
• Не вставляти ключі середовища прямо у файли з кодом сторінок чи компонентів, адже тоді до них ймовірно отримають доступ інші люди. Такі паролі мають зберігатися лише в одному файлику під назвою ".env" – скорочення від environment.

Документація

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

Це звісно ж не означає, що вам потрібно вчитуватися в кожне слово, проте базово прочитати зайвим не буде. Також дуже раджу паралельно ставити запитання ChatGPT або Perplexity. Коли ви щось не розумієте, просіть АІ чат пояснювати вам складні речення простими словами (метод ELI5).

YouTube канал "Попелюха - Тестування ПЗ"

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

NotebookLM

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

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

Google AI Studio, Bolt

Одна з найкорисніших порад для початківців: спробуйте створити першу версію вашого продукту за допомогою Google AI Studio (безкоштовна альтернатива популярним v0 та Lovable). Адже він налаштований спеціально для того, щоб швидко генерувати MVP, який ви вже далі зможете перенести собі в курсор і допрацювати. Або, що ще краще, зможете розібрати структуру проекту, яку AI Studio вам створив і поставити уточнювальні запитання штучному інтелекту вже всередині курсору. Наприклад, чому там існує певна папка чи чому в ній знаходяться саме такі файли тощо.

Це корисно, адже якщо починати з нуля відразу в Курсорі, ви швидше за все зіткнетеся з купою помилок. Хоч це й також класний варіант для навчання, просто довший та важчий.

Ще додам, що Google AI Studio, v0 та Lovable підходять для веб продуктів, та інсують альтернативи й для мобільних застосунків. Наприклад, інструмент під назвою Bolt. Він, до речі, якраз таки використовує фреймворк Expo, про який вже раніше згадували.