Коротка відповідь: між порожнім фреймом і передаванням макета розробникам дизайнер створює не картинку, а модель майбутнього інтерфейсу. Він задає ієрархію об’єктів, правила зміни розмірів, повторно використовувані компоненти, візуальні змінні, стани, переходи й технічний контекст. Якщо цю систему зібрано правильно, Figma пояснює розробнику не лише те, який вигляд має екран, а й чому він повинен поводитися саме так.
Порожній фрейм у Figma має цілком невинний вигляд. Білий прямокутник, праворуч розміри, ліворуч майже нічого, попереду — обіцянка прекрасного. Новачок бачить свободу. Досвідчений дизайнер бачить майбутню суперечку про те, чи повинен заголовок переноситися на два рядки, куди зникає кнопка за ширини 320 пікселів і хто вирішив показувати помилку оплати зеленим кольором. Тобто бачить звичайний робочий вівторок.
Саме тому хороший макет починається задовго до вибору кольору кнопки й закінчується набагато пізніше за останнє вирівнювання. Між цими точками Figma поступово перетворюється з редактора прямокутників на систему домовленостей. Розкриймо її обережно, шар за шаром, і подивімося, що там ворушиться.
Figma — це не полотно, а дерево рішень
На поверхні Figma схожа на нескінченне полотно. У центрі лежать екрани, ліворуч перелічені шари, праворуч змінюються властивості. Така будова провокує ставитися до файлу як до кімнати, куди можна складати все підряд: кілька варіантів головної сторінки, старий логотип, випадковий скриншот, коментар «вирішити пізніше» та кнопку, яку ніхто не наважується видалити ще з лютого.
Однак із технічного погляду важливіше дивитися на Figma як на ієрархію об’єктів. Кожен елемент має тип, властивості, батьківський і, можливо, дочірні елементи. Фрейм може керувати тим, що міститься всередині нього; компонент визначає будову своїх екземплярів; змінна підставляє значення; прототипний зв’язок описує реакцію на дію. Тому список шарів ліворуч — не бухгалтерія і не покарання за дизайнерські гріхи. Це карта структури майбутнього інтерфейсу.
Звідси виникає перший професійний зсув. Дизайнер припиняє запитувати: «Як поставити цей блок сюди?» — і починає запитувати: «За яким правилом цей блок повинен опинитися тут із будь-яким допустимим вмістом?» У першому запитанні живе координата. У другому — система. Координата переживає один скриншот; система переживає новий текст, іншу мову, вузький екран і колегу, який раптом додав іконку, бо йому наснилося дослідження користувачів.
Логіка файлу тримається на кількох рівнях. Pages розділяють області продукту, Sections збирають пов’язані екрани, Frames формують контейнери, Styles і Variables забезпечують повторюваність, а Prototype і Dev Mode додають поведінку й технічне прочитання. Документація Figma називає фрейм батьківським об’єктом, здатним впливати на дочірні елементи, а секції — засобом організації та передавання дизайнів у розробку
Що потрібно вирішити до першого прямокутника
Порожній фрейм рідко буває справжнім початком роботи. До нього вже мають існувати щонайменше чотири відповіді: хто користувач, чого він намагається досягти, у якому контексті це відбувається і що система зобов’язана повідомити у відповідь. Якщо відповідей немає, дизайнер малює не інтерфейс, а власний настрій. Іноді настрій виходить дуже естетичним. Користуватися ним однаково складно.
Візьмімо екран відгуку на вакансію. Формальне завдання звучить просто: «Зробити форму відгуку». Якщо одразу відкрити Figma, рука майже автоматично намалює поля імені, електронної пошти, телефону, завантаження CV і велику кнопку. Проте реальне завдання значно ширше. Користувач уже авторизований чи прийшов уперше? Чи можна взяти дані з профілю? Який формат і розмір файлу допустимі? Чи зберігається чернетка? Що відбувається в разі обриву зв’язку? Чи потрібна згода на обробку даних? Чи отримає кандидат підтвердження? Чи може роботодавець закрити вакансію, поки форма відкрита?
Кожне з цих запитань потенційно створює стан, текст, компонент або перехід. Тому перед візуальним макетом корисно зібрати коротку модель сценарію: вхідні дані, основну дію, можливі перешкоди та результат. Вона не зобов’язана мати урочистий вигляд. Іноді достатньо схеми з п’яти блоків і кількох нотаток. Її цінність у тому, що дизайнер починає проєктувати не «форму взагалі», а конкретну поведінку системи.
Тут проявляється психологічна пастка Figma. Малювати приємно, тому що результат з’являється негайно. Поставити запитання аналітику або перечитати вимоги менш приємно: там можна виявити, що красиву ідею доведеться викинути. Мозок віддає перевагу дії, яка створює відчуття прогресу, навіть якщо це декоративний прогрес. Тому зрілість дизайнера добре видно за тим, як довго він здатен не прикрашати невизначеність.
Frame, Group, Section і Component: чотири сутності, які часто звалюють в один кошик
Якщо елементи візуально стоять поруч, це ще не означає, що вони утворюють осмислену конструкцію. У Figma різні контейнери виконують різні завдання, а плутанина між ними розповзається файлом швидше, ніж повідомлення «маленька правка» у п’ятницю ввечері.
Сутність | Для чого вона потрібна | Що вона повідомляє команді |
|---|---|---|
Frame | Створює батьківський контейнер для екрана або блоку, підтримує Auto Layout, обмеження, напрямні, обрізання вмісту та прототипування | «Ці елементи утворюють одну інтерфейсну конструкцію та підпорядковуються спільним правилам» |
Group | Тимчасово об’єднує об’єкти для вибору й переміщення | «Зараз ці елементи зручно рухати разом», але майже нічого не говорить про їхню продуктову поведінку |
Section | Організовує пов’язані області полотна, дає їм назву, посилання і статус передавання в розробку | «Ось завершений сценарій, версія або робоча зона» |
Component | Описує повторно використовуваний елемент із контрольованими варіантами та властивостями | «Це не унікальна картинка, а екземпляр спільного правила» |
Group корисна, коли потрібно швидко перемістити ілюстрацію з кількох векторів або тимчасово зібрати об’єкти. Проте використовувати групи як основу інтерфейсу — усе одно що будувати шафу на канцелярських скріпках: певний час конструкція навіть викликає повагу. Frame створює справжній контекст для дочірніх шарів. Саме всередині фрейму з’являються передбачувані правила розмірів, вирівнювання, прокручування й поведінки під час зміни контейнера.
Section розташована рівнем вище. Вона не замінює екран і не керує його внутрішнім компонуванням. Натомість секція може зібрати, наприклад, увесь сценарій Apply flow / Mobile / Approved: форму, помилку завантаження, успішний відгук і підтвердження електронною поштою. Посилання можна вести не в туманну область полотна, а в конкретний змістовий блок. Коли секцію позначають як Ready for development, розробник бачить, що саме команда вважає готовим. Важливо: такий статус не блокує подальших змін; якщо дизайн усередині змінюється, статус також повинен це відображати. Figma спеціально підтримує стан Changed, щоб оновлення після handoff не розчинялися в колективній пам’яті
Архітектура файлу: порядок потрібен раніше за красу
Структура файлу — частина інтерфейсу, просто його користувачі сидять усередині вашої команди. Вони також втомлюються, помиляються, поспішають і не хочуть двадцять хвилин шукати актуальний мобільний екран. Тому до Figma-файлу можна застосувати ті самі UX-принципи, що й до продукту: зрозумілу навігацію, видимий статус, передбачувані назви та мінімум здогадок.
Зазвичай за допомогою Pages розділяють дослідження, користувацькі потоки, wireframes, актуальний UI, компоненти й архів. Для невеликого лендингу шість сторінок будуть адміністративним театром, а для продукту з десятками сценаріїв одна сторінка швидко перетвориться на археологічну пам’ятку. Масштаб структури має відповідати роботі; Figma дає змогу виділяти сторінки під різні етапи й основні компоненти
Назви екранів повинні відповідати на запитання «що це й у якому стані», а не фіксувати емоційну історію автора. Checkout / Payment / Error — Card declined корисніше, ніж Frame 147, New, New new і особливо Final 6 copy. Людина, яка вперше відкрила файл, має зрозуміти маршрут без екскурсії від власника. Якщо без власника файл німіє, перед нами не робочий інструмент, а особистий щоденник із прямокутниками.
Секції зручно використовувати для сценаріїв, платформ, релізів або статусів. Усередині секції екрани розташовують у напрямку читання, а застарілі варіанти переносять до архіву, а не залишають поруч «для історії». Історія вже існує у Version History. Figma автоматично зберігає контрольні точки й дає змогу називати важливі версії та додавати описи змін. Названа версія Handoff 1.3 — upload errors added приносить більше користі, ніж ще одна цвинтарна зона праворуч від актуального макета
Геометрія інтерфейсу: напрямні, обмеження та сенс відстаней
Коли структура файлу зрозуміла, починається робота з геометрією. На цьому етапі дизайнер визначає ширину контенту, колонки, поля, ритм відступів і співвідношення між блоками. Layout guides допомагають підтримувати загальну сітку екрана: колонки корисні для вебінтерфейсів, рядки — для вертикального ритму, рівномірна сітка — для точної роботи з іконками й невеликими модулями. Це візуальні напрямні, а не механізм автоматичного компонування. В актуальній термінології Figma вони називаються layout guides і відрізняються від grid flow усередині Auto Layout
Сітка не зобов’язана починатися з магічного числа дванадцять. Кількість колонок обирають відповідно до характеру контенту та діапазону ширин. Кабінет із таблицями, маркетингова сторінка й мобільна форма відгуку потребують різної композиції. Хороша сітка зменшує кількість випадкових рішень: заголовок, картки й фільтри вирівнюються за спільною логікою, а не тому, що дизайнер на масштабі 173% відчув внутрішню гармонію.
Далі з’являються constraints — обмеження, які пояснюють, як шар поводиться під час зміни батьківського фрейму. Елемент можна утримувати біля лівого або правого краю, розтягувати між сторонами, центрувати чи масштабувати. Обмеження особливо важливі для шарів поза потоком Auto Layout і для об’єктів з абсолютним позиціонуванням. Їхнє завдання — зберігати співвідношення з контейнером, коли змінюється розмір контейнера. Офіційна довідка формулює це прямо: constraints визначають реакцію шару на зміну розміру фрейму
Однак обмеження не перетворюють один desktop-макет на доказ адаптивності. Якщо дизайнер розтягнув фрейм із 1440 до 390 пікселів і нічого драматичного не сталося, це поки що означає лише те, що шари вміють рухатися. Потрібно також перевірити зміну порядку, перенесення тексту, зникнення другорядних елементів, заміну таблиці картками, доступність дій і реальні контрольні точки. Адаптивність — це продуктові рішення на різних ширинах, а не цирковий номер із гумовим прямокутником.
Auto Layout: момент, коли макет починає розуміти вміст
Auto Layout — центральний механізм сучасного інтерфейсного файлу у Figma. Він задає напрямок потоку, відступи всередині контейнера, відстань між дочірніми елементами, вирівнювання та правила зміни розмірів. Вкладені Auto Layout-фрейми дають змогу створювати багатовимірні конструкції: вертикальна картка містить горизонтальний рядок автора, той — аватар і текстовий блок, а всередині тексту знову працює вертикальний потік.
Найважливіша частина Auto Layout прихована не в кнопці ввімкнення, а в трьох моделях розміру: Fixed, Hug contents і Fill container. Fixed говорить: розмір визначено заздалегідь. Hug contents змушує контейнер підлаштовуватися під вміст з урахуванням padding і gap. Fill container наказує дочірньому елементу зайняти доступний простір батьківського. Figma також підтримує мінімальні й максимальні розміри, що дає змогу описувати реалістичніші межі розтягування
Розгляньмо кнопку. Текстова мітка Apply now має природну ширину. Контейнер кнопки отримує горизонтальні внутрішні відступи й Hug contents за шириною. Якщо замінити мітку на Надіслати відгук, кнопка розшириться, а текст не проб’є її бік, наче пасажир у переповненій маршрутці. Іконка залишається фіксованого розміру, відстань між іконкою й текстом задається через gap, а висота кнопки відповідає вибраному розміру компонента.
Тепер розмістімо кнопку в нижній частині мобільної форми. На широкому екрані вона може зберігати Hug contents, а на мобільному — використовувати Fill container, займаючи ширину батьківського блоку. Це вже не дві випадково намальовані кнопки, а дві реалізації однієї логіки в різних контейнерах. Розробник бачить намір: ширина залежить не від смаку, а від доступного простору й патерну платформи.
У картки вакансії логіка інша. Зовнішній контейнер заповнює колонку за шириною та підлаштовується під вміст за висотою. Заголовок може переноситися, метадані — перебудовуватися або переходити на наступний рядок, а блок дій залишається доступним. Якщо картка ламається після додавання довгої назви Senior Infrastructure Reliability and Corporate Systems Engineer, проблему буде виявлено у Figma, а не після листа від QA. У цьому й полягає економічний сенс Auto Layout: він переносить частину помилок із дорогої стадії розробки на дешеву стадію моделювання.
Контент — це не наповнювач, а навантажувальний тест
Lorem ipsum заспокоює. Він однаково сірий, слухняно займає місце й ніколи не повідомляє, що документ перевищує допустимий розмір. Тому інтерфейс із заглушками майже завжди має зріліший вигляд, ніж є насправді. Реальний текст швидко показує, де дизайнер побудував систему, а де акуратно сфотографував ідеальні умови.
Для перевірки потрібні короткі й довгі імена, багаторядкові заголовки, порожні значення, великі числа, різні дати, системні повідомлення та реальні мови продукту. На ринках регіону кирилиця й латиниця мають різну візуальну щільність, слова розширюються під час перекладу, адреси й телефони живуть за різними правилами. Інтерфейс лише з John Smith і Product Designer пройшов не тест, а фотосесію.
Текст має бути частиною ієрархії. Заголовок відповідає за розпізнавання завдання, підпис уточнює дію, placeholder показує формат, helper text запобігає помилці, а error text пояснює спосіб відновлення. Написати під полем Invalid input — усе одно що лікарю повідомити пацієнтові «з вами щось не так» і піти у відпустку. Повідомлення Завантажте файл PDF або DOCX розміром до 10 МБ пов’язує проблему з рішенням і водночас дає розробнику чітке правило.
У Figma текстові властивості компонентів дають змогу позначити, які рядки дозволено змінювати, а Variables можуть зберігати рядкові значення й перемикати контекст. Проте локалізація не зводиться до механічної заміни тексту через mode. Потрібно перевірити довжину, напрямок читання, перенесення, форматування та культурний сенс. Змінна здатна підставити фразу. Вона поки що не здатна засоромитися через те, що дизайнер сховав половину цієї фрази під іконкою.
Components: як перетворити повторення на домовленість
Компонент у Figma складається з main component і пов’язаних із ним instances. Головний компонент визначає будову та властивості, а екземпляри повторно використовуються на екранах і отримують оновлення. Це робить компонент схожим на контракт: команда один раз домовляється, із чого складається кнопка, поле або картка, а потім послідовно застосовує це рішення.
Компонент потрібен не тому, що об’єкт зустрівся двічі. Повторюваність — лише перший сигнал. Важливіше, чи має об’єкт стабільну роль, єдину логіку й очікувані варіанти. Кнопка, поле введення, badge, navigation item і картка вакансії зазвичай мають таку роль. Випадкова декоративна композиція на промосторінці може залишитися звичайним фреймом. Якщо компонент створюють раніше, ніж зрозуміли його сенс, система отримує ідеально організовану помилку.
Variants об’єднують близькі версії компонента в component set і описують відмінності через властивості: наприклад, Type=Primary, Size=Medium, State=Disabled. Це наближає мову макета до мови реалізації. Однак варіанти легко розмножуються. Якщо перетворити на variant кожне поєднання розміру, стану, теми, наявності іконки, її розташування та довжини тексту, компонент дуже швидко обзаведеться населенням невеликої столиці.
Для керування складністю існують component properties. Variant property відповідає за осмислені стани або типи. Boolean property вмикає та вимикає необов’язковий шар. Instance swap дає змогу замінити вкладену іконку або інший компонент, за потреби обмеживши бажані варіанти. Text property відкриває редагування потрібного рядка. Slot створює гнучку область, куди можна додавати та перебудовувати вміст, не від’єднуючи екземпляр. Figma збирає ці налаштування на правій панелі, щоб користувачеві компонента не доводилося розшукувати дозволені зміни всередині дерева шарів.
Повернімося до кнопки. Її тип і стан логічно виразити варіантами, наявність провідної іконки — boolean-властивістю, саму іконку — instance swap, підпис — text property, а кольори теми — змінними. Так модель повідомляє призначення кожної зміни. Якщо все виразити варіантами, система роздується; якщо все залишити вільними overrides, екземпляри почнуть мутувати незалежно. Один шлях веде до бюрократії, другий — до зоопарку. Хороший компонент утримує середину.
Detach instance може бути виправданим для експерименту, але він розриває зв’язок із головним компонентом. Від’єднаний елемент припиняє отримувати оновлення й може довго вдавати, що залишається частиною системи, — як працівник, який уже звільнився, але все ще отримує запрошення на дзвінки.
Styles і Variables: зовнішня схожість, різна робота
Styles і Variables часто сприймають як два способи зберегти колір. Це надто вузьке розуміння. Style зберігає набір візуальних властивостей: наприклад, шрифт, розмір, line height і letter spacing для тексту; кілька ефектів для тіні; параметри напрямних. Variable зберігає повторно використовуване значення, яке може змінюватися залежно від контексту або mode. Обидва механізми можна публікувати в бібліотеках і оновлювати між файлами, але рівень абстракції в них різний
Механізм | Що зберігає | Практичний приклад |
|---|---|---|
Style | Пов’язаний набір візуальних параметрів | Text/Body/Medium: гарнітура, кегль, висота рядка, трекінг |
Variable | Одне повторно використовуване значення з можливими modes та aliases | color/text/primary, яке отримує різні значення в Light і Dark |
Component | Структуру, допустимі зміни й іноді інтерактивну поведінку | Input із label, полем, helper text і станами |
Library | Канал поширення компонентів, стилів і змінних між файлами | Спільна продуктова дизайн-система команди |
Сила Variables розкривається в семантичних назвах і aliasing. Припустімо, primitive-змінна gray/900 зберігає конкретний колір. Семантична color/text/primary посилається на неї у світлій темі й на gray/50 — у темній. Екран використовує не «сірий 900», а «основний колір тексту». Коли тема змінюється, дизайнер перемикає mode, а не перефарбовує двісті шарів вручну, поступово втрачаючи волю до життя.
Modes можуть представляти теми, бренди, щільність інтерфейсу, платформи або мовний контекст. Колекції групують змінні, scopes обмежують їхнє застосування, aliases пов’язують семантичний шар із базовими значеннями. У Dev Mode видно назву змінної, колекцію, mode, значення та ланцюжок aliases
Проте змінні не виправляють погану модель. Назви green1, green2 і newGreenFinal залишаються хаосом, навіть якщо хаос тепер централізований. Семантика має відображати роль: фон поверхні, текст помилки, межу фокуса, відстань між елементами. Тоді токен можна зіставити з кодом, а зміна не вимагатиме колективного ворожіння, який саме зелений був «тим самим».
Стани: інтерфейс починається там, де закінчується ідеальний сценарій
Статичний екран показує лише один момент. Продукт існує в часі: дані завантажуються, люди помиляються, права доступу змінюються, сервер відповідає повільно, дія завершується або відхиляється. Тому готовий дизайн — це набір станів і переходів, а не парад щасливих екранів.
Форма відгуку має початковий стан, введення, фокус, заповнені поля, перевірку, завантаження CV, помилку формату, помилку мережі, надсилання, успіх і ситуацію, коли вакансію вже закрито. Кнопка має default, hover, pressed, focus, disabled і loading. Список має дані, порожній результат, завантаження, часткове завантаження й помилку. Не кожен проєкт зобов’язаний малювати всі можливі катастрофи, інакше реліз відбудеться після теплової смерті Всесвіту. Проте команда має визначити стани, які впливають на розуміння, дію та відновлення користувача.
Важливо розрізняти disabled і loading. Disabled повідомляє, що дія зараз недоступна, і потребує зрозумілої причини. Loading повідомляє, що дію прийнято й система зайнята. Якщо після кліку кнопка просто сіріє, користувач не знає, йому заборонили діяти чи дані вже надсилаються. Він натискає знову, система створює два відгуки, аналітика отримує релігійний досвід.
Focus — ще один стан, який часто зникає з макетів. Для користувача клавіатури видимий фокус показує поточне положення в інтерфейсі. Його не можна вважати декоративною облямівкою, яку розробник додасть на свій смак. Дизайнер повинен визначити контраст, форму, відступ і поведінку фокуса, а також логічний порядок переходу. Те саме стосується error state: колір допомагає, але не повинен бути єдиним носієм сенсу; повідомлення, іконка та зв’язок із конкретним полем роблять помилку помітною і зрозумілою.
Prototype: репетиція поведінки, а не вистава заради лайків
У Prototype mode об’єкти стають точками взаємодії, зв’язки ведуть до цільових фреймів, а trigger, action і animation описують реакцію. Overlays підходять для модальних вікон, меню, підказок і підтверджень. Interactive components дають змогу пов’язати варіанти через дію Change to, тому перемикач або кнопка можуть поводитися однаково в усіх екземплярах. Variables і conditionals дають змогу змінювати збережені стани, текст, видимість і значення, а також будувати if/else-логіку з меншою кількістю дубльованих екранів
Хороший прототип відповідає на конкретне запитання. Чи знаходить людина завантаження CV? Чи розуміє, що відгук надіслано? Чи може повернутися й виправити дані? Чи помічає помилку? Для перевірки інформаційної архітектури достатньо простих переходів. Для тестування мікровзаємодії знадобиться точніша анімація. Для обговорення бізнес-логіки корисніше показати розгалуження й стани, ніж полірувати рух іконки тривалістю 120 мілісекунд.
Прототип залишається моделлю. Він не відтворює повністю реальну мережу, браузер, клавіатуру, API, скринрідер та обмеження production-коду. Надто гладка демонстрація здатна приховати складність реалізації: дизайнер натиснув Smart Animate, і складний перехід виник із повітря; у розробника повітря чомусь не компілюється. Тому поруч із демонстрацією мають існувати специфікації й домовленості про те, яка частина поведінки є обов’язковою, а яка лише ілюструє намір.
Спільна робота: коментар має закривати рішення, а не прикрашати полотно
Figma підтримує коментарі безпосередньо в design-файлах і прототипах. Це корисно, тому що обговорення залишається поруч з об’єктом, а не розчиняється між месенджером, відеодзвінком і пам’яттю людини, яка «точно все записала». Коментувати можуть користувачі з доступом на перегляд, а гілки дають змогу обговорювати й закривати питання у вихідному контексті.
Однак коментар корисний лише тоді, коли з нього зрозуміле рішення. Не подобається описує стан автора, але не продукту. За ширини 360 px основна дія опускається нижче першого екрана; пропоную скоротити допоміжний текст або змінити порядок блоків уже створює предмет для обговорення. Після ухвалення рішення зміни вносять у макет, а гілку закривають. Якщо коментар містить важливе постійне правило, його переносять до документації або annotation: закрита гілка не повинна бути єдиним сховищем продуктової пам’яті.
Команда часто залишає на полотні всі версії, тому що боїться втратити варіант і взяти на себе відповідальність за вибір. У результаті файл демонструє не багатство дослідження, а нездатність завершити думку. Архів і Version History зберігають минуле; актуальна область має показувати ухвалене рішення, інакше розробнику передають колективну тривогу у форматі .fig.
Перевірка макета перед передаванням: що дизайнер зобов’язаний зламати сам
Перед handoff дизайнеру корисно припинити милуватися макетом і почати ставитися до нього як QA з особистою образою. Потрібно змінювати ширину контейнерів, подовжувати текст, прибирати дані, вмикати інші modes, перевіряти вкладеність, переглядати overrides і шукати елементи, які тримаються на ручних координатах. Хороший файл витримує зміну вмісту. Якщо картка переживає лише той текст, під який її малювали, це ілюстрація картки, а не картка.
Перевірка починається з користувацького шляху. Чи показано всі обов’язкові стани? Чи зрозуміло, звідки прийшла людина й куди потрапить після дії? Чи є вихід із помилки? Потім перевіряють візуальну систему: чи використовуються узгоджені text styles, semantic variables і бібліотечні components; чи не з’явилися випадкові кольори, відступи й від’єднані instances. Після цього перевіряють адаптивність: ключові ширини, перенесення, min/max, видимість дій, touch targets і прокручування.
Окремий шар — доступність. Контраст, розмір тексту, видимий фокус, зрозумілі labels, порядок читання, помилки й альтернативи колірним сигналам мають бути частиною дизайну. Figma може зберігати й показувати багато з цих рішень, але не ухвалює їх замість команди. Червона рамка навколо поля ще не пояснює помилку, а ідеально рівна іконка без доступної назви залишається ідеально рівною проблемою.
Нарешті, слід перевірити технічну чистоту: зрозумілі назви фреймів і шарів, коректні export settings, відсутність випадково прихованих об’єктів, актуальні посилання, потрібні шрифти, узгоджені змінні та зв’язок екземплярів із компонентами. Ця робота майже не потрапляє до портфоліо, тому що скриншот Layer names cleaned збирає мало захоплених реакцій. Натомість саме вона скорочує кількість повідомлень від розробника з формулюванням «а це що?».
Dev Mode і handoff: розробнику передають не пікселі, а намір
Handoff часто уявляють як певний момент: дизайнер закінчив, надіслав посилання й урочисто залишив сцену. Насправді передавання в розробку — це процес з уточненнями, змінами та зворотним зв’язком. Dev Mode створено саме як розробницький спосіб навігації та інспектування design-файлу. У ньому можна знаходити позначені як Ready for development секції, фрейми й компоненти, переглядати властивості, розміри та відстані, вивчати змінні, завантажувати assets, порівнювати зміни й читати annotations.
Annotations особливо корисні для інформації, яку неможливо вивести із зовнішнього вигляду. Біля поля варто вказати допустимий формат, обмеження довжини, поведінку під час вставлення й текст помилки. Біля картки — правило truncation і дію за відсутності даних. Біля модального вікна — чи закривається воно клавішею Escape та кліком поза областю, куди повертається фокус, чи блокується фон. Figma дає змогу прив’язувати до шарів текстові пояснення, властивості й вимірювання; властивості в annotations оновлюються разом із дизайном, що знижує ризик появи застарілих redlines.
Inspect показує box model, layout, typography і значення властивостей. Code snippets можуть бути представлені для CSS, SwiftUI або UIKit, Compose чи XML залежно від платформи. Це прискорює читання макета, але автоматично згенерований фрагмент не слід плутати з production-кодом. Він не знає архітектури застосунку, домовленостей команди, вимог доступності, бізнес-логіки та продуктивності. Офіційна документація окремо описує Code Connect: він пов’язує компоненти Figma з реальними компонентами кодової бази, щоб замість загального представлення розробник бачив прийнятий у продукті API та приклад використання
Саме тут стає помітною якість усієї попередньої роботи. Якщо шар називається Rectangle 583, відстань задано випадково, колір не прив’язаний до змінної, а кнопку від’єднано від компонента, Dev Mode чесно покаже цю анатомію. Він не перетворює безлад на специфікацію; він лише вмикає яскраве світло в кімнаті.
Хороший handoff відповідає не лише на запитання «скільки пікселів», а й на запитання «яке правило», «який стан», «який компонент», «що змінюється», «що залишається», «як перевірити готовність». Разом із Figma-секцією розробнику потрібні посилання на завдання, scope релізу, acceptance criteria, тексти, дані й обмеження API. Макет показує продуктову модель із боку інтерфейсу, але не зобов’язаний удавати всю інженерну документацію.
Наочний приклад: шлях форми відгуку від порожнього фрейму до Ready for development
Уявімо, що потрібно спроєктувати мобільний відгук на вакансію. Ми створюємо фрейм завширшки 390 пікселів, але поки що не малюємо UI. Спочатку фіксуємо мету: авторизований кандидат має перевірити контактні дані, додати CV й надіслати відгук. Головний ризик — втратити введене або не зрозуміти, чи завантажився файл. Успіх — побачити підтвердження й наступний крок.
На рівні потоку з’являються перегляд даних, завантаження файлу, надсилання й результат, а поруч — розгалуження для непідтримуваного формату, завеликого файлу, помилки мережі та закритої вакансії. Одного красивого екрана вже недостатньо: знадобляться стани Upload, повідомлення форми й різні результати надсилання.
Основний фрейм отримує вертикальний Auto Layout. Усередині розташовані header, інформаційний блок про вакансію, form content і зона дії. Контентний блок використовує Fill container за шириною та Hug contents за висотою. Поля зібрані з бібліотечного Input: label, control, helper або error. Відстані прив’язані до spacing variables, текст — до styles, кольори — до semantic variables. Кнопка на мобільному займає доступну ширину, а її мітка залишається редагованою text property.
Upload стає компонентом зі станами Empty, Uploading, Uploaded і Error. Ім’я файлу — text property, видалення — вкладена icon button. Помилка розміру з’являється поруч із завантаженням, де користувач може її виправити; мережева помилка після надсилання отримує Retry без втрати введених даних.
Далі замість CV.pdf підставляється Oleksandr_Kovalenko_Product_Designer_Portfolio_2026.pdf, а замість короткої вакансії — довга назва. Перевіряються реальні локалізації. За ширини 320 пікселів ім’я файлу скорочується, розширення залишається видимим, а кнопка видалення не виїжджає за край.
У Prototype mode пов’язуються надсилання, loading, success і retry. Перевіряється, чи помічає користувач зміну стану й чи може відновитися після помилки. Важливий принцип: дію прийнято, прогрес видно, повторний клік унеможливлено, дані зберігаються.
Перед handoff дизайнер створює секцію Apply / Mobile / v1.3 з основним потоком і станами. Annotations фіксують формати PDF/DOCX, ліміт 10 МБ, скорочення імені, Retry, збереження даних і порядок фокуса. Після перевірки variables, component links і шарів версія отримує назву, а секцію позначають як Ready for development.
Розробник відкриває посилання в Dev Mode і бачить не екскурсію творчою біографією дизайнера, а обмежений набір готових екранів. Він може перевірити розміри, padding, типографіку, токени й компоненти, завантажити потрібну іконку та порівняти зміни з переглянутою версією. Якщо після передавання змінюється ліміт файлу, дизайнер оновлює annotation і статус; зміна стає видимою, а не передається шаманським способом через фразу «здається, ми про це говорили».
Дев’ять типових поломок між фреймом і кодом
Перші поломки — групи й ручні координати замість структури, а також Auto Layout заради Auto Layout, де кожен шар вкладено в п’ять безіменних контейнерів. Потім з’являються компоненти, створені до розуміння патерну, вільні overrides, постійний Detach і візуальні значення без семантики. Один підхід ламається під час зміни тексту, інший створює дерево, яке формально розумне, а на практиці нечитабельне.
Інші поломки пов’язані з процесом: проєктується лише happy path, прототип вражає анімацією й мовчить про логіку, Ready for development установлюють до перевірки, а код з Inspect сприймають як готову реалізацію. Тоді порожні дані, помилки й обмеження вперше обговорюються вже під час розробки людиною, яка просто хотіла закрити завдання. У продукту щодо цього зазвичай похмуріші плани.
Усі ці помилки об’єднує одне: макет сприймають як фінальне зображення. Тоді структура здається зайвою, стани — додатковою роботою, назви — косметикою, а handoff — посиланням. Щойно Figma стає моделлю продукту, ті самі дії набувають сенсу. Auto Layout описує залежності, component — повторюване правило, variable — значення в контексті, prototype — перехід, annotation — рішення, Ready for development — відповідальність за конкретну версію.
Як зрозуміти, що макет справді готовий до розробки
Макет готовий, коли команда може відновити його логіку без постійної присутності автора. Користувацькі шляхи узгоджені, ключові стани показані, тексти близькі до фінальних, адаптивність перевірена, а компоненти та змінні відповідають системі. На запитання про довгий заголовок, іншу мову, порожню відповідь API й вузький екран відповідають структура, властивості або annotations, а не дизайнер, який тимчасово виконує обов’язки документації.
Розробник водночас бачить актуальний scope, розпізнає production-компоненти й відрізняє обов’язкову поведінку від демонстраційної анімації. Handoff не завершує співпрацю, а переводить її до обмежень реалізації, даних і крайніх випадків. Дизайнер і розробник читають одну модель із різних боків, тому жодному з них не доводиться відновлювати продукт за піксельними рештками.
Що зрештою відбувається всередині Figma
Між порожнім фреймом і handoff дизайнер послідовно зменшує кількість здогадок. Спочатку він перетворює завдання на сценарій, потім сценарій — на ієрархію, ієрархію — на адаптивне компонування, повторення — на компоненти, значення — на styles і variables, моменти — на стани, а поведінку — на prototype. Після перевірки все це отримує назви, версії, пояснення та статус готовності.
Тому професійний Figma-файл рідко вражає кількістю ефектів. Він вражає тим, як мало в ньому доводиться вгадувати. Можна замінити текст, змінити ширину, перемкнути тему, відкрити стан помилки й зрозуміти, що станеться. Розробник бачить не муміфікований екран, а систему зі зрозумілими суглобами. І якщо після розтину ніхто не закричав, що кнопка насправді мала надсилати три різні форми, отже, операція минула напрочуд успішно.
Ресурси та міркування
В основі цього розбору лежить офіційна документація Figma Learn, присвячена роботі з Frames, Auto Layout, Components, Variables, Prototyping і Dev Mode. Ці матеріали корисні як технічна опора: вони пояснюють можливості інструмента, обмеження окремих функцій та актуальну термінологію.
Однак документація відповідає переважно на запитання «як працює функція». У реальному проєкті важливіше наступне запитання: «яку невизначеність ця функція має усунути?» Auto Layout потрібен не заради акуратного дерева шарів, а заради передбачуваної поведінки контенту. Components існують не для красивої бібліотеки, а для повторюваних правил. Variables цінні не кількістю створених токенів, а можливістю змінювати контекст без ручного перефарбовування сотень елементів. Dev Mode також не перетворює макет на код — він робить рішення дизайнера доступнішими для інженерної команди.
Тому стаття розглядає Figma як робочу систему, а не каталог інструментів. Її головний критерій простий: хороший файл повинен залишатися зрозумілим, коли автор закрив ноутбук. Якщо інший дизайнер може змінити вміст, розробник — відновити логіку, а команда — побачити актуальний стан сценарію, отже, між порожнім фреймом і handoff справді було виконано роботу. Усе інше може виявитися дуже дорогою колекцією прямокутників.
