Пошук

Як зробити дизайн-системні компоненти придатними до використання, а не «ідеально складними» (частина 2)

·

Архівний матеріал: розбір публікації від 2023-12-18. Назви функцій, інтерфейс, можливості плагінів і умови доступу наведені в контексті того часу.

У матеріалі розбирається підхід Луїса Уріача до того, як будувати Figma-компоненти так, щоб їх реально споживали продукт-команди, а не оминали через складність. У фокусі чотири характеристики з його FRAILS-рамки: adoptable (придатні до впровадження), indexable (легко знаходяться), logical (логічні в роботі) та specific (достатньо конкретні).

Adoptable — компоненти, які хочеться використовувати

1. Іменування: про зручний пошук, а не про 1:1 з кодом

Автор виходить із болю з опитування Sparkbox 2022 року: серед трьох головних проблем дизайн-систем adoption опинилася на одному рівні з технічним боргом і паритетом «design — code». Тобто можна мати класну систему, але її просто не беруть у роботу.

Одна з ключових причин — як компоненти названі та знаходяться в інструменті. Уріач не радить зациклюватися на 1:1 відповідності між назвами в дизайні та в коді. Дизайнери й розробники шукають по-різному, тому вигідніше орієнтуватися на те, як кожна аудиторія шукає.

Практичний прийом — використовувати поле опису компонентів у Figma як «контейнер аліасів». Основні моменти:

  • компонент у коді може зватися headerNavItemActive, а в Figma — «Header link»;
  • в поле опису вносяться альтернативні назви: і кодова, і терміни, якими оперують дизайнери;
  • так само можна робити зі styles і variables, додаючи до опису всі поширені синоніми.

An illustration that explains how the component description field within Figma can be used in order to list out the possible name aliases of a component.
We can use the component description field within Figma to list out possible name aliases of a component.

Це не про красу, а про пошук: як тільки хтось шукає «header», «nav», «link» чи кодовий ідентифікатор, Figma тягне й текст з опису.

2. Окремі сети: «швидкі» стилі для ідей та семантичні токени для продакшену

Уріач описує конфлікт між більш «сирими» візуальними стилями для ідей та суворо семантичними токенами в коді. Якщо все змішати в один шар, команда ризикує отримати дві (або більше) «правди» й хаос у Figma.

Його порада для великих команд:

  • тримати швидкі стилі для ескізів/ідеації окремо від набору семантичних змінних;
  • на рівні продакшен-компонентів підв’язувати саме семантичні токени;
  • на рівні «пісочниці» — дозволяти використання більш інтуїтивних назв (типу Brand/Primary).

An illustration that explains how the bottom border for a header link should be named. On the left, you see a component ‘Header link,’ the bottom border is highlighted, and there are three arrows going to the right into three separate boxes: ‘Style: quick reference,’ ‘Variable: production,’ and ‘Variable: component (optional).’
How should we name the bottom border for a header link? A quick reference style, a production variable, or a component variable?

Приклад: дизайнер у процесі ідей робить активну вкладку з бордером Brand/Primary. Коли ж з'являється компонент «Tabs» для бібліотеки, цей бордер у ньому має стати семантичним токеном, наприклад border-active. У файлі, який потрапляє в бібліотеку, стилі приводять до семантики.

An illustration that explains if we should support styles for ideation and variables for production components within the design systems. The two design stages are the ideation stage (using a style) and the production stage (using a variable).
Can we support styles for ideation, and variables for production components within our systems?

Автор окремо застерігає від надмірної деталізації, на кшталт токенів рівня header-nav-item-active. Супер-специфічні токени варто розглядати як опціональний рівень — вони множать кількість сутностей для підтримки.

3. Спільнота та «хаб — споук» модель

Уріач підкреслює: дизайн-система не працює без внутрішніх адвокатів у product, design і engineering. Інакше центральна команда стає вузьким горлом — бізнес росте швидше, ніж вони встигають відповідати на запити.

IBM, за словами Робіна Кеннона, використовує «hub and spoke» модель: центральна команда (hub) розвиває принципи й базу, а продукт-команди (spokes) отримують повноваження розширювати й підтримувати рішення на місцях.

Практичні формати спільноти:

  • спільний Slack/Teams-канал для всіх, хто працює з системою;
  • регулярні «open house» сесії, демо чи навчальні мітинги;
  • офісні години або щомісячні Q&A для дизайнерів, розробників, продактів.

Уріач посилається на приклад Zalando, де систему підтримують порталом, навчанням та культурою «відкритого дому». Аналогічно команда Gov UK проводить публічні заходи — від воркшопів з доступності до повноцінних «design system days».

4. (Over) communication — краще забагато, ніж замало

