Figma → WordPress: де ламається впровадження і що я повертаю PM

П’ятниця, вечір. Project Manager радісно пише: «Клієнт затвердив дизайн! Макет у Figma ідеальний, можеш починати верстати. Там усе просто».

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

Як WordPress-розробник, я міг би просто придумати відсутні елементи на ходу або зробити «як вийшло». Але такий підхід завжди призводить до нескінченних правок і виходу за рамки бюджету. Замість цього я зупиняю процес і повертаю макет PM-у з детальним фідбеком.

Ось 4 найчастіші місця, де ламається перенесення з Figma у WordPress, і які питання я задаю перед стартом.

1. Відсутність станів (States)

Дизайнери люблять малювати «щасливий шлях» (happy path), де все виглядає статично та ідеально. Але вебсайт — це живий організм.

Що зазвичай забувають:

• Як виглядає кнопка при наведенні (Hover), натисканні (Active) чи якщо вона неактивна (Disabled)?

• Як виглядає поле вводу, якщо користувач ввів дані неправильно (Error state)?

• Що відбувається з випадаючим меню (Dropdown), коли воно відкрите?

• Як виглядає форма, коли вона відправлена, але прийшла помилка валідації?

Що я пишу PM-у:

«Будь ласка, попроси дизайнера додати UI-kit зі станами кнопок та форм, щоб я не вигадував їхні кольори під час верстки. Інакше на тестуванні будуть несподіванки, які доведеться терміново правити».

2. Мобільна версія: «Ну, там просто блоки один під одним»

Адаптивність — це не просто звуження екрана. Найчастіше проблеми виникають між десктопом (1440px) та мобільним (375px), тобто на планшетах (768px–1024px).

Але навіть у мобільній версії часто ховаються сюрпризи:

• Мобільне меню (бургер). Намальована іконка бургера, але немає макета того, як виглядає відкрите меню. Чи займає воно весь екран? Де знаходяться контакти? Яка анімація відкриття?

• Таблиці. Величезна таблиця з прайсом на десктопі. Як вона має скролитися чи трансформуватися на екрані смартфона? Чи є альтернативний вигляд (картки замість рядків)?

• Липкий хедер (Sticky header). Чи залишається шапка при скролі на мобільному? Якщо так, чи не перекриває вона половину екрана?

Що я пишу PM-у:

«У макеті немає повної мобільної версії для ключових блоків. Мені потрібно бачити хоча б основні стани на 768px і 375px, інакше я буду вигадувати поведінку сам, а потім ми разом виправлятимемо це на тестуванні».

3. Хаос у відступах та типографіці (відсутність системи)

Якість дизайну легко перевірити за тим, як використовуються стилі. Якщо в макеті 15 різних розмірів шрифту для звичайного тексту (14px, 15px, 16px, 17px…) — це не дизайн-система, це хаос.

Те саме стосується відступів. Якщо між однаковими блоками відступи скачуть від 23px до 27px, розробник має два варіанти:

• Писати унікальний CSS-код для кожного блоку (що роздуває код і уповільнює сайт).

• Привести все до єдиної системи (стандартизувати до 24px), але тоді макет не буде «pixel-perfect».

Що я пишу PM-у:

«У макеті немає єдиної сітки та стилів тексту. Я буду стандартизувати відступи та шрифти кратно 4/8px для оптимізації швидкості роботи сайту. Попередьте про це клієнта: візуально різниця буде непомітна, а сайт працюватиме швидше і стабільніше».

4. Приховані сторінки та логіка, про яку забули

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

Що я шукаю і часто не знаходжу в макеті:

• Сторінка 404. Куди потрапляє користувач, якщо перейшов за битим посиланням?

• Thank You Page / поп-апи. Що бачить людина після успішної відправки форми?

• Empty States (порожні стани). Як виглядає сторінка блогу, якщо там ще немає жодної статті? Або результати пошуку, якщо нічого не знайдено?

• Сторінки системних помилок. Що показуємо, якщо сервер не відповів, або якщо щось пішло не так при завантаженні?

Що я пишу PM-у:

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

Що я повертаю PM після аудиту макету

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

1. Список ризиків і «вузьких місць»

Я виписую конкретні місця, де впровадження може піти не за планом:

• Блоки, які важко редагувати в WordPress без додаткових інструментів.

• Сценарії, де не прописані адаптивні стани або стани помилок.

• Елементи, які вимагають кастомної логіки (наприклад, нестандартні фільтри, складні калькулятори).

Це не «критика дизайну», а карта ризиків, щоб PM міг обговорити з клієнтом пріоритети: де готові платити за складність, а де краще спростити.

2. Пропозиції спрощення без втрати суті

Часто можна зберегти візуальну ідею, але зробити реалізацію простішою:

• Замість 10 унікальних секцій — 3–4 шаблонні блоки з різними налаштуваннями.

• Замість складної анімації — проста мікро‑взаємодія, яка не ламається при зміні контенту.

• Замість унікальної сітки для кожної сторінки — єдина система відступів і колонок.

Я показую, як це вплине на:

• Бюджет — менше годин на верстку і інтеграцію.

• Підтримку — простіше додавати новий контент без розробника.

• Стабільність — менше кастомного коду, який треба тестувати при оновленнях.

3. Чітке «що можна легко редагувати в WP», а що краще залишити фіксованим

Одна з найважливіших частин звороту — розмежування:

• Легко редагувати: тексти, зображення, прості блоки (переваги, відгуки, кейси, базові секції послуг).

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

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

Приклад з реального проекту

Як ілюстрацію — типовий сценарій: інтернет‑магазин/каталог (схожий на проекти, з якими я працюю).

Що було в макеті:

• Картки товарів з ідеально однаковими назвами і описами.

• Фільтри, показані лише в «заповненому» стані.

• Сітка товарів, намальована для 8–12 карток, без сценаріїв «товарів багато/мало».

Що виявилося при впровадженні:

• Реальні назви товарів значно довші, через що ламається сітка.

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

• Деякі блоки каталогу були намальовані унікально для кожної категорії, хоча логічніше було б зробити 1–2 шаблонні варіанти.

Що я запропонував:

• Уніфікувати картку товару: одна структура, різний контент, чіткі обмеження по довжині заголовка і опису.

• Прописати стани фільтрів: порожній стан, стан «нічого не знайдено», стан з 1–2 обраними параметрами.

• Замість 5 унікальних шаблонів категорій — 2 основні варіанти (з бічною колонкою фільтрів і без), які покривають 90% сценаріїв.

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

Чек‑лист «Figma before handoff»

Після аудиту я формую короткий чек‑лист для дизайнера/PM, щоб наступні макети було простіше впроваджувати.

Компоненти:

• Усі повторювані блоки оформлені як компоненти/варіанти.

• Назви компонентів зрозумілі («Product Card», «Service Block», «FAQ Item»).

Адаптив:

• Є варіанти для десктопу, планшета, мобільного.

• Показані ключові точки зламу (меню, сітки карток, форми).

Стани контенту:

• Довгі/короткі заголовки, різна кількість карток.

• Порожні стани (немає товарів/послуг), стани помилок, завантаження.

Логіка блоків:

• Зрозуміло, які блоки мають бути шаблонними, які — унікальними.

• Вказані обмеження: максимальна довжина тексту, кількість елементів, розміри зображень.

Такий чек‑лист економить час і на моїй стороні, і на стороні клієнта, бо зменшує кількість ітерацій «а давайте перемалюємо».

Чому моє «ні» — це турбота про проект (і бюджет)

Коли я повертаю PM-у макет із запитаннями, це може здатися затримкою процесу. Насправді це економія десятків годин на етапі тестування.

Коли впровадження ламається через непродумані макети, це завжди:

• Додаткові години на узгодження «як це має працювати».

• Додаткові ітерації верстки, бо доводиться «на ходу» придумувати стани.

• Ризик, що частина роботи піде в кошик, коли клієнт побачить реальний контент і попросить переробити.

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

Готові перетворити свій дизайн на швидкий та надійний сайт?

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

Це не зобов’язує вас до співпраці — але допоможе уникнути несподіваних витрат і неочікуваних правок уже в процесі розробки.