Vibe-дизайн vs Дизайн-мислення: чи зможе АІ замінити дизайнера і як я побудувала повноцінний продукт з Claude Code

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

Привіт, мене звати Яна, я Product / UX/UI Designer. Пишу цю статтю для інших дизайнерів, яким цікаво розбиратися в нових AI, та не AI інструментах (такі зараз є?). Котрі не панікують від того, що AI їх замінить — або ця стаття допоможе цього не робити.

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

Я опишу свій власний експеримент з АІ. В процесі зʼясую, де закінчується дизайн, Figma, мокапи і що починається після. Опишу процес, який мені вдалося побудувати в рамках цього експерименту. Поділюся своїм досвідом зміни процесів дизайну. Маю надію, що знання про мої кроки допоможуть комусь створити своє, дізнатися більше, або просто почати в усьому цьому розбиратися.

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

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

Отож. Як все почалось

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

Так і вийшло.

На той момент я ще абсолютно нічого не розуміла про Claude Code, тільки читала щось у LinkedIn, бачила якісь каруселі, але й того було не так багато, як зараз.

І незважаючи на це, я дуже хотіла спробувати оволодіти наявними інструментами, протестувати їх на всю, подивитись, чи під силу це мені взагалі. І з’ясувати: де сучасний світ зараз знаходиться? Чи в ногу з ним я рухаюсь?

Одним із викликів було те, що я вирішила рухатися зовсім без Figma. Робити дизайн прямо в коді. І перед цією роботою мені потрібно було дуже добре розібратися із тим, як це працює, що за проект я буду створювати, поресьорчити, побудувати план роботи, документацію — і сам Claude Code мені в цьому дуже допоміг.

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

Що ж за проєкт

Концептуальний e-commerce магазин нішових китайських чаїв. Дала йому назву Söl Tea.

Це дослідницький проект про те, що відбувається, коли дизайнер з нульовим бекграундом в кодингу береться за повноцінний e-commerce разом з AI.

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

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

Все задокументовано, всі версії зберігаються, що можна відкотитися до попередньої, коли це стає потрібно. А повірте, таке неодмінно станеться. Особливо коли працюєш з Claude Code — зміни відбуваються швидко, тому історія в цей момент прям рятує.

Етап 0. Бренд і продукт

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

Söl Tea — нішові китайські чаї.

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

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

Етап 1. Дизайн-система

Перший (майже) і найдовший етап — побудова всіх сторінок і компонентів. Але ще до першої сторінки я мучила себе питаннями: як зробити, щоб продукт був цілісним?

У Figma для цього є стилі і токени. В коді, як виявилось, — те саме, тільки назви інші. Це стало першим і, мабуть, найважливішим відкриттям цього проекту. Всі кольори, розміри тексту, відступи записані як змінні: —cream, —green-800, —text-h1. Жодне значення не хардкодиться. Зміна в одному місці — оновлення скрізь. Це той самий принцип, що й у Figma, тільки живе у файлі tokens.css.

Важливо! Перевіряйте Claude Code в цих питаннях по кілька разів — бо з точки зору коду та розробки це критично важливо.

Web Components у коді має ту ж саму логіку, що й компоненти у Figma. Один раз будуєш nav, footer, product-card — і вони однакові на всіх сторінках. Зміна компонента в одному файлі оновлює його скрізь, де він використовується. Саме тому, якщо вирішено змінити вигляд картки товару — міняється один файл, а не кожна сторінка окремо. І це теж треба по кілька разів перевіряти.

Дизайн-система — sol-design-system.html.

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

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

Що потрібно пам’ятати в роботі з AI-інструментами? — потрібно постійно тримати їх в контексті. Claude Code може сам генерувати документацію, сам її оновлювати. Так, це пришвидшує роботу. Але, що саме в цій документації буде написано і для чого вона написана — вирішуєте тільки ви.

Робота з AI зараз схожа на диригентство. Багато різних інструментів, в кожного своє місце, але без управління цим всім — не вийде мелодії.

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

Я вирішила, що зроблю цей проект абсолютно по-іншому і з новим інструментом, але, як виявилось, що вміння, які були в іншому інструменті і поза ним так само можна застосувати і з АІ. Бо системність та креатив не можна набути штучно, а прискорити себе — цілком.

Сторінки

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

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

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

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

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

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

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

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

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

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

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

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

Всі сторінки, від каталогу до чекауту — це верстка під мобільний екран: картки товарів, модалки, навігація, форми. І насправді це теж потрібно робити окремо та поправляти, бо AI не зробить все ідеально.

Медіа: 110+ зображень і системний підхід до генерації

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

Вся генерація відбувалася в Krea AI. Системний підхід та цікавість — це те, що врятувало мою роботу в цьому процесі. Окреме слово для нодів у Krea, які допомагали мені тримати все цілісним. Я доволі багато писала про це у своїх сторітелінг-постах у LinkedIn, коли працювала над цим проектом. Там ціла ода для нодів.

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

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

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

Етап 2–3. База даних

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

Перехід до Supabase став переходом від «макету з даними» до «системи з даними». Різниця одразу стала відчутна. Тепер є місце, де все зберігається, редагується і де видно, що відбувається.

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

У мене вийшло 10 таблиць загалом: товари, варіанти, замовлення, позиції, відгуки, підписки, кошики, вішлісти, населені пункти і відділення Укрпошти.

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

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

