Автор статті на UX Design пропонує підхід, який він називає In-System Design: прототипування відбувається всередині вже існуючої дизайн-системи, а не поза нею. Ідея проста. Для кожного завдання обирається полотно у Figma або код, але обидва середовища працюють з одними й тими самими компонентами. Мета — щоб прототип був зібраний з того, що команда вже має в продукті, а не з малюнків, які потім доведеться переписувати.
Ключова вимога — збіг назв і властивостей. Імена бібліотеки Figma мають точно відповідати компонентам у коді, а сам код вважається першоджерелом істини. Компоненти у Figma відображають назви та пропси коду. Коли назви різняться, хтось мусить їх інтерпретувати, а ШІ робить це з невиправданою впевненістю і видає правдоподібний, але хибний результат. Пікселі можуть відрізнятися, на це автор закриває очі. Натомість різні кольори чи семантична невідповідність мають фіксуватися перевірками.
Технічно робочий цикл тримається на AI-агенті, який зв'язує код, наприклад Storybook, і Figma через MCP-з'єднання. Автор використовує Figma Console MCP від Southleft і Storybook MCP. Для роботи потрібні опублікована бібліотека, яка відповідає коду, порожній файл прототипу у Figma, Figma MCP, агент і окрема дизайн-гілка.
Автор описує приклад: прототип форми реєстрації на курс перебудували у Figma з 21 компонента бібліотеки без жодних візуальних рішень, прийнятих вручну. Після цього агент залишає нотатку зі списком використаних компонентів, частин, зібраних вручну, прогалин і пропозицій. Щоб відокремити системні елементи від малюнків, у Figma є режим перегляду wireframe (Cmd+Y, а на Windows Ctrl+Y), у якому інстанси бібліотеки позначені фіолетовим.
Зворотний шлях, тобто з Figma назад у код, читає інстанси за компонентом бібліотеки та властивостями, а не за назвами шарів, і позначає все, що не належить до бібліотеки. Саме цей цикл, за словами автора, допоміг знайти реальні помилки. Наприклад, різницю в 21 піксель по висоті спричинили абзацні відступи, які не були скинуті в коді. Окрім того, виявилося, що діалог не підтримує слоти, через що потрібно було переробити весь потік. Також з'ясувалося, що в коді для розміщення елементів використовувалися порожні шари-розпірки.
Важливо, що без інструментів на боці коду команда все одно може прототипувати у Figma, посилаючись на бібліотеку. Файл прототипу ізольований, тому компоненти, вигадані ШІ, не потрапляють у головну бібліотеку. Автор при цьому зазначає, що найбільшим джерелом помилок були людські чинники, а не штучний інтелект. Текст у джерелі обривається, тож детальніше про цей висновок судити складно.
Для української команди цей підхід цікавий насамперед тим, що не вимагає перебудови процесів з нуля. Якщо в продукті вже є бібліотека компонентів, яка збігається з Storybook, варто почати з вузького експерименту: одного екрана, однієї гілки і нотатки агента з переліком прогалин. Тоді буде зрозуміло, чи дизайн-система справді працює як джерело правди, а не лише як папка з файлами.
4
Джерело: In-system design: from code to Figma and back. Prototyping in your real design system
