interfaces.prjctr | vnotchenko week

Ситуація: замовнику нічого не подобається Питання: що робити? (тільки неправильні відповіді) Завдання від Проджа — інституту вільної освіти 💙

«Коли робити UX рисьорч?» 1. Зараз. Чим раніше ви почнете, тим більший вплив матимуть результати на ваш продукт. Найкращий час, щоб розпочати дослідження, — це сьогодні, адже минуле повернути неможливо. 2. Досліджуйте користувачів на всіх етапах. На кожному з них можна дізнатися щось корисне. Кожен зважений крок буде приносити користі на більшу суму, ніж вартість дослідження. 3. Зосередьте більшість досліджень на початку проєкту. Тоді вони матимуть найбільший вплив. Але залиште частину бюджету для додаткових досліджень на пізніших етапах. Це особливо важливо, якщо ресурси на всі необхідні кроки обмежені. Методи та заходи UX досліджень для різних етапів проєкту — на віжуалі. Детальний розбір — у статті NN/g.

Що робити, якщо команда не використовує вашу дизайн-систему? Щоб заохотити команди використовувати дизайн-систему та забезпечити узгодженість, я зосередився б на її зручності та ефективності. Дизайн-система має спрощувати робочі процеси та зменшувати когнітивне навантаження, тому важливо оцінити, наскільки легко команди можуть її використовувати. Потрібно спостерігати за тим, як вони взаємодіють із системою, виявляти точки тертя та збирати зворотний зв’язок для визначення напрямків покращення. Можна зробити дизайн систему більш інтуїтивною та доступною шляхом ітераційного вдосконалення. Наприклад, покращити документацію, розширити функціональність інструментів або надання адаптованих шаблонів. Коли система зручна й органічно вписується у наявні робочі процеси, це природним чином стимулює її використання. Такий підхід дозволяє досягти узгодженості у продуктах, одночасно враховуючи потреби та виклики окремих команд. Від Франческо Кутоло — автора та куратора інтенсиву Design Systems, Design Lead у Wolt (Doordash).

Ви керуєте розробкою дизайн-системи для своєї компанії. Після її запуску помічаєте, що деякі команди не поспішають її впроваджувати, віддаючи перевагу власним дизайн-рішенням. Це призводить до несумісностей у продуктах компанії. Питання: Як би ви заохотили ці команди використовувати дизайн-систему? Які стратегії ви б застосували, щоб забезпечити узгодженість, одночасно враховуючи їхні потреби? Від Франческо Кутоло — автора та куратора інтенсиву Design Systems, Design Lead у Wolt (Doordash).

Навіщо свої граблі, якщо є чужі. Зібрали 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 у Швеції.

Ну ви! Дякуємо за відповіді. Вийшло так само погано, як тег від замовника ввечері неділі та ситуації на картинках. Чекайте на душний кейс завтра 💙

Завдання: зробити поганий дизайн Об’єкт для знущань: сайт Проджа Порадьте, як погіршити UX? 🙏 Обирайте будь-які сторінки. Завдання від Проджа — інституту вільної освіти 💙

Менше часу на рутину, більше — на творчі завдання Знайшли плагін Handy Components від Арсена Колиби — нашого куратора курсу Product Design, продуктового дизайнера у Wix. Нещодавно кількість користувачів перетнула 100 000 тисяч. Плагін автоматично підлаштовує UI-компоненти під стиль вашого дизайну. Він magically підбирає match — визначає, як саме мають виглядати компоненти у вашому файлі, враховуючи типографіку, кольори, радіуси кутів та інші параметри. Що це дає? 1. Готові компоненти, які ідеально вписуються у ваш дизайн. 2. Економію часу на налаштування стилів вручну. 3. Узгодженість і стильність у будь-якому проєкті без зайвих зусиль. • Тестуйте за посиланням

Як взятися за нове та побороти синдром самозванця? Дизайнери переносять ідеї від бізнесу до користувачів. Світ швидко рухається, створюються нові бізнеси на незнайомі нам теми — тож ми ніколи не будемо розбиратися в усьому. Тому на початку проєкту страшно входити в незнайому для нас тематику — це вихід з комфортної зони. Уявіть, що вам 1 рік і ви не спробували вчитись ходити, тому що страшно впасти. А тепер уявіть, що ви не спробували попрацювати з проєктом, для якого вважаєте себе «недосвідченим». Не спробувавши — не буде зростання. Але для кожного «нового» треба час — плануйте терміни із запасом на рисьорч. Також варто знайти людину, яка шарить в цій темі та поговорити з нею. Оцініть проєкт, а потім додайте ще 1.5x годин на «дорозібратись». І все у вас вийде! Від Олі Алтухової — кураторки курсу Web Design Junior, дизайнерки продукту в airSlate.

Завдання із серії «Підтримка» 💙 Вам запропонували взятися за класний дизайн проєкту, але не надто великий досвід і надокучливий синдром самозванця зупиняють вас. Питання: Як будете «домовлятися» з останнім, щоб все ж долучитися до проєкту? Від Олі Алтухової — кураторки курсу Web Design Junior, дизайнерки продукту в airSlate.

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

Користувач, коли треба взаємодіяти з держсайтами: картинка перша Користувач, коли провзаємодіяв з держсайтами: картинка друга Комісія Проджа прогляне ваші вчорашні жарти та оцінить кількість та інтенсивність хіхіків найближчим часом. Дякуємо! На фото Дуня — тотемна тварина нашої смм-менеджерки Юлі Перевертайло 💙

Завдання на сьогодні — мемне. Закиньте картинку, яка ідеально описує ситуацію: користувач намагається підписати петицію на державному сайті. Фото ваших pet children вітаються. Кейс від Проджа — інституту вільної освіти 💙

Стас Говорухін зробив плагін «Булка» — на випадок, коли вам треба трансформувати гору тексту в стікери. Наприклад, коли треба перенести фідбек користувачів з таблиці у фігму. Улюблений сценарій творця: скопіюйте колонку з таблиці й перетворіть її на стікери одним кліком. Стас каже, що це дійсно кайф. Забирати тут. Смачного.

Як знайти проблеми і не витратити багато часу на інтерв'ю? Під час проведення кард-сортинг сесії з користувачами провести дослідження «Лист про розрив відносин». Для цього ви надасте кожному юзеру аркуш паперу, на якому він напише: «Любий продукте, я тебе дуже люблю, але ми повинні розійтись, адже деякі речі в тобі мене засмучують…» і напише перелік всіх відомих йому недоліків. Так вам не доведеться витрачати багато часу на проведення юзер інтерв'ю та їхній аналіз та дозволить набити беклог, щоб потім опрацювати ці проблеми. Корисна лінка: Love Letters and Break-Up Letters Кейс від Євгена Олексюка — автора і куратора курсу UX Design Medium, Senior UX Designer y EPAM Systems.

Ви працюєте на проєкті. Під час тестувань вже наявного сайту ви дізналися, що навігація працює погано і тому ініціювали кард-сортинг на досить великій фокус групі постійних користувачів. Сесія кард сортингу з вашими постійними юзерами відбудеться вже за тиждень, але за останні 2 — після останнього релізу — в саппорт чомусь навалилось дуже багато негативних відгуків. Питання: як вам знайти потенційні проблеми і не витратити багато часу на проведення інтерв'ю? Кейс від Євгена Олексюка — автора і куратора курсу UX Design Medium, Senior UX Designer y EPAM Systems.

Ви працюєте на проєкті. Під час тестувань вже наявного сайту ви дізналися, що навігація працює погано і тому ініціювали кард-сортинг на досить великій фокус групі постійних користувачів. Сесія кард сортингу з вашими постійними юзерами відбудеться вже за тиждень, але за останні 2 — після останнього релізу — в саппорт чомусь навалилось дуже багато негативних відгуків. Питання: як вам знайти потенційні проблеми і не витратити багато часу на проведення інтерв'ю? Кейс від Євгена Олексюка — автора і куратора курсу UX Design Medium, Senior UX Designer y EPAM Systems.