Це переклад статті Jérôme Benoit
Система дизайну Oxygen doctolibs існує вже понад три роки і стає все більш і більш надійною. Три роки додавання нових компонентів, нових процесів, змін, через нові можливості Figma (як авторозмітка), оновлення або перероблення компонентів, дрейфів (розбіжностей між компонентом дизайну і компонентом розробки)...
Все це призвело до того, що бібліотека Figma (раніше називалася 💠Core components) була ближче до Франкенштейна, ніж до стрункої та вишуканої бібліотеки, як нам хотілося б.
Паралельно ми регулярно отримували негативні відгуки від Product Designers, зокрема, про те, що файли Figma дуже важкі, а отже, над ними дуууже повільно і дратівливо працювати. Це дуже важливо, якщо врахувати, що Product Designer працює над Figma щонайменше півдня.
Щодо системи дизайну, ми відкрили для себе:
Багато властивостей компонентів не використовувалися або, що ще гірше, оминалися проектувальниками, а деякі з них говорили нам, що компоненти були надмірно спроектовані.
Не було офіційної номенклатури властивостей, тобто від компонента до компонента схожа властивість мала різну назву.
Ми також боролися з тим, що ми називаємо "Компоненти-привиди", тобто екземплярами без вихідних компонентів.
Ми зрозуміли, що настав час зробити велике прибирання і створити другу версію нашої системи дизайну.
Жахлива правда
Для вирішення більш важливої теми (і, очевидно, блокуючої) - ваги файлів - ми почали використовувати плагін Layer Counter. Цей плагін був дуже корисним для зважування наших компонентів, а потім для вимірювання нашого прогресу та впливу.
А потім ми відкрили для себе жахливу правду: файли були важкими, тому що наші компоненти не були важкими, вони були ВЕЛИЧЕЗНИМИ! І, чесно кажучи, ми були шоковані!
Візьмемо для прикладу компонент 💠Pill. Цей компонент має багато варіантів, кілька смислових колірних тем, включає вкладені компоненти з Системи дизайну (Кнопки-піктограми, Аватари, Іконки, Завантажувач, Значки...) і має кілька доступних розмірів, типів і т.д.
А ця 💠Pill використовувала.... 8 684 шари 😱.
NB: залежно від вибору (компонент-джерело або екземпляр) результат лічильника шарів може дещо відрізнятися.
Питання стояло так:
Як створити легкі та ресурсоефективні компоненти, максимізуючи ефективність без шкоди для якості?
Після низки ідей та досліджень ми вирішили зосередитися на 3 напрямках:
1. Видаліть всі непотрібні вкладені компоненти і створіть приватні вкладені компоненти
У варіанті використання 💠Pill (і у всіх наших компонентах сімейства зворотного зв'язку) семантичні іконки не повинні змінюватися, тому ми видалили компонент 💠Icon, що використовується як вкладений, на користь іконки SVG з нашої бібліотеки іконок. Це нам допомогло:
- Надати гнучкість дизайнерам продукту, якої не було в компоненті розробки (а потім уникнути непорозумінь при передачі та невідповідної кастомізації у виробництві).
- Видалити величезне навантаження шарів.
- Видалити відображення непотрібних властивостей на правій бічній панелі, що автоматично спростило панель властивостей та її використання.
2. Спрощення структури
Паралельно ми маємо бібліотеку під назвою 🧰 Helper components, що містить компоненти, які постійно використовуються дизайнерами продуктів, але не враховуються в Системі проектування. Зокрема, ця бібліотека містить зовнішні набори інтерфейсу користувача (клавіатури ОС, сповіщення...), курсори, саморобні елементи для управління організацією файлів (картки, обкладинки проектів...) тощо. У 💠Pill використовувався один з цих допоміжних компонентів для керування падінгами з булевими властивостями - 🧰 Grid Spacer. Ми використовували їх у минулому, щоб мати керування падінгами, а точніше, щоб мати можливість змінювати розмір компонента з булевим значенням без необхідності вводити новий варіант. Ми прибрали 🧰 Grid Spacers і створили більш розумну структуру компонента з авторозмітками.
Для компонентів, які можуть мати невизначену кількість значень, таких як 💠випадаючий список або 💠меню, ми пропонували 10 рядків або елементів за замовчуванням. Це означає, що якщо дизайнеру потрібні лише 2 з них, то 8 інших будуть прихованими шарами, додаючи непотрібну вагу. Для цього конкретного випадку використання і завдяки Mr Biscuit ми створили допоміжні компоненти під назвою 🧰 Swappers. Таким чином, наші дизайнери продуктів можуть вибрати необхідну кількість рядків або елементів, з вертикальним або горизонтальним авторозміщенням.
3. Розділіть компонент
Для компонента 💠Alert раніше ми мали 1 компонент для 3 сімейств варіантів:
- Банер (на всю ширину)
- Листівка (стиль листівки)
- Сповіщення з підказкою (для низького акценту)
Спочатку ми думали, що простіше імпортувати один компонент і змінювати властивості залежно від потреб за допомогою панелі властивостей (що більш-менш вірно). Але такий підхід означає, що ваш компонент містить багато непотрібних невикористовуваних шарів при кожному імпорті з файлу, і при кожному використанні дизайнер додає багато ваги, якої можна було б уникнути.
Тут наведено приклад з окремим компонентом, але уявіть собі комірку таблиці, яка використовується десятки разів у таблиці, і ця таблиця використовується в десятках макетів... файл досить швидко вийде за межі.
На завершення, ми значно зменшили вагу компонентів, пропонуючи ті ж самі можливості, що й раніше, і прибравши зайву кастомізацію, яка не була дозволена на стороні коду.
У більш глобальному масштабі, наші 64 компоненти представляли понад 130 000 шарів до, порівняно з 21 700 після. Це означає, що 83% шарів було видалено.
Відтоді ми не отримували жодних скарг від дизайнерів продуктів, а працювати з файлами стало набагато швидше.
Стандартизація властивостей
Ви знаєте, як це буває: 3 роки створення системи дизайну, з безліччю учасників, зі змінами процесів на стороні розробників і дизайнерів... Спочатку все було скоріше інтуїтивним, ніж структурованим, що призвело до великої кількості невідповідностей у властивостях і використанні. Саме тому наші компоненти не дотримувалися жодної номенклатури, з чіткими та ефективними формулюваннями, що полегшують розуміння компонентів.
Наприклад:
- Властивості тексту можуть бути такими: ✏️ label, description - ✏️ label, ✏️ title
- Колір теми може бути: UI style, Color, Label color
Ми скористалися можливістю переробити компоненти, щоб створити список властивостей, пов'язаний з тим, який використовується на стороні коду.
Основні моменти такі:
- Текстові властивості: завжди відображаються зі смайликом
- Булеві властивості або варіанти: завжди відмінюються як у коді, наприклад, has Left asset, has Title, is Closable, is Disabled
- Більше стандартних варіантів: прості слова, такі як позиція (position), розмір (size), стан (state), стиль (style), тип (type)
Ми також намагаємося максимально зберегти однаковий порядок властивостей для всіх компонентів.
У Figma величезна перевага вирівнювання всіх компонентів разом полягає в тому, що коли ви замінюєте компонент на інший, перевизначення компонента залишаються. Побічним ефектом для нас, як супровідників системи проектування, є те, що дуже просто вибирати назви та типи властивостей.
Зробіть компоненти простими у використанні
Раніше всі вкладені компоненти були офіційними компонентами (наприклад, 💠Пункт списку використовував офіційний 💠Аватар). У цьому компоненті ми перестали використовувати офіційні вкладені компоненти, тільки приватні вкладені з виділеною номенклатурою. Таким чином:
- Ми показуємо лише ті властивості, які дійсно використовуються, крайні випадки більше не відображаються, і тоді стає менше властивостей.
- За замовчуванням ми показували всі властивості на правій панелі. Тепер для кожного компонента ми перевіряємо, які з них слід показувати, а які ні.
- Спрощення дощок. Раніше ми поміщали вихідний компонент у фрейм, щоб мати чисту і акуратну бібліотеку. Справа в тому, що при імпорті компонента цей фрейм викликав зайвий клік.
Таким чином, ми полегшуємо повсякденне життя користувачів дизайн системи і можемо мати більш раціональний вплив.
Таким чином, ми полегшуємо повсякденне життя користувачів Design System і можемо мати більш раціональний вплив. Наприклад, еволюція 💠Dropdown (випадаючого списку) не обов'язково потрібна на 💠Combobox (Комбобоксі) (за допомогою 💠Dropdown). І останнє, але не менш важливе: ми менше турбуємо дизайнерів нескінченними оновленнями.
Боротьба з компонентами-примарами
Останнім кроком, і не найпростішим, була публікація нової бібліотеки. Ми визначили два ризики:
- Видалення старої бібліотеки може призвести до створення так званих компонентів-привидів, тобто компонентів без вихідного коду, що зазвичай означає, що вихідний компонент було видалено (той, що має кнопку "Відновити компонент", або той, що вказує на бібліотеку, але не на основний компонент).
- Створення великої кількості руйнівних змін. Це означає, що якщо дизайнер замінить компонент v1 на v2, оскільки ми змінили всю структуру та властивості, всі перевизначення будуть скинуті.
Тож ми вирішили:
- Не публікувати бібліотеку v1, а лише видалити доступ до неї, і позначити їх ☠️ [V1 DO NOT USE] у назві. Таким чином дизайнери можуть легко відрізнити v1 від v2, копіювати, вставляти та використовувати компоненти v1, але не зможуть їх імпортувати. А ми, зі свого боку, все ще можемо виконувати деякі оновлення бібліотеки.
- Опублікувати бібліотеку v2 з компонентами, що мають ту саму номенклатуру
Через місяць після релізу використання компонентів v1 значно зменшилося, і ми плануємо остаточно видалити їх протягом найближчих тижнів.
Функція версійності та розгалуження компонентів
Побічна тема, але важлива, ми вирішили використовувати функцію розгалуження для будь-якого оновлення компонента, і створити підкомпоненти версій (позначені в їхньому описі), дотримуючись такої номенклатури: X.Y.Z, де:
- X [Major] означає версію, в якій ми зробимо велике оновлення, яке вплине на всю структуру компонентів, що передбачає порушення змін з перевизначенням втрат екземплярів.
- Y [Minor] означає версію, в якій ми покращуємо компонент (додаємо нові функції або виправляємо незначні помилки), що не впливає на перевизначення поточних екземплярів.
- Z [Patch] означає версію, в якій ми оновлюємо компонент з нульовим впливом на файли дизайнерів.
Висновок
Загалом, ми підрахували, що для вирішення цієї проблеми потрібно 3 місяці роботи на повну ставку. Це здається величезною інвестицією, але виходячи з того, скільки часу дизайнери продуктів витрачають на Figma, фінансова економія завдяки тому, що не потрібно чекати на завантаження файлів Figma, може бути вражаючою!
Саме тому, відтепер:
- Ми завжди оцінюємо вплив наших компонентів завдяки лічильнику шарів
- У нас є процес перевірки використовуваних властивостей і забезпечення їх відповідності нашому глосарію
- Ми більше знаємо про випуск нових функцій або оновлень компонентів. Таким чином, ми уникаємо пастки створення компонентів-привидів або внесення руйнівних змін в існуючі екземпляри у файли дизайнерів.
Щиро дякуємо Майклу Бланкону Тарді за його величезний внесок у те, щоб зробити Oxygen найкращою у своєму класі системою проектування, яку добре засвоїли наші дизайнери та розробники.
Також дякую моїм дорогим колегам по команді UX-райтерів за коректуру: Ханні Ширан та Майку Віннінгтону.
Дякую Lyne Dang Recalt за чудову ілюстрацію для обкладинки (тепер я відчуваю себе художником)
Топ коментарі (0)