Як дизайнеру перевірити код від AI: чекліст з 10 пунктів

Коротка відповідь: дизайнеру не обов'язково читати кожен рядок коду, який написав AI. Достатньо перевірити десять речей: що змінено тільки те, що просили, кольори і відступи з токенів, всі стани на місці, адаптив на трьох ширинах, доступність з клавіатури, довгі тексти, немає дублів компонентів, немає зайвого (секретів, бібліотек), проєкт збирається і pull request зрозумілий. Більшість цих перевірок робиться в браузері і через питання до самого Claude.

Я Дмитро Ніколаєнко, дизайнер, який щодня мерджить код від Claude Code у продакшн UX Hero. Цей чекліст - те, що я сам проходжу перед мерджем, і те, що найчастіше ловлю в чужих pull request.

Чому код від AI треба перевіряти, якщо він працює?

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

Добра новина: саме ці проблеми дизайнер помічає краще за розробника, бо вони видимі. Вам не треба розуміти, як працює React, щоб побачити, що focus зник.

Чекліст: 10 пунктів перевірки

1. Змінено тільки те, що просили

Подивіться список змінених файлів. Якщо просили виправити хедер, а змінено п'ять файлів, з'ясуйте, навіщо. У GitHub Desktop чи на сторінці pull request це видно одразу. Питання до Claude: «Перелічи змінені файли і поясни одним реченням, навіщо змінено кожен».

2. Кольори, відступи і радіуси з токенів

Найчастіша проблема. Попросіть: «Знайди у змінах сирі hex, rgb і px-значення, яких немає в tokens.css». Якщо список не порожній, просіть замінити на токени. Чому це важливо, пояснено в матеріалі Design tokens простими словами.

3. Усі стани на місці

Пройдіться мишкою і клавіатурою: hover, focus, active, disabled, loading, error, пустий стан. Агент часто робить default і hover, а решту забуває. Шість станів, які потрібні кожній кнопці, детально розібрані в статті Компонент зі станами.

4. Адаптив на трьох ширинах

Відкрийте сторінку в браузері і перевірте на 360, 768 і 1440 пікселях. У Chrome це DevTools і режим пристрою. Дивіться на переноси тексту, горизонтальний скрол і елементи, що налазять один на одного.

5. Доступність з клавіатури

Натисніть Tab кілька разів. Чи видно, де фокус? Чи в логічному порядку він рухається? Чи можна відкрити меню і закрити модалку з клавіатури? Додатково попросіть Claude: «Перевір контраст тексту на фоні за WCAG AA і alt у зображень».

6. Довгі тексти і реальні дані

Українські слова довші за англійські, а реальні дані довші за «Lorem ipsum». Підставте найдовшу назву, велике число, ім'я на два рядки. Агент майже завжди тестує на коротких прикладах.

7. Немає дублікатів компонентів

Питання: «Чи створено в цій гілці нові компоненти? Чи є в проєкті схожі існуючі?» Дві кнопки з різною логікою - початок розвалу системи. Краще розширити існуючий компонент варіантом.

8. Нічого зайвого: секрети, бібліотеки, файли

Перевірте, що в змінах немає ключів API, паролів, токенів доступу і файлів на кшталт .env. Попросіть: «Чи додано нові залежності в package.json? Навіщо кожна?» Нова бібліотека заради одного ефекту - зазвичай погана угода.

9. Проєкт збирається, Storybook і тести проходять

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

10. Pull request зрозумілий людині

Опис PR має відповідати на три питання: що змінено, навіщо, як перевірити. Якщо ви самі не можете пояснити зміну колезі, ви її не перевірили. Попросіть Claude написати опис, а потім відредагуйте його своїми словами.

Як зробити перевірку звичкою, а не подвигом

Перевіряти все руками щоразу втомлює, тому чекліст варто автоматизувати поступово:

• Пункти 2, 7 і 8 добре перевіряє окремий агент-рев'юер у Claude Code, який тільки читає код і звітує. Як його зібрати, є в статті AI-агенти для дизайнера.
• Пункти 2 і 3 можна закріпити в CLAUDE.md як правила, тоді агент частіше робить правильно з першого разу.
• Пункти 4, 5 і 6 лишаються за вами. Це дизайнерське око, і саме за нього вас цінують.
• Пункт 9 закриває автоматична збірка: Cloudflare Pages чи Vercel збирають preview на кожну гілку, і ви бачите результат за посиланням до мерджу.

Коли кликати розробника

Є зони, де дизайнеру варто зупинитись і попросити рев'ю в розробника, навіть якщо все виглядає добре:

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

Це не про недовіру до себе. Це нормальний розподіл відповідальності в команді. Як домовитись з розробниками, щоб вони були за ваші правки в коді, я писав у статті Дизайнер, що кодить.

Шаблон короткої перевірки на 10 хвилин

1. Список змінених файлів: все за задачею?
2. Claude: сирі hex/px у змінах?
3. Tab по сторінці: фокус видно?
4. 360 / 768 / 1440: нічого не налазить?
5. Найдовший текст і велике число: тримає?
6. Claude: нові компоненти і залежності?
7. Збірка і preview: відкривається?
8. Опис PR: що, навіщо, як перевірити.

Цей шаблон можна покласти в опис кожного pull request як чекліст з галочками. Через тиждень ви проходите його автоматично.

Три питання до Claude після кожної задачі

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

1. «Що ти змінив і навіщо, коротко по кожному файлу?» Якщо пояснення не збігається з задачею, ви одразу це побачите.
2. «Що в цій зміні може зламатись і де?» Агент чесно назве слабкі місця: довгі тексти, старі браузери, сторінки, які використовують той самий компонент.
3. «Що ти не перевірив?» Найкорисніше питання. Відповідь показує, де ваше око потрібне найбільше.

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

Три питання до Claude після кожної задачі

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

1. «Що ти змінив і навіщо, коротко по кожному файлу?» Якщо пояснення не збігається з задачею, ви одразу це побачите.
2. «Що в цій зміні може зламатись і де?» Агент чесно назве слабкі місця: довгі тексти, старі браузери, сторінки, які використовують той самий компонент.
3. «Що ти не перевірив?» Найкорисніше питання. Відповідь показує, де ваше око потрібне найбільше.

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

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

Часті питання

Чи може дизайнер перевіряти код без знання програмування?

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

Які помилки найчастіше робить AI в UI-коді?

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

Як автоматизувати перевірку коду від AI?

Закріпіть правила в CLAUDE.md, зробіть агента-рев'юера в Claude Code, який тільки читає код і звітує про проблеми, налаштуйте preview-деплой на кожну гілку і, за можливості, візуальні регресійні тести для компонентів.

Скільки часу займає перевірка однієї зміни?

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

---

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