Створення життєздатної дизайн-системи будь-якого масштабу – складне завдання. Створення дизайн-системи для більш ніж 150 продуктових команд, 200 дизайнерів та 800 розробників, що охоплює 4 різні платформи? Це справжній виклик!
Коли ми працюємо над дизайн-системою такого масштабу, виникає безліч запитань:
- Як зробити її надійною та масштабованою для кількох тем та брендів?
- Як зберегти узгодженість компонентів на різних платформах?
- Як ми можемо забезпечити цілісність та послідовність досвіду на всіх платформах?
У цій статті ми докладно розглянемо, як влаштовано мультиплатформну дизайн-систему Booking.com, і як ми підтримуємо її за допомогою ретельно продуманого процесу розробки.
Трохи про команду
Місія Booking.com – зробити так, щоб кожен міг пізнавати світ. Для команди це означає: максимально спростити роботу дизайнерів та розробників.
Ключ до досягнення цієї мети – дизайн-система. Ми надаємо посібники, бібліотеки компонентів, технічну документацію, інструменти та навчання (все це складові надійної дизайн-системи) для того, щоб продуктові команди могли більш ефективно створювати якісні продукти.
Фундамент
У нас сотні дизайнерів та розробників, які працюють разом над різними продуктами для різних платформ. Це робить створення цілісного досвіду особливо складним завданням. Нам просто необхідний міцний фундамент, що масштабується.
Мова дизайну
В результаті більш ніж 25 років експериментів, ризикованих кроків та зростання наш продукт зазнав значних змін. Ми використовували цю еволюцію, поєднали її зі стратегічним баченням та отримали те, що ми називаємо мовою дизайну. Це основа як для стандартів нашого бренду, так і дизайн-системи.
Мова дизайну включає рекомендації щодо використання кольору, типографіки, лейауту, іконок, фотографій, ілюстрацій, а також голосу та тону.
Неважливо, чи намагаєтеся ви забронювати готель через нашу програму, відкриваєте електронний лист з підтвердженням оренди автомобіля або переглядаєте одну з наших історій в Instagram, ви відразу розумієте, що маєте справу з Booking.com.
Як же впровадити мову дизайну у великий продукт із такою багатою історією? Створивши загальний базовий шар у дизайні та коді за допомогою наступних елементів:
Дизайн-токени
Дизайн-токени застосовуються для кольорів, типографіки, тіней, округлення кутів, інтервалів та сіток. Це будівельні блоки, які допомагають нам створювати продукти, які сприймаються як частина однієї родини.
Функціональні токени передають певний семантичний контекст. У кольорів є семантичні групи, такі як дія, конструктивна, деструктивна і т.д. Але вони також належать до певних функціональних груп – передній план, тло, обведення тощо.
Дизайн-токени дозволяють підтримувати кілька тем та автоматичний темний режим. Їх можна налаштовувати за необхідності. Продуктовим командам не потрібно вносити зміни вручну, що знижує ризик помилок.
Design API
Ми зібрали стилі в єдину бібліотеку, щоб зробити їх доступними всім дизайнерам. А оскільки наші продукти підтримують темний режим, ми маємо ще одну бібліотеку, яка повністю складається з відповідних токенів. Три наші фірмові теми зараз включають елементи темного режиму, і ми плануємо додати ще кілька в майбутньому.
Усього ми створили 6 бібліотек з більш ніж 600 стилями. Підтримувати цю потужну систему вручну дуже складно. Тому разом із нашими розробниками ми створили єдине джерело інформації для всіх наших тем, режимів та токенів: Design API.
Design API зберігає базові дані, історію змін та перетворює загальні значення в токени для конкретних платформ – iOS, Android, Vue, React та Figma.
Щоб автоматично переносити дані з Design API Figma, ми розробили внутрішній плагін. Він безпечно отримує всю інформацію про стиль (включаючи метадані з описом). Це заощаджує нам години роботи, запобігає безлічі помилок і візуальних невідповідностей. І ми завжди можемо бути впевнені, що наш дизайн повністю відповідає коду.
Плагін Themer
Потім ми створили версію плагіна для всіх дизайнерів Booking.com, щоб їм було зручніше та простіше працювати з темами та режимами:
- Дизайнери можуть перемикати темний режим на рівні теми
- Підтримка різних системних шрифтів залежно від вибраної платформи (SF Pro для iOS та Roboto для Android)
- Додаткова тема із заокругленнями кутів, оскільки Figma поки не дозволяє створювати дизайн-токени для заокруглень.
Наш плагін був натхненний плагіном Themer від Тома. Завдяки такій структурі API та інструментарію дизайнери можуть використовувати лише одну бібліотеку стилів та одну бібліотеку компонентів для всіх продуктів та тем, а також для всіх підтримуваних платформ.
Графіка
Крім дизайн-токенів, у нас також є графічні елементи, такі як іконки та ілюстрації, які мають виглядати узгоджено на різних платформах.
Історично наші іконки використовувалися по-різному на різних платформах та мали непослідовні стилі та формати: шрифти, вбудовані SVG, PDF, спрайти – у нас було все.
Як і у випадку з Design API, ми спільно з розробниками створили єдиний ресурс для всієї нашої графіки – Asset Service. Він зберігає всі іконки, історію змін і застосовується для всіх платформ, включаючи Figma! І, як і у випадку з токенами, ми створили плагін, який витягує іконки з Asset Service для створення та оновлення нашої бібліотеки.
Мультиплатформна технологія: як ми це робимо
Заклавши фундамент, ми тепер можемо зайнятися підтримкою системи. Як наша команда забезпечує узгодженість компонентів на різних платформах, постійно вносячи зміни? Коротка відповідь: добре організований процес.
Раніше ми використовували бібліотеки та компоненти, які були розроблені спільнотою кожної платформи без синхронізації один з одним. Це спричинило неузгодженість між платформами.
Ми знали, що маємо організувати процес, у рамках якого дизайнери та розробники працюватимуть разом і паралельно. Ці фахівці найчастіше діють ізольовано, оскільки займаються абсолютно різними завданнями. Важливо подолати цей розрив, щоб забезпечити кроссплатформенну узгодженість. Щоразу, коли ми починаємо працювати над функцією, хай то новий компонент або оновлення наявного компонента, ми дотримуємося одного і того ж алгоритму:
- Оцінка дизайну 💡
- Передача розробникам 📙
- Технічна оцінка 🔎
- Запуск 🤝
- Реалізація 💻🤖📱
- Перевірка дизайну та доступності ✅
- Реліз та поширення 📣
1. Оцінка дизайну 💡
Перший етап – оцінка перед початком роботи. Тут головна роль приділяється дизайнерам.
A. Оцінка вимог
Зміни повинні відповідати цілям та потребам користувачів. Ми починаємо з того, що просимо дизайнерів продукту сформулювати пропозицію з докладним описом вимог: постановка проблеми, чому поточне рішення не працює, запропоноване рішення, приклади використання продукту тощо.
B. Аудит поточного рішення
Після оцінки запиту ми проводимо аудит поточного стану компонента на всіх платформах та намагаємося виявити, чи є десь таке рішення, чи щось схоже на нього, а також будь-які інші невідповідності, які нам необхідно врахувати.
Якщо під час аудиту ми бачимо якісь додаткові невідповідності (наприклад, у цьому випадку іконка підтримується скрізь, окрім Інтернету), ми обговорюємо та домовляємося, чи залишити їх на потім, чи внести зміни одразу.
C. Дизайн-специфікації
Дизайнери представляють необхідні зміни у встановленій формі. Тут ми визначаємо всі специфікації: анатомію, варіанти, а також поведінку компонентів, якщо необхідно.
Ми працюємо з дизайнерами продукту та зацікавленими сторонами, щоб отримати зворотний зв'язок про зміни, зібрати приклади використання та інсайти.
На цьому етапі ми також консультуємося з командою забезпечення доступності Booking.com. Вони оцінюють, наскільки наше рішення відповідає вимогам доступності, таким як рівень контрастності, мітки aria для допоміжних технологій тощо.
2. Передача розробникам
Тепер ми готові поділитись своїм рішенням з нашими розробниками. Вони подивляться на нього та сформулюють свої запитання чи коментарі. Потім ми зустрінемося та ретельно обговоримо всі можливі варіанти, анатомію нового компонента та його технічні характеристики.
3. Технічна оцінка
Коли розробники мають всю необхідну інформацію, вони приступають до технічної оцінки.
A. Обговорення спірних випадків
Ми ще раз обговорюємо нове рішення та приходимо до консенсусу щодо дизайну та поведінки компонента залежно від можливостей кожної платформи. Ми також усуваємо неясності та розглядаємо спірні випадки, які потребують подальшого вивчення.
Іноді нам доводиться повертатися на крок назад, щоб привести своє рішення у відповідність до технічних вимог.
B. Визначення властивостей компонентів ✨
Під час технічної оцінки розробники аналізують властивості компонентів. Властивість компонента – це атрибут, що представляє функцію/характеристику компонента, яка може бути налаштована командою розробників. Подібно до того, як ми зберігаємо базові токени в нашому API, ми також зберігаємо властивості компонентів.
Властивості компонентів не залежать від платформи, тобто компоненти мають однакові характеристики, навіть якщо вони виглядають по-різному.
У iOS та Android компоненти можуть виглядати по-різному, оскільки ми намагаємося дотримуватися дизайн-стандартів нативних програм, але в коді вони все одно мають одні й ті самі властивості. Саме це робить властивості такими потужними. Це ключ до багатоплатформної розробки.
Після того, як властивості визначені, розробник створює merge request (запит на злиття) із запропонованими змінами. Іноді в результаті щось "ламається", і тоді ми повідомляємо про це розробникам.
4. Запуск
Ми проводимо організаційну нараду, щоб розпочати реалізацію. Дизайнери та розробники аналізують рішення та приймають зміни.
Ми встановлюємо терміни реалізації та визначаємо дні релізу. Наша мета – впроваджувати всі зміни паралельно, щоб зберегти узгодженість компонентів на різних платформах.
5. Реалізація
Тепер, коли всі зміни узгоджені, ми можемо розпочати їх впровадження на всіх платформах.
A. Розробка
Розробники реалізують зміни відповідно до нових специфікацій та вимог. У нас є своя внутрішня платформа для зберігання компонентів, а також властивостей, що налаштовується.
B. Документація
У процесі реалізації розробники також оновлюють технічну документацію з урахуванням внесених змін.
Наша технічна документація включає такі пункти, як композиція, кращі практики, вимоги до доступності і пояснення різних властивостей.
C. Синхронізація з компонентом Figma
Тим часом дизайнери створюють гілку в основній бібліотеці дизайн-системи та вносять зміни в цю гілку.
Саме тут ми синхронізуємо властивості та варіанти Figma із властивостями, які ми визначили раніше.
D. Оновлення посібника з дизайну
Дизайнери також переглядають рекомендації щодо проєктування компонента. У нашому посібнику ми відображаємо властивості, поведінку, що налаштовуються, а також описуємо допустимі та неприпустимі варіанти використання.
6. Перевірка дизайну та доступності ✅
Коли реалізація завершена, дизайнери аналізують компонент, що вийшов. Ми тестуємо його для кожної платформи у спеціальних додатках-пісочницях.
Ми перевіряємо різні характеристики та поведінку на всіх платформах та вносимо необхідні коригування.
7. Реліз та поширення
Коли все готово, ми публікуємо нову версію бібліотеки на кожній платформі разом із журналом змін релізу. У Figma ми випускаємо релізи щотижня, щоб краще керувати оновленнями.
Коли ми плануємо внести суттєві зміни до якогось Figma-компонента, ми відзначаємо це в журналі змін, щоб забезпечити більшу передбачуваність.
Висновок
На те, щоб побудувати та вдосконалити мультиплатформний процес розробки, знадобився не один день. Ми постійно покращуємо та розвиваємо його, щоб він залишався ефективним для дизайнерів, розробників та UX-фахівців.
- Більш ефективна дизайн-система: API, дизайн-токени та Asset Service – основа нашої дизайн-системи, і саме завдяки їм ми можемо масштабувати її на безліч брендів та платформ.
- Підтримка узгодженості: Чітко побудований процес, до якого від початку залучені розробники, забезпечує узгодженість компонентів різних платформ.
- Цілісний досвід: Ця узгодженість дозволяє продуктовим командам створювати цілісний досвід взаємодії на всіх платформах.
Тому наступного разу, коли ви створюватимете або дороблятимете дизайн-систему, що охоплює більше однієї платформи, подумайте, як ви можете застосувати деякі з цих принципів у своїй роботі.
Тут ви знайдете файл із чекістами для кожного етапу процесу.