Щоб adoption не «просідає», команда системи має постійно тримати інших у курсі. Автор пропонує ввести ритм оновлень, наприклад прив'язаний до спринтів:

  • в останній день спринту — changelog / release notes;
  • на початку спринту — «What’s next?» з планами робіт;
  • в середині — шаринг цікавих ресурсів для натхнення;
  • щокварталу — «small wins»;
  • раз на півроку — результати опитувань про зрілість дизайну;
  • оновлення щодо найму — по факту.

An illustration that shows what a sprint-long plan would look like for a design systems team’s community. Sprint days 1-10 are displayed on a timeline. At 1) there is ‘What’s next?’, at 5) there is ‘Resource sharing’, and at 10) there is ‘Changelog’.
What would a sprint-long plan look like for a design systems team’s community?

Ці повідомлення можуть супроводжуватися конкретними release notes в чаті: що додали, що перейменували, які зміни потрібно «Accept library updates» у Figma.

Screenshot of release notes, white box on a blue background, black font. The text in it says at the top: 17 September / v2.3, and then the notes follow: Added hover and pressed interactions to all atomic form components; The Growl component has been renamed to Toast; Moved styles from the main component file into a dedicated ‘Styles’ file; For everyone working on v2, don’t forget to accept these changes into your design files.
What could release notes look like as a message within your chat software?

Окремий пласт комунікації — всередині самого Figma-файлу:

  • детальні позначки у version history (що змінено, ким, навіщо);
  • змістовні описи гілок (branches) при branch-based workflow;
  • використання branch-ів для дрібних фіксів, а великі релізи — в нових файлах, щоб паралельно жити v1 і v2.

A screenshot that shows branches for component updates. The example shows ‘Version history’ at the top, and below, details about ‘Current version’ are shown.
Branches for component updates promote a much richer timestamp on work that has been completed.

Як інструмент контролю якості Уріач рекомендує плагін Design Lint. З кастомними правилами він дає змогу:

  • знайти відсутні стилі;
  • позначити некоректне використання color styles;
  • виявити компоненти, яких немає в бібліотеці або без опису.

Indexable — як зробити компоненти знахідними

1. Розрив «гарної бібліотеки» й реального використання

Автор описує типовий сценарій: команда випускає базову бібліотеку (inputs, navigation, alerts), а далі помічає, що продуктові флоу створюють «обхідними шляхами» — без системи. Основні причини:

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

Висновок Уріача: індексація — це не тільки структура бібліотеки, а й окрема комунікаційна робота.

2. Публічний канал про стан компонентів

У Slack/Teams доцільно мати окремий канал «design-system-components» (назва умовна), де команда системи регулярно відповідає на п'ять простих запитань:

  • що зараз у роботі;
  • які оновлення очікуються найближчим часом;
  • хто за що відповідає;
  • як інші можуть допомогти чи законтриб'ютити;
  • які є блокери.

Так формується «жива індексація» — не тільки того, що вже в бібліотеці, а й того, що скоро з'явиться.

3. Іменування для пошуку: вербозність замість мінімалізму

Уріач пропонує орієнтуватися на принцип: «discoverability over complexity». Часто краще більш довга, але точна назва, ніж лаконічна, в яку кожен вкладає своє.

Він розбирає приклад меню з діями «Import / Export / Share»:

A screenshot of a dropdown menu design, with the menu items in it being: ‘Import’, ‘Export’, and ‘Share’.
Is it a dropdown?

Без контексту це може бути dropdown, popover, modal, action list — команда не домовиться. Але в інтерфейсі це меню прив'язане до триточкового контролу над результатами пошуку:

A screenshot of the same dropdown menu, with the menu items in it being: ‘Import’, ‘Export’, and ‘Share’, but now the dropdown menu is connected to a three-dots icon (similar to the popular ‘hamburger menu icon’ interaction), and to the left of it there is a search field with the words ‘Website variables’ displayed in it as the value.
Is it still a dropdown?

У такому контексті автор пропонує називати компонент search actions або іншим контекстним терміном (action list, search dropdown, filter menu тощо) — не намагаючись одразу зробити «універсальну» назву.

Щоб не втрачати альтернативи, в поле опису компоненту можна дописати інші можливі назви як аліаси, щоб різні люди знаходили його своїми словами.

The component description field again is somewhere we can add alias names for discoverability for the previously shown dropdown component, now named “search actions”.
The component description field again is the place where we can add alias names for discoverability.

Logical — компоненти, якими реально зручно користуватися

1. Проблема «prop soup»

Figma дає дуже багато можливостей через component properties. Уріач зауважує, що часто системні дизайнери оптимізують під створення компонента (усі можливі варіанти в одному сеті), а не під використання. У результаті:

  • панель властивостей перетворюється на «prop soup»;
  • споживачі компонентів не розуміють, з чого почати й що можна міняти;
  • з'являються однакові питання на кшталт «чому navbar з 4 табами, якщо в проді 3?».

An illustration that shows a component that has too many properties available in the component properties panel.
Too many properties = prop soup!

2. Розділення перезавантажених компонентів

У прикладі з кнопкою один «універсальний» компонент містить:

  • 4 intentions: primary, secondary, error, warning;
  • 2 type: fill / stroke;
  • 3 size: large, medium, small;
  • 4 state: default, hover, focus, inactive.

A complex table that shows one component variant button which has four intentions (primary, secondary, error, warning), two types (fill/stroke), three sizes (large, medium, small, and four states (default, hover, focus, inactive).
One component variant button with four intentions, two types, three sizes, and four states. With so many customization options, is there trouble ahead?

Автор ставить запитання: чи справді дизайнеру потрібно в одному місці перемикатися між primary та warning? У реальному флоу це дві різні задачі, тому логічніше винести їх у окремі компоненти-варіанти:

  • Button / Primary;
  • Button / Secondary;
  • Button / Error;
  • Button / Warning.

An illustration that shows a series of separate button variant components, split by type: primary, secondary, error, warning. Here, we no longer need one component that would encompass all the button variants (sub-divided into intentions, types, sizes, and states), like it was shown in the previous illustration.
A series of four separate button variant components, split by each type: primary, secondary, error, warning.

На думку автора, це дає дві переваги:

  • список Assets читається простіше — ключові варіанти видно візуально;
  • користувач компонента приймає на один вибір менше — не потрібно згадувати, який intention включити.

Так втрачається ідеальний паритет з кодом (де все може бути однією абстрактною кнопкою), але Уріач вважає це прийнятним компромісом: розробники отримують документацію з відповідністю варіантів, а дизайнери — логічні для них компоненти.

3. Auto layout як обов'язковий інструмент

Ще одна практична порада — «all in» на auto layout у компонентах:

  • знімає потребу «на око» виставляти відступи;
  • дозволяє нетехнічним ролям (копірайтери, продакти) спокійно правити текст у компонентах;
  • через змінні padding/gap усередині можна стандартизувати spacing.

Автор вважає, що суцільне використання auto layout створює для команди «рейки» для відступів і вирівнювання, що напряму підсилює консистентність.

Specific — навмисна конкретність замість гіпер-універсальності

1. Чому «search» і «combobox» мають жити окремо

Останній акцент Уріача — на специфічності назв і компонентів. Він порівнює термінологію великих систем:

  • Apple HIG — «search field»;
  • Material Design — «search bar»;
  • Fluent 2 — «combobox» з typeahead-пошуком, без окремого search-компонента.

Для системної команди ці відмінності логічні, але для більшості дизайнерів і розробників — ні. Тому коли все загортається в один універсальний компонент типу «Input / Search / Combobox», з властивістю «mode», виникають зайві питання: що саме я шукаю в Assets, як це потім виявиться в коді, чи можу я використати цей «режим» тут?

Автор пропонує відокремлювати сутності:

  • Search як самостійний компонент;
  • Combobox — інший компонент.

An illustration that shows how a single component is then split into two separate components: one of the components is labeled ‘Search’ and the other one ‘Combobox’.
A single search variant component split into two main components, one for each distinct type: Search and Combobox.

Це означає певну «неефективність» у короткостроковій перспективі (два компоненти, більше підтримки), але різко скорочує час пошуку й помилкові використання. На думку Уріача, справжню ефективність дизайн-система здобуває поступово, а не в перший день — тому дозволити собі таку неефективність на старті цілком раціонально.

Що можна взяти в роботу вже зараз

  • Додати до ключових Figma-компонентів і стилів описи з аліасами назв (включно з кодовими).
  • Розвести «швидкі» стилі для ескізів і семантичні токени для продакшен-компонентів (особливо в великих командах).
  • Запустити публічний канал або регулярні сесії навколо дизайн-системи, де центральна команда ділиться планами, релізами й запрошує до контриб'юцій.
  • Переглянути найбільш «монолітні» Figma-компоненти та розділити їх за реальними сценаріями використання, навіть якщо це збільшить їх кількість.
  • Стандартизувати використання auto layout та spacing-variables у всіх базових компонентах.
  • Для «супер-широких» компонентів (на кшталт «універсального поля вводу») розглянути розділення на конкретні компоненти: search, combobox, filter тощо.

Ці кроки безпосередньо підтримують ідею Луїса Уріача: компоненти дизайн-системи мають бути створені насамперед для споживання командами, а не як максимально «чиста» абстракція заради самої абстракції.

Джерело: Luis Ouriach – Smashing Magazine. Дата оригіналу: 2023-12-18.

Пошук

Закрити