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

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

Питання: як вам знайти потенційні проблеми і не витратити багато часу на проведення інтерв'ю?

Кейс від Євгена Олексюка — автора і куратора курсу UX Design Medium, Senior UX Designer y EPAM Systems.

Як знайти проблеми і не витратити багато часу на інтерв'ю?

Під час проведення кард-сортинг сесії з користувачами провести дослідження «Лист про розрив відносин».

Для цього ви надасте кожному юзеру аркуш паперу, на якому він напише:
«Любий продукте, я тебе дуже люблю, але ми повинні розійтись, адже деякі речі в тобі мене засмучують…» і напише перелік всіх відомих йому недоліків.

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

Корисна лінка: Love Letters and Break-Up Letters

Кейс від Євгена Олексюка — автора і куратора курсу UX Design Medium, Senior UX Designer y EPAM Systems.

Стас Говорухін зробив плагін «Булка» — на випадок, коли вам треба трансформувати гору тексту в стікери.

Наприклад, коли треба перенести фідбек користувачів з таблиці у фігму.

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

Забирати тут. Смачного.

Завдання на сьогодні — мемне.

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

Фото ваших pet children вітаються.

Кейс від Проджа — інституту вільної освіти 💙

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