Етап 4. Авторизація і профіль

Один модальний компонент, але п’ять режимів: вхід в акаунт, реєстрація, відновлення пароля, Magic link — лист, що одразу логінить без пароля, і auth-gate — коли хтось хоче залишити відгук, не будучи авторизованим.

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

Окремо виділю можливість авторизуватися через Google. Для мене це здавалося чимось надзвичайним, а виявилось доволі простим — якщо, звичайно, робити це з Claude Code.

Захист від ботів через Cloudflare Turnstile активується тільки тоді, коли користувач починає взаємодіяти з формою, а не одразу при відкритті сторінки.

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

У віджеті профілю є три вкладки: Замовлення, Відгуки, Налаштування.

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

Етап 5. Адмін-панель: другий продукт всередині першого

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

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

Дашборд — це bento-сітка. Виручка, кількість замовлень, нові відгуки, топ-5 товарів, міні-графік за останній місяць.

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

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

Етап 6. Кошик і вішліст: два стани одного користувача

Кошик — один з найважливіших елементів e-commerce. Що відбувається з ним, коли користувач закриває сторінку? Або коли він логіниться? Зараз ще одна невеличка відступка саме від інтерфейсів і того, як це виглядає на сторінках.

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

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

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

Етап 7. Доставка

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

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

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

База Укрпошти (~23 000 населених пунктів, ~28 000 відділень) зібрана з відкритого датасету data.gov.ua і зберігається у Supabase — тому пошук швидкий, без залежності від зовнішніх API.

Етап 8. Оплата: redirect і три можливих стани після повернення

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

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

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

Сам чекаут: дані отримувача, вибір перевізника і відділення, спосіб оплати (готівка або картка). Для залогіненого — частина полів заповнена автоматично. Для гостя — простий flow без примусової реєстрації.

Етап 9. Email і аналітика

Домен sol-tea.store коштував 50 гривень на рік. І завдяки цьому, всі листи приходять від [email protected]. Маленька деталь — але вона тримає бренд цілісним навіть у транзакційних листах.

Налаштування email відбувається за допомогою сервісу Resend.

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

Деплой — через Vercel. Спочатку я використовувала GitHub Pages — вбудований хостинг від GitHub. Але у безкоштовній версії Pages доступні тільки для публічних репозиторіїв. Коли проект розростався і даних ставало все більше, виникла потреба зробити репозиторій приватним. Тому перейшла на Vercel: push у main — і сайт оновлюється за хвилину автоматично. Так само, пізніше підключила і власний домен.

Три рівні аналітики. Vercel Analytics — трафік і швидкість завантаження. Microsoft Clarity — теплові карти і записи сесій. Видно, де люди клікають і де зупиняються. Google Analytics 4 — події і конверсії за кожним кроком воронки.

Окремо варто згадати Google PageSpeed Insights — інструмент, який тестує сайт за чотирма показниками: Performance, Accessibility, Best Practices і SEO.

У мене стабільно тримаються оцінки 95–100 по Accessibility, Best Practices і SEO. Performance — гнучкіший показник: залежить від поточного навантаження сервера і того, звідки запускаєш тест. Може трохи просідати, але загальна картина — хороша.

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

Komora DS

В процесі роботи над дизайн-системою Söl Tea та самим проектом виникла ідея: що якби цей процес можна було відтворити швидко в будь-якому проекті? Мені допомогли в цьому люди та українське комʼюніті дизайнерів, чому дуже завдячую. Komora DS — публічний Claude Code skill, який генерує живу Design System сторінку на основі вже існуючого проекту. Не просто документ — а інтерактивна сторінка з усіма компонентами, токенами і правилами. Прям, як вийшло у мене, тільки це буде під кожен окремий проект.

Після цього проекту стало зрозуміло кілька речей.

Принципи не залежать від інструменту. Компоненти, токени, ієрархія, інформаційна архітектура — це спосіб мислення, а не Figma-інструментарій. Ті самі підходи живуть в іншому середовищі і вирішують ті самі завдання. Масштаб вимагає системності — 10 сторінок, 19 компонентів, 7 функцій на сервері, 37 товарів, 110+ зображень і 47 виправлених проблем. Так, можна проводити тестування прямо з Claude Code. І це неможливо зробити за один вечір. Без документації і чіткої структури проект розсипається. Це не буде працюючим рішенням без глибинного розуміння, як це працює для людей та що ми отримуємо від цього. Можливо, не все можна пояснити словами.

Наостанок

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

Ось що, на мою думку, сталося.

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

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

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

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

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

Дякую, що прочитали цю статтю!)

Посилання

• Живий магазин: sol-tea.store
• LinkedIn: linkedin.com/in/yananaaas
• GitHub: github.com/yananaaas
• Komora DS — Claude Code skill для генерації живої Design System сторінки
• Claude Code — AI-асистент, основний інструмент розробки
• Krea AI — генерація зображень товарів
• Vercel — хостинг
• Supabase — база даних, авторизація, Edge Functions
• LiqPay — оплата карткою
• Resend — email-нотифікації
• Cloudflare Turnstile — captcha
• Microsoft Clarity — поведінкова аналітика
• Google Analytics 4 — аналітика подій і конверсій
• Нова Пошта — служба доставки, API можна взяти там
• Укрпошта — служба доставки і відкритий датасет відділень