Розробка VisualSnag та чому AI-інструментам потрібен чіткий візуальний контекст

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

Вітаю! Довгий час моя професійна кар’єра була пов’язана з UX/UI та продуктовим дизайном, але останній рік я все більше займаюся створенням власних продуктів.

Спочатку це були застосунки для iOS та macOS на Swift, потім я перейшов до JavaScript і зробив кілька застосунків для Jira та Confluence. Після цього логічно було б зупинитися, сфокусуватися на маркетингу вже створених продуктів і не відкривати новий репозиторій хоча б кілька місяців.

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

Так у мене з’явилася ідея VisualSnag.

Ідея

Останнім часом я багато працюю з AI-інструментами для розробки та дизайну: ChatGPT, Claude Code, Codex, Figma Make та іншими подібними сервісами. Вони вже добре допомагають із логікою, структурою сайтів та застосунків, генерацією компонентів, роботою з кодом і швидким прототипуванням.

Але під час роботи з такими інструментами я постійно стикався з однією проблемою: візуальна частина часто виходить занадто узагальненою (особливо з цим проблема у Claude Code).

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

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

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

VisualSnag дозволяє вставити URL сайту або завантажити зображення-референс, а на виході отримати готову візуальну систему для AI-assisted building: кольори, типографіку, правила layout, CSS variables, design tokens, style brief і AI prompts. Ідея не в тому, щоб копіювати чужий сайт, а в тому, щоб зрозуміти його візуальну логіку й перетворити її на практичні матеріали, які можна використати у власному проєкті.

Чому не просто prompt generator?

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

Проблема візуального напряму в AI-розробці ширша. Користувачу потрібен не тільки промпт. Йому потрібні конкретні опори, які можна перенести у процес розробки:

1. Які кольори використовувати.
2. Яка роль у primary, secondary, accent і background colors.
3. Яка типографічна логіка підходить для заголовків, body text, labels і кнопок.
4. Які радіуси, відступи та щільність інтерфейсу характерні для референсу.
5. Який загальний UI mood має бути збережений.
6. Які CSS variables можна одразу використати.
7. Який промпт вставити в ChatGPT, Claude, Codex, Cursor, Lovable або інший AI builder.

Тому VisualSnag я сприймаю не як генератор промптів, а як перекладач між візуальним референсом і практичними правилами для AI-assisted development.

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

Розробка

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

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

Стек обрав такий:

Frontend

Vite, React, TypeScript, Tailwind CSS.

Backend

Node.js, Express.

Database

PostgreSQL.

ORM

Prisma.

Hosting

Railway.

URL analysis

Playwright / Chromium.

Такий стек для мене був оптимальним з кількох причин. По-перше, я вже мав досвід роботи з JavaScript / TypeScript після розробки застосунків для Atlassian Marketplace. По-друге, мені потрібна була швидкість і гнучкість, а не надмірно складна архітектура для першої версії продукту. По-третє, Railway дозволяв швидко розгорнути і сам застосунок, і PostgreSQL в одному середовищі.

Vite і React дали швидкий фронтенд. Tailwind CSS допоміг швидко збирати інтерфейс і при цьому контролювати візуальну систему. Node.js і Express закрили API-частину.

Звичайно, це не означає, що все працювало з першого разу. Особливо коли в проєкті з’явився Playwright і серверний запуск Chromium.

Як працює продукт

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

Користувач може:

1. Вставити URL сайту.
2. Завантажити одне або кілька зображень-референсів.
3. Запустити аналіз.
4. Отримати структурований результат.
5. Скопіювати потрібні блоки.
6. Завантажити файли для подальшої роботи.

На виході ресурс формує кілька типів результатів.

Style Brief

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

Colors

Сервіс визначає основну палітру та намагається розподілити кольори за ролями: background, surface, text, primary, accent, border тощо. Це важливо, бо набір HEX-кодів не дуже допомагає в роботі. Набагато корисніше розуміти, який колір за що відповідає.

Typography

Окремо формується напрям для типографіки: заголовки, основний текст, кнопки, labels, акценти. Не завжди можливо або потрібно точно копіювати конкретний шрифт. Частіше важливіше зрозуміти типографічну логіку: геометрична, editorial, tech, playful, мінімалістична, контрастна або нейтральна.

Layout rules

Цей блок описує принципи побудови інтерфейсу: відступи, сітку, щільність, ширину контейнерів, характер карток, блоків, CTA і візуального ритму.

Component DNA

Це спроба описати, як поводяться UI-елементи в межах стилю: картки, кнопки, badges, inputs, sections, navigation. Мені хотілося, щоб результат був корисним не тільки для простих landing page, а й для складних інтерфейсів.

CSS Variables

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

Design Tokens

tokens.json дає структурований формат, який можна використовувати в AI-інструментах, власних скриптах або дизайн-процесах.

AI Prompts

Окремо генеруються промпти для AI-assisted building. Ідея в тому, щоб користувач міг не вигадувати формулювання з нуля, а одразу вставити готовий опис стилю в ChatGPT, Claude, Codex, Cursor, Lovable, Figma Make або інший AI інструмент.

Downloads

Результат можна не тільки переглянути на сайті, а й завантажити:

STYLE.md
variables.css
tokens.json

Що важливо, оскільки такі робочі файли, корисні і стають частиною реального workflow.

Архітектура

На рівні архітектури я не намагався робити складну систему з першої версії. Основне завдання було побудувати стабільний шлях від input до output.

Сценарій виглядає приблизно так:

1. Користувач надсилає URL або завантажує зображення.
2. Backend приймає запит і створює запис у базі.
3. Для URL запускається процес аналізу сторінки.
4. Для зображень обробляються візуальні дані.
5. Дані приводяться до внутрішнього структурованого формату.
6. Генерується style brief, tokens, CSS variables і prompts.
7. Результат повертається на фронтенд.
8. Користувач копіює блоки або завантажує файли.

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

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

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

Проблеми та рішення, з якими зіткнувся в процесі розробки

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

1. AI-output має бути структурованим, а не просто красивим

Проблема: якщо просто попросити AI описати стиль сайту або зображення, результат часто буде занадто загальним. Він може бути грамотно написаний, але не завжди практичний. Наприклад, формулювання на кшталт «modern and clean interface with strong visual hierarchy» звучить нормально, але саме по собі не дає достатньо матеріалу для розробки.

Мені був потрібен результат, який можна використати одразу. Не просто опис, а конкретні блоки: кольори, типографіка, layout rules, CSS variables, tokens і промпти.

Рішення: я зробив output максимально структурованим. Кожен блок має свою роль і очікуваний формат. Якщо це colors, то мають бути ролі кольорів. Якщо typography, то має бути розподіл за типами тексту. Якщо CSS variables, то вони мають бути готові до використання. Якщо prompt, то він має бути написаний так, щоб його можна було вставити в AI builder без додаткового редагування.

Головний висновок: AI у продукті має не просто генерувати текст, а повертати передбачуваний і корисний артефакт.

2. Важливо правильно пояснити, що продукт не копіює сайти

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

Мета інша: допомогти зрозуміти візуальну логіку референсу й адаптувати її під власний проєкт.

Рішення: я свідомо уникаю формулювань на кшталт «clone any website». Натомість використовую visual system, style brief, design rules, AI-ready prompts. Це точніше описує те, що робить продукт.

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

3. Запуск Chromium у production

Проблема: для аналізу URL потрібно працювати зі сторінкою як із реальною веб-сторінкою, а не просто отримувати HTML. Часто важливі стилі, завантажені шрифти, computed styles, візуальна структура, адаптивність і те, як сторінка виглядає після виконання JavaScript.

Для цього потрібен Playwright / Chromium. Локально такий підхід працює досить просто. Але в production-середовищі з контейнерами з’являються додаткові нюанси: системні залежності, шрифти, права, пам’ять, таймаути, стабільність запуску браузера.

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

4. Сайти мають дуже різну структуру

Проблема: немає єдиного способу дістати візуальний стиль із сайту. Один сайт має добре структуровані CSS variables, інший використовує Tailwind-класи, третій має inline styles, четвертий багато візуальних речей формує через JavaScript або SVG.

Кольори можуть бути в CSS, у background images, у gradients, у SVG або в декоративних елементах. Шрифти можуть завантажуватися з різних джерел. Layout може суттєво змінюватися залежно від viewport, cookies або A/B тестів.

Рішення: я не став будувати систему, яка намагається ідеально розібрати кожну властивість кожного сайту. Замість цього зробив практичний підхід: збирати найбільш корисні сигнали з DOM, computed styles, візуальної структури й скриншоту сторінки, а потім приводити їх до зрозумілого стилістичного формату.

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

5. Інтерфейс має бути зрозумілим і дизайнерам, і розробникам

Проблема: VisualSnag знаходиться на межі дизайну й розробки. Для дизайнерів важливі референси, стиль, кольори, композиція, типографіка. Для розробників важливі CSS, tokens, prompts, exports, структура даних і можливість швидко використати результат у своєму workflow.

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

Рішення: я розділив output на два рівні.

Перший рівень: людський і візуальний.
Style brief, colors, typography, layout rules, component DNA.

Другий рівень: практичний і технічний.
CSS variables, design tokens, AI prompts, downloads.

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

Що я не робив у першій версії і що зрозумів під час розробки

Я свідомо не намагався одразу перетворити VisualSnag на велику платформу.

У першій версії немає:

• командних workspace;
• повноцінної бібліотеки проєктів;
• Figma plugin;
• browser extension;
• marketplace готових style systems;
• складних collaboration-функцій;
• автоматичного створення готового сайту з референсу.

На старті важливо було перевірити головну гіпотезу:

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

Тому перша версія фокусується на базовому сценарії:

1. Дати референс.
2. Отримати структурований style output.
3. Скопіювати промпт або завантажити STYLE.md, variables.css і tokens.json.
4. Використати це у своєму AI-assisted workflow.

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

Референс сам по собі ще не є інструкцією. Його потрібно розкласти на конкретні правила: кольори, типографіку, ритм, layout, компоненти, spacing і акценти.

Саме тому корисний AI-output має бути структурованим, а не просто виглядати як довгий текст без чітких секцій. Якщо результат можна розділити на Style Brief, CSS variables, design tokens і AI prompts, його набагато простіше використати в реальному проєкті.

Що далі

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

Мені важливо зрозуміти:

• наскільки корисний Style Brief;
• чи достатньо точні CSS variables;
• чи зручно використовувати tokens.json;
• яких форматів експорту не вистачає;
• які промпти краще підходять для різних AI builders;
• чи потрібно порівнювати кілька референсів одночасно.

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

• глибший аналіз URL;
• краща робота зі скриншотами;
• порівняння кількох референсів;
• окремі output-формати для Cursor, Claude, Codex, Lovable, Bolt, Framer і Webflow;
• бібліотека збережених visual systems;
• командні workspace;
• Figma plugin;
• browser extension для швидкого аналізу стилю з будь-якої сторінки.

VisualSnag не має на меті копіювати чужі сайти. Це проміжний шар між візуальним референсом і AI-assisted development, який допомагає зробити візуальний напрям зрозумілим, структурованим і придатним для використання в реальному проєкті.

Посилання

Спробувати VisualSnag можна тут:
www.visualsnag.com

Написати особисто:
[email protected]