Архівний матеріал: розбір публікації від 2023-11-17. Назви функцій, інтерфейс, можливості плагінів і умови доступу наведені в контексті того часу.
У матеріалі розбирається підхід методу Matthew Mattei та команди Uno Platform: як вони будують спільний процес роботи дизайнерів і .NET-розробників навколо Figma та плагіна Uno Platform (Figma to C# or XAML), щоб зменшити ручний хендоф і одразу отримувати придатний до роботи XAML/C# код.
Де ламається класичний дизайн-хендоф
Автор описує знайому для більшості продуктових команд ситуацію: дизайнери готують детальний макет, документують відступи, стани й активи, передають усе в розробку і переходять до наступного проєкту. Далі розробники вручну «перекладають» макети у верстку та код, відновлюючи:
- відступи, сітку, вирівнювання;
- типи контролів та їх стани (loading, error, partial, disabled тощо);
- кольори, шрифти, іконки, активи;
- сторінкові й компонентні варіанти.
Через те, що кожна сторона працює у своєму середовищі (Figma vs IDE), часто бракує єдиного джерела правди. Автор підкреслює дві типові крайнощі:
- розробники бачать тільки свої дрібні задачі й втрачають цілісну картинку інтерфейсу, що веде до переробок;
- дизайнери активно «перетасовують» цілі блоки макета і легко пропускають окремі стани, які критично важливі вже на етапі імплементації.
Результат — дороге і повільне конвертування дизайну в код, яке погано масштабується. Uno Platform пропонує перенести частину цієї роботи в саму Figma, зробивши макет не просто ілюстрацією, а основою для генерації реального XAML/C#.

Як Uno Platform пропонує об'єднати дизайн і розробку
Філософія підходу, описаного автором: Figma-файл має стати єдиним джерелом правди, з яким погоджуються й дизайнери, й розробники, й стейкхолдери. Звідти ж і генерується код, на який спирається команда розробки.
Ключові елементи цього процесу:
- Спільний інструмент для дизайну — Figma як кросплатформний веб-інструмент, яким можуть користуватися команди незалежно від ОС (на відміну від зв'язки Sketch + Zeplin, прив'язаної до macOS).
- Стандартизований дизайн-сет — Uno Material Toolkit у Figma, де всі компоненти вже підготовлені під мультиплатформні застосунки.
- Плагін Uno Platform для Figma — генерує код інтерфейсу (XAML або C# markup) та файли перевизначення кольорів і шрифтів безпосередньо з макета.
- Живий прев'юер — дає дизайнерам проганяти інтерфейс як «живий» застосунок ще до того, як розробники почнуть верстку.
Автор прямо застерігає: це не повна відмова від співпраці, а інший розподіл праці. Дизайнери й надалі будують UX, а розробники додають бізнес-логіку, навігацію, стан, але стартують з уже узгодженого коду, а не з нуля.
Вибір стеку: чому саме Figma і Uno Material Toolkit
Автор пояснює, чому команда Uno Platform будувала процес саме навколо Figma:
- інструмент працює в браузері й не вимагає Mac для перегляду/редагування;
- є плагіни, спрямовані конкретно на хендоф (згадується, наприклад, Clippy — add attachments для вкладень у файли Figma);
- Figma вже стала основним дизайновим інструментом у багатьох компаній — автор посилається на кейси Purplebricks Digital і Zomato.
Фундаментом для автоматичної генерації коду виступає Uno Material Toolkit — Figma-файл із бібліотекою компонентів під Uno Platform.

Критичне обмеження, на якому наголошує автор: щоб плагін Uno Platform працював, дизайн має бути створений всередині файлу Uno Material Toolkit і використовувати його компоненти. Існуючі Figma-дизайни, зроблені «як завжди», плагін просто не зможе конвертувати.
DSP та передача дизайн-системи в код
Для налаштування теми використовується Design System Package (DSP). У термінах автора це:
- репозиторій графічних активів (іконки, кнопки, UI-елементи);
- JSON-файли з описом токенів дизайн-системи (кольори, шрифти тощо).
Сценарій, який пропонує автор:
- Дизайнери збирають власний DSP (фірмова тема, набір токенів).
- DSP імпортується в Uno Material Toolkit у Figma, макет від початку будується з урахуванням цих токенів.
- Ті самі токени через плагін експортуються в Uno Platform застосунок і підключаються як файли перевизначення кольорів/шрифтів.
Таким чином, зміна дизайн-системи синхронно оновлює вигляд застосунку, а не веде до розсинхронізації між макетами та кодом.
Покроковий робочий процес в Uno Figma Plugin
Крок 1. Підготовка середовища
Згідно з інструкцією автора, базове налаштування виглядає так:
- Встановити плагін Uno Platform (Figma to C# or XAML).
- Відкрити файл Uno Platform Material Toolkit з Figma Community.
- На сторінці Getting Started налаштувати тему (кольори, шрифти) або імпортувати свій DSP.
- Створити нову сторінку і вставити Standard Page Template з бібліотеки компонентів, потім Detach instance, щоб мати змогу його редагувати.

Ці кроки повторюються для кожного нового проєкту. Автор рекомендує виконувати налаштування теми на старті — так легше зберігати порядок, а не повертатися до редизайну всього інтерфейсу через зміну базових токенів.
Крок 2. Проєктування інтерфейсу тільки з toolkit-компонентів
Uno Material Toolkit містить компоненти з варіантами (variants). Приклад, на якому зупиняється автор — кнопка з варіантом Leading Icon: той самий компонент, але з прапорцем для відображення іконки перед текстом.

Що це дає в контексті design-to-code:
- структура шарів, відступи, стани вже узгоджені з очікуваною XAML/C#-структурою;
- плагін може однозначно зіставити Figma-компонент з Uno Toolkit-контролом;
- повторне використання компонентів у Figma транслюється в більш чистий і повторновикористовний код.
Крок 3. Живий прев'юер
Автор окремо виділяє можливість попереднього перегляду застосунку ще всередині Figma:
- У Figma вибрати екран для прев'ю.
- Right-click → Plugins → Uno Platform (Figma to C# or XAML).
- У вікні плагіна перейти на вкладку Preview.
- Натиснути Refresh.
У результаті дизайнери отримують інтерактивне прев'ю: можна скролити, натискати кнопки, перевіряти стани контролів. Це дозволяє виявляти проблеми до того, як вони «дістануться» розробникам, та зменшує кількість уточнень і редизайнів.
Крок 4. Перегляд і експорт коду
Далі працює вкладка Export. Автор описує, що з неї можна:
- перемикатися між C#, XAML, Color Override File, Fonts Override File;
- копіювати згенерований код у буфер обміну;
- налаштовувати деякі властивості (наприклад, namespace) у вкладці Properties.
Для команди це означає:
- дизайнер не зобов'язаний копіювати код — це можуть робити розробники через Dev Mode у Figma без ролі editor;
- розробник одразу отримує XAML/C#-розмітку сторінки плюс файли токенів (кольори, шрифти, локалізаційні ключі), підготовлені до вставки в проєкт Uno Platform.
Перекидання моста до Visual Studio
Наступний блок тексту присвячений тому, як згенерований код інтегрується в .NET-проєкт на Uno Platform. Автор орієнтується на Visual Studio та використовує Uno Solution Template Wizard.
Сценарій із XAML
Згідно з кроками автора розробник:
- Створює новий проєкт Uno через Uno App Template Wizard (XAML як спосіб опису UI).
- Відкриває
MainPage.xaml, видаляє вміст і вставляє XAML зі вкладки Export плагіна. - Коригує
x:classтаxmlns:local, щоб відповідали namespace проєкту. - Окремо експортує файл перевизначення кольорів і вставляє контент у
ColorPaletteOverride.xamlзгідно з документацією Uno Material library → Customize Color Palette.
Сценарій із C# Markup
Для варіанта з C# Markup (коли UI описується кодом C#) кроки дещо відрізняються:
- У вкладці Export обрати C# Markup і виділити код після ключового слова
thisдо фінальної крапки з комою. - Створити проєкт Uno з шаблоном, що підтримує C# Markup.
- У
MainPage.csзамінити вміст сторінки на код, скопійований із плагіна. - Для коректних шрифтів відкрити
MaterialFontsOverride.csі замінити ресурсний словник значеннями з вкладки Fonts Override File плагіна.
У обох сценаріях Uno Toolkit стає спільною основою: компоненти, використані у Figma, відповідають контролам, доступним у Uno Platform, а документація для них доступна в Getting Started with Uno Toolkit.
Міні-кейс: мобільний інтерфейс Flight App
Щоб показати, як цей процес виглядає «у живій» задачі, автор розбирає навчальний приклад — мобільний інтерфейс додатку для пошуку перельотів Uno Flights (Figma-файл-доклад можна взяти з Uno Flights file template).

Упор тут не на візуальні деталі, а на те, як використовувати готові компоненти Material Toolkit і Auto Layout так, щоб плагін коректно згенерував код.
Крок 1. Пошук, сортування й фільтри
Перший блок — зона пошуку рейсів і керування результатами:
- TextBox з власним placeholder'ом та опційними leading/trailing-іконками;
- Text з кількістю результатів, об'єднаний в Auto Layout (Shift + A);
- IconButton'и для сортировки та фільтрації, де іконка змінюється через Swap instance, а текст і іконка об'єднуються горизонтальним Auto Layout;
- вкладення цих блоків в один Auto Layout і перенесення разом із полем пошуку в
Content.Scrollableстандартного шаблону сторінки.

У реальному коді це перетворюється на стек з текстовими полями, полем введення і кнопками-фільтрами на базі Uno Toolkit.
Крок 2. Карточки рейсів
Другий великий блок — картка з інформацією про переліт. Автор ділить її на три секції, кожна в окремому Auto Layout:
- Час вильоту/прильоту і ProgressBar з іконкою літака, що позиціонується абсолютом поверх прогресу;
- Інформація про рейс — час у дорозі, статус, коди аеропортів;
- Авіакомпанія та вартість — текстові елементи з Auto Layout і коригованим горизонтальним відступом.

Потім три секції групуються в загальний Auto Layout з потрібним фоном та відступами й переносяться під content.Scrollable на сторінці. Той самий прийом можна застосувати й до подальших карток рейсів, щоб у коді з'явився один повторюваний шаблон.
Крок 3. Нижня навігаційна панель
Bottom TabBar входить до стандартного шаблону сторінки. Автор показує, що його кастомізація зводиться до двох дій:
- через Swap instance → Local components → Icons підмінити іконки на потрібні;
- оновити текст підписів відповідно до розділів застосунку.

Після цього інтерфейс уже придатний для попереднього перегляду в плагіні, а отже — й для генерації XAML/C#.
Крок 4. Прев'ю й передача в код
Фінальний етап для цього прикладу повторює загальну схему:
- Прев'ю інтерфейсу у вкладці Preview, перевірка взаємодій.
- Перехід у вкладку Export, копіювання XAML або C# Markup.
- Створення Uno-проєкту в Visual Studio та заміна вмісту
MainPageзгенерованим кодом. - Підключення файлів перевизначення кольорів і шрифтів.

Готові приклади кодів для цього кейсу автор надає окремими файлами: flightXAML.txt та flightCsharp.txt. Вони демонструють, який саме XAML і C# генерує плагін для описаної UI-структури.
Обмеження та практична користь підходу
Матеріал не подає Uno Figma Plugin як універсальне рішення для будь-якої зв'язки «дизайн → код». Автор описує конкретний сценарій:
- Figma як основний дизайн-інструмент;
- Uno Platform як цільовий фреймворк для побудови нативних застосунків (мобільних, десктопних, веб, embedded) з одним кодовим базисом;
- команда, готова будувати макети тільки з компонентів Uno Material Toolkit.
У цих рамках підхід дає відчутний виграш:
- менше ручної розмітки інтерфейсу розробниками;
- менше розривів між погодженим макетом і тим, що реально потрапляє в застосунок;
- можливість дизайнерів самостійно проганяти свій інтерфейс у «напівживому» стані;
- передача не тільки верстання, а й дизайн-системи (кольори, шрифти, токени) в структурованому вигляді.
Водночас, для команд, які:
- не використовують Uno Platform;
- мають вже великий парк старих Figma-файлів без Uno-компонентів;
- або жорстко прив'язані до іншого UI-фреймворку,
описаний процес напряму непридатний — плагін не може автоматично інтерпретувати довільні компоненти в Uno-контроли.
Сам автор рекомендує тим, хто працює з Uno Platform, дивитися також інші практичні туторіали команди Uno (логін-сторінка, профіль, UI для pet adoption чи dating app) і офіційну документацію Uno Platform 5.0 та Uno Toolkit, щоб розгорнути повноцінний дизайн-to-code процес у своїх проєктах.
Джерело: Matthew Mattei – Smashing Magazine. Дата оригіналу: 2023-11-17.