Як Booking дизайн-систему перебудували

Сотні розробників і дизайнерів мали ефективно працювати разом. Але скільки людей, стільки й думок, тому без чіткої системи це було важко. Розповідаємо проблема та рішення команди:

1. Непослідовний вигляд і поведінка компонентів на різних платформах

У веб, iOS, Android компоненти виглядали і функціонували по-різному, що створювало плутанину для користувачів і додавало роботи командам.

Рішення:

• Визначили основні принципи та ядро дизайн-системи, яке охоплює всі платформи.
• Для кожної платформи створили окремі стилістичні шари, щоб врахувати їхні унікальні вимоги — наприклад, специфічні патерни поведінки на iOS чи Android.

2. Зайва робота

Дизайнери та розробники витрачали час на створення та повторне налаштування одних і тих самих компонентів для різних платформ.

Рішення:

• Створили централізовану бібліотеку компонентів у Figma та Storybook.
• Впровадили систему спільного використання компонентів, що дозволяє дизайнерам і розробникам працювати з одними й тими ж елементами.
• Налаштували автоматичну синхронізацію між дизайном і кодом.

3. Відсутність стандартів роботи з компонентами

Різні команди використовували різні підходи до створення компонентів, що ускладнювало інтеграцію та оновлення.

Рішення:

• Розробили чіткі правила для створення компонентів, що охоплюють як візуальну, так і функціональну частину.
• Впровадили перевірку компонентів через peer review, де команди оцінюють та узгоджують кожен новий елемент перед додаванням до бібліотеки.

4. Неактуальна документація

Частина документації була застарілою або неповною, що викликало труднощі у використанні дизайн-системи.

Рішення:

• Створили централізовану та інтерактивну документацію у Confluence.
• Включили приклади коду, інтерактивні компоненти та рекомендації щодо їх використання.
• Регулярно оновлювали документацію через спільний Slack-канал, де всі команди могли залишати коментарі та пропозиції.

5. Відсутність механізму зворотного зв’язку

Рішення приймалися без залучення кінцевих користувачів дизайн-системи — дизайнерів і розробників.

Рішення:

• Організували регулярні воркшопи з командами, щоб обговорювати проблеми та пропозиції.
• Впровадили механізм для швидкого подання зворотного зв’язку через інтеграцію у Figma та Slack.

6. Складність масштабування

Додавання нових функцій та адаптація під нові продукти вимагали великих зусиль через розрізненість компонентів.

Рішення:

• Встановили модульну структуру дизайн-системи, де компоненти легко адаптуються або доповнюються без впливу на інші частини.
• Побудували архітектуру за принципом Atomic Design, що дозволяє комбінувати дрібні елементи для створення складних інтерфейсів.

Задокументований процес від команди Booking доступний у Figma.

Будувати власні дизайн системи кличемо на воркшоп Design Systems.

Завдання із серії «Підтримка» 💙

Вам запропонували взятися за класний дизайн проєкту, але не надто великий досвід і надокучливий синдром самозванця зупиняють вас.

Питання: Як будете «домовлятися» з останнім, щоб все ж долучитися до проєкту?

Від Олі Алтухової — кураторки курсу Web Design Junior, дизайнерки продукту в airSlate.

Як взятися за нове та побороти синдром самозванця?

Дизайнери переносять ідеї від бізнесу до користувачів. Світ швидко рухається, створюються нові бізнеси на незнайомі нам теми — тож ми ніколи не будемо розбиратися в усьому. Тому на початку проєкту страшно входити в незнайому для нас тематику — це вихід з комфортної зони.

Уявіть, що вам 1 рік і ви не спробували вчитись ходити, тому що страшно впасти. А тепер уявіть, що ви не спробували попрацювати з проєктом, для якого вважаєте себе «недосвідченим». Не спробувавши — не буде зростання.

Але для кожного «нового» треба час — плануйте терміни із запасом на рисьорч. Також варто знайти людину, яка шарить в цій темі та поговорити з нею. Оцініть проєкт, а потім додайте ще 1.5x годин на «дорозібратись». І все у вас вийде!

Від Олі Алтухової — кураторки курсу Web Design Junior, дизайнерки продукту в airSlate.

Менше часу на рутину, більше — на творчі завдання

Знайшли плагін Handy Components від Арсена Колиби — нашого куратора курсу Product Design, продуктового дизайнера у Wix. Нещодавно кількість користувачів перетнула 100 000 тисяч.

Плагін автоматично підлаштовує UI-компоненти під стиль вашого дизайну. Він magically підбирає match — визначає, як саме мають виглядати компоненти у вашому файлі, враховуючи типографіку, кольори, радіуси кутів та інші параметри.

Що це дає?

1. Готові компоненти, які ідеально вписуються у ваш дизайн.
2. Економію часу на налаштування стилів вручну.
3. Узгодженість і стильність у будь-якому проєкті без зайвих зусиль.

• Знайомтеся за посиланням

Завдання: зробити поганий дизайн
Об’єкт для знущань: сайт Проджа

Порадьте, як погіршити UX? 🙏

Обирайте будь-які сторінки.

Завдання від Проджа — інституту вільної освіти 💙

Навіщо свої граблі, якщо є чужі. Зібрали 10 дизайн систем великих компаній. Насолоджуйтеся, зберігайте собі, не будьте жадібні — кидайте друзям:

• Spotify – Reimagining Design Systems at Spotify

• Booking.com – How We Built Our Multi-Platform Design System

• Uber – Uber Design Platform

• Dropbox – How Dropbox migrated to Figma and structured our cross-platform design system

• Salesforce – Lightning Design System

• IBM – Carbon Design System

• Atlassian – Atlassian Design System Evolution

• Airbnb – Airbnb Design Language System

• Microsoft – Fluent Design System

• Google – Material Design Evolution

Тут зібрали лінки, а практичні скіли зі створення ефективних дизайн систем — на воркшопі Design Systems.

Куратор: Франческо Кутоло, Design Lead у Wolt, ex. Design Lead Klarna, Figma community advocate у Швеції.

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

Питання: Як би ви заохотили ці команди використовувати дизайн-систему? Які стратегії ви б застосували, щоб забезпечити узгодженість, одночасно враховуючи їхні потреби?

Від Франческо Кутоло — автора та куратора інтенсиву Design Systems, Design Lead у Wolt (Doordash).

Що робити, якщо команда не використовує вашу дизайн-систему?

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

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

Потрібно спостерігати за тим, як вони взаємодіють із системою, виявляти точки тертя та збирати зворотний зв’язок для визначення напрямків покращення.

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

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

Від Франческо Кутоло — автора та куратора інтенсиву Design Systems, Design Lead у Wolt (Doordash).

«Коли робити UX рисьорч?»

1. Зараз. Чим раніше ви почнете, тим більший вплив матимуть результати на ваш продукт. Найкращий час, щоб розпочати дослідження, — це сьогодні, адже минуле повернути неможливо.

2. Досліджуйте користувачів на всіх етапах. На кожному з них можна дізнатися щось корисне. Кожен зважений крок буде приносити користі на більшу суму, ніж вартість дослідження.

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

Методи та заходи UX досліджень для різних етапів проєкту — на віжуалі.
Детальний розбір — у статті NN/g.

Ситуація: замовнику нічого не подобається
Питання: що робити?

(тільки неправильні відповіді)

Завдання від Проджа — інституту вільної освіти 💙

Добірка intrusive thoughts дизайнера інтерфейсів у коментарях під попереднім дописом — дивитися всім!

Подякували, записали, сподіваємося, що до втілення не дійде ✍️

Від натхнення аж нежиттєвий мем зробили.

«Де ви берете натхнення? На яких сайтах шукаєте патерни і референси для своїх інтерфейсів?»

Питання підслухано у чаті Interface Design Projector 📽️

Відповіді — теж:

• Mobbin
• Рідне:
• Land-book
• MaxiBestOf
• Godly
• Minimal Gallery
• Steph Hardy
• Brutalist Websites
• The Responsive

І трохи бази від редакції каналу:

• Design Spells
• Awwwards
• FWA
• LandingFolio
• UISources
• Dribbble
• Pttrns

Зберігайте та пишіть у коментарях, якщо щось забули 💙

Ви розробляєте складний багатоколонковий процес заповнення страхової форми, що складається з 30 етапів.

Припустимо, що форма має 2 колонки, кожна з яких містить близько 10 полів вводу.

Форма має містити такі UI компоненти:

• Reset (скинути всю форму)
• Cancel (скасувати цей етап)
• Clear (очистити вибір)
• Update (оновити індикатор статусу)
• Back (повернутися до попереднього етапу)
• Previous/Next (перемикання між етапами)
• Save and Exit (зберегти та вийти)
• Share (поділитися)
• Export as PDF (експортувати у PDF)
• Progress Bar (показник прогресу)

Питання: усі ці кнопки необхідні, оскільки виконують різні функції — як би ви інтегрували їх у єдиний інтерфейс форми?

Кейс від Віталія Фрідмана, автора і куратора воркшопів Design Patterns For Complex Web Forms, Measuring UX and Impact of Design, Designing for Complex UI, UX Strategy, Design Patterns for AI Interfaces, засновника та креативного ліда у Smashing Media.

Як створити smooth вебформу?

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

Одночасно важливо запобігти помилкам, випадковим натисканням і прискорити взаємодію.

Тому важливо максимально чітко позначати функціонал кнопок.

Кнопки «Скинути» (Reset) та «Скасувати» (Cancel) мають бути розташовані у верхньому правому куті екрана — бажано, щоб вони виглядали меншими за розміром і нагадували посилання.

Кнопка «Очистити» (Clear) повинна розташовуватися поруч із поточним полем вводу, виглядати як посилання і мати невеликий шрифт.

Кнопка «Оновити» (Update) має бути другорядною кнопкою стандартного вигляду, розташованою поруч із полем вводу.

Кнопка «Назад/Попередній» (Back/Previous) повинна виглядати як посилання у верхньому лівому куті екрана.

Кнопка «Далі» (Next) розташовується в нижньому лівому куті екрана.

Кнопки «Поділитися» (Share) та «Експорт у PDF» (Export as PDF) варто розмістити у верхньому правому куті екрана.

Для індикатора прогресу краще використати вертикальну шкалу, розташовану в бічній панелі зліва або справа.

Кнопка «Зберегти та вийти» (Save and Exit) повинна розташовуватися поруч із кнопкою «Далі» (Next).

Кейс від Віталія Фрідмана, автора і куратора воркшопів Design Patterns For Complex Web Forms, Measuring UX and Impact of Design, Designing for Complex UI, UX Strategy, Design Patterns for AI Interfaces, засновника та креативного ліда у Smashing Media.