Практичний процес design-to-code з Uno Platform для Figma: як уникнути «болючого» хендофу

Архівний матеріал: розбір публікації від 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#.

A screenshot of the Uno Platform repository on Github
The GitHub repository of the open-source project Uno Platform.

Як 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.

Screenshot of the Uno Material Toolkit file available in Figma Community.
Uno Platform Material Toolkit (available in Figma Community).

Критичне обмеження, на якому наголошує автор: щоб плагін Uno Platform працював, дизайн має бути створений всередині файлу Uno Material Toolkit і використовувати його компоненти. Існуючі Figma-дизайни, зроблені «як завжди», плагін просто не зможе конвертувати.

DSP та передача дизайн-системи в код

Для налаштування теми використовується Design System Package (DSP). У термінах автора це:

  • репозиторій графічних активів (іконки, кнопки, UI-елементи);
  • JSON-файли з описом токенів дизайн-системи (кольори, шрифти тощо).

Сценарій, який пропонує автор:

  1. Дизайнери збирають власний DSP (фірмова тема, набір токенів).
  2. DSP імпортується в Uno Material Toolkit у Figma, макет від початку будується з урахуванням цих токенів.
  3. Ті самі токени через плагін експортуються в Uno Platform застосунок і підключаються як файли перевизначення кольорів/шрифтів.

Таким чином, зміна дизайн-системи синхронно оновлює вигляд застосунку, а не веде до розсинхронізації між макетами та кодом.

Покроковий робочий процес в Uno Figma Plugin

Крок 1. Підготовка середовища

Згідно з інструкцією автора, базове налаштування виглядає так:

  1. Встановити плагін Uno Platform (Figma to C# or XAML).
  2. Відкрити файл Uno Platform Material Toolkit з Figma Community.
  3. На сторінці Getting Started налаштувати тему (кольори, шрифти) або імпортувати свій DSP.
  4. Створити нову сторінку і вставити Standard Page Template з бібліотеки компонентів, потім Detach instance, щоб мати змогу його редагувати.

Screenshot of the Getting Started instructions page in Uno Material Toolkit file.
The Getting Started page in the Material Toolkit file.

Ці кроки повторюються для кожного нового проєкту. Автор рекомендує виконувати налаштування теми на старті — так легше зберігати порядок, а не повертатися до редизайну всього інтерфейсу через зміну базових токенів.

Крок 2. Проєктування інтерфейсу тільки з toolkit-компонентів

Uno Material Toolkit містить компоненти з варіантами (variants). Приклад, на якому зупиняється автор — кнопка з варіантом Leading Icon: той самий компонент, але з прапорцем для відображення іконки перед текстом.

Screenshot of the button components with a Leading Icon variant – the same set of icons is shown with an icon in front of the labels, and then without.
Button components with a Leading Icon variant: you can use the same element with or without icons in your design.

Що це дає в контексті design-to-code:

  • структура шарів, відступи, стани вже узгоджені з очікуваною XAML/C#-структурою;
  • плагін може однозначно зіставити Figma-компонент з Uno Toolkit-контролом;
  • повторне використання компонентів у Figma транслюється в більш чистий і повторновикористовний код.

Крок 3. Живий прев'юер

Автор окремо виділяє можливість попереднього перегляду застосунку ще всередині Figma:

  1. У Figma вибрати екран для прев'ю.
  2. Right-click → Plugins → Uno Platform (Figma to C# or XAML).
  3. У вікні плагіна перейти на вкладку Preview.
  4. Натиснути 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

Згідно з кроками автора розробник:

  1. Створює новий проєкт Uno через Uno App Template Wizard (XAML як спосіб опису UI).
  2. Відкриває MainPage.xaml, видаляє вміст і вставляє XAML зі вкладки Export плагіна.
  3. Коригує x:class та xmlns:local, щоб відповідали namespace проєкту.
  4. Окремо експортує файл перевизначення кольорів і вставляє контент у ColorPaletteOverride.xaml згідно з документацією Uno Material library → Customize Color Palette.

Сценарій із C# Markup

Для варіанта з C# Markup (коли UI описується кодом C#) кроки дещо відрізняються:

  1. У вкладці Export обрати C# Markup і виділити код після ключового слова this до фінальної крапки з комою.
  2. Створити проєкт Uno з шаблоном, що підтримує C# Markup.
  3. У MainPage.cs замінити вміст сторінки на код, скопійований із плагіна.
  4. Для коректних шрифтів відкрити MaterialFontsOverride.cs і замінити ресурсний словник значеннями з вкладки Fonts Override File плагіна.

У обох сценаріях Uno Toolkit стає спільною основою: компоненти, використані у Figma, відповідають контролам, доступним у Uno Platform, а документація для них доступна в Getting Started with Uno Toolkit.

Міні-кейс: мобільний інтерфейс Flight App

Щоб показати, як цей процес виглядає «у живій» задачі, автор розбирає навчальний приклад — мобільний інтерфейс додатку для пошуку перельотів Uno Flights (Figma-файл-доклад можна взяти з Uno Flights file template).

Screenshot of a flight app user interface and the generated code.
Uno Flights: a tutorial that will teach you how to create a mobile Uno Platform app.

Упор тут не на візуальні деталі, а на те, як використовувати готові компоненти Material Toolkit і Auto Layout так, щоб плагін коректно згенерував код.

Крок 1. Пошук, сортування й фільтри

Перший блок — зона пошуку рейсів і керування результатами:

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

Screenshot of step 1 in the flight app tutorial: adding search and filter results.
Step 1: Adding the Result Actions.

У реальному коді це перетворюється на стек з текстовими полями, полем введення і кнопками-фільтрами на базі Uno Toolkit.

Крок 2. Карточки рейсів

Другий великий блок — картка з інформацією про переліт. Автор ділить її на три секції, кожна в окремому Auto Layout:

  • Час вильоту/прильоту і ProgressBar з іконкою літака, що позиціонується абсолютом поверх прогресу;
  • Інформація про рейс — час у дорозі, статус, коди аеропортів;
  • Авіакомпанія та вартість — текстові елементи з Auto Layout і коригованим горизонтальним відступом.

The UI with the first card component created (step 2. completed).
The results after completing Step 2.

Потім три секції групуються в загальний Auto Layout з потрібним фоном та відступами й переносяться під content.Scrollable на сторінці. Той самий прийом можна застосувати й до подальших карток рейсів, щоб у коді з'явився один повторюваний шаблон.

Крок 3. Нижня навігаційна панель

Bottom TabBar входить до стандартного шаблону сторінки. Автор показує, що його кастомізація зводиться до двох дій:

  • через Swap instance → Local components → Icons підмінити іконки на потрібні;
  • оновити текст підписів відповідно до розділів застосунку.

Changing icons in the bottom tab bar screen (step 3. in progress).
Step 3: Swapping icon instances in the Bottom TabBar (Swap instance → Local components → Icons).

Після цього інтерфейс уже придатний для попереднього перегляду в плагіні, а отже — й для генерації XAML/C#.

Крок 4. Прев'ю й передача в код

Фінальний етап для цього прикладу повторює загальну схему:

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

Preview of final user interface (final step 4. now complete).
Step 4: The result in the Plugin Previewer.

Готові приклади кодів для цього кейсу автор надає окремими файлами: 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.

Пошук

Закрити