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

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

Якщо захочеться практичнішого формату — воркшопу — залишайте заявку тут 👈🏻

А завершити хочу цитатою зі свіжого випуску HBR:

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

Дякую і гарного тижня! 👋😌
Мої контакти Instagram, LinkedIn.

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

Особливо зачепила думка про те, що АІ будує власну культуру, і що, можливо, саме через мистецтво, яке він створюватиме, ми зможемо краще зрозуміти, як він мислить. Є над чим порефлексувати.

Дякуємо тобі за цей час і йдемо далі 💙

Також маємо декілька курсів, які розпочинаються ось-ось та можуть бути вам корисні 🤝

Як почався ваш тиждень?
Підготували останні старти жовтня та цікаві новинки до вашого перегляду:

AI & Design Systems with Brad Frost — 4 дні впровадження AI в дизайн-систему. Аудит-промпти, чекліст оцінки ефективності та план для команди. Це наш перший воркшоп із Бредом Фростом, і поки наступних запусків не заплановано. Тож радимо доєднатися — старт уже сьогодні.

Product Marketing — оновлена програма з Growth Loops та Experimentation. А ще при реєстрації даруємо інтенсив A/B Testing.

Інші курси жовтня — у коментарях.
Продж 💙

Ну що ж, ми готові представити вам нового куратора! Можливо, хтось уже знайомий із ним, а якщо ні — знайомтеся:

Тім Роман — Product Designer у ПУМБ Бізнес, дизайн-менеджер у бібліотеці паперових книг KyivUX та ментор у Projector Mentorship Platform.

У дизайні Тім понад 16 років. Працював у різних доменах в аутсорсингових та аутстаф-агенціях, фрилансив, а останні 4 роки працює над фінтех-продуктами.

Також співавтор книги «Смачні кнопки» та поборник нейровідмінного дизайну. А ще дотримується принципу lifelong learning.

Тіме, запрошуємо тебе до слова й бажаємо гарного тижня! 💙

👆 Обирайте теми, з яких почнемо. Дві з найбільшою кількістю голосів розберу першими. Якщо вашої теми тут немає, пишіть у коментарях

Добрий вечір друзі. Неочікувані результати для мене. Ну ок.

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

Але все буде. Ще 10 хв і я переключусь на вас. Я дуже ізвіняюсь 😁😁

За результатами голосування найбільше, що вас цікавить - це те, як задача в ПУМБ проходить від старту і до релізу. Ок. Я прийняв. В мене є для вас трохи інформації. Сподіваюсь буде цікаво

Життєвий цикл задачі в ПУМБ: від брифу до релізу

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

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

Планування і аналіз задачі
Як сказано в Євангелії від Івана (я не релігійний якшо шось), «спочатку було Слово». В Agile спочатку було планування спринту. Що ми робимо тут і зараз, залежить від квартальних цілей, фідбеку юзерів, вимог регулятора чи дизайн-боргу. Саме тут ти набираєшся задач, як собака бліх, на найближчі два тижні.

Бриф зазвичай виглядає як бізнес-схема від аналітика, від якої очі на лоба лізуть, і опис story на 5 сторінок А4.

Щоб в'їхати, я розкладаю задачу в мапінг на кшталт Service Blueprint чи BPMN і ставлю купу питань до кожного кроку. Що, як у користувача немає підпису керівника? Чи може система самостійно витягти номер рахунку з договору і чи може при цьому помилитись? Відповіді спершу шукаю сам: гуглю, питаю ШІ, риюся в Confluence. Решту збираю в список і закидаю замовнику: у нашій оргструктурі це аналітики або PO.

Але текстовий список рідко закриває діру нерозуміння, тож складні флоу без грумінгу не обходяться. Аналітики, PO, фронт, QA, інколи бек збираються на "Чорну раду" і розглядають мої каляки-маляки мапінги, і питання закриваються прямо в процесі.

Діскавері
Для нового функціоналу готується план дослідження: ЦА, гіпотези, метрики, івенти на потрібні екшни в UI для аналітики після релізу (так, воронку треба будувати руцями, раніше я цього не знав). Чернетку приносить аналітик або готую я. Далі шліфуємо план із сервіс-дизайнеркою, дивимось на власну систему, конкурентів і функціональні аналоги, шукаємо вторинні дослідження.

Перше діскавері майже завжди треш, бруд і хитання, поки команда не набере контексту про ринок і ЦА.

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

Тестування
Довгий складний флоу ризикований: юзер втомиться і відповідатиме на відчепись. Тут радимось із сервіс-дизайнеркою (Христино, привіт!). Скажімо, у мене форми на 10+ полів і сторонні флоу всередині. Включати все? Обмежитись happy path? Цього разу вона запропонувала заповнювати частину полів вручну, а решту автоматично (God bless Claude Code).

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

Рев'ю, розробка, User Acceptance Testing
У ПУМБ практика взаєморев'ю: дизайнери перевіряють рішення один у одного, перш ніж ті підуть у розробку. Є зауваження - повертаюсь до макетів і правлю, правлю, правлю.

Затверджені макети йдуть у хендоф, і він тут зовсім не такий, як в аутсорсі. Це не набір згрупованих макетів, а детальний screen flow: едж- і корнер-кейси, взаємодія з сервером, пусті стани, помилки, фолбеки. Що менше задокументую, то більше питань прилетить від розробника.

Далі QA виловлює баги й повертає задачу розробнику, а інколи й дизайнеру: тоді погоджений дизайн знову йде на рев'ю. Цього намагаються уникати ВСІ, бо дата релізу зазвичай уже погоджена.

Фіналочка - UAT. Я перевіряю, що дизайн виглядає так, як закладено в макетах. А якщо помічаю щось не моє, але очевидно зламане, теж підсвічую.

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

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

Вечір в хату, панове. Як і обіцяв, сьогодні друга тема з найбільшою кількістю голосів.

Вторинні дослідження недооцінені
Коли ми почали покращувати досвід читачів дизайн-бібліотеки KyivUX, мені здавалося, що задача досить нішева. Виявилося, що пошук інформації, вибір книжок, відгуки й навіть затримки з поверненням досліджують десятиліттями. Тож можна знайти що завгодно.

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

Пошук досліджень теж працює як воронка
Наприклад "дослідження про бібліотеку" надто широкий запит, і очевидно невдалий. Тому я пройшовся по шляху нашого читача: дізнався про книжку, шукав, оцінював, замовив, прочитав, повернув, залишив відгук. До кожного етапу виникає купа питань. Одне із питань яке нас цікавило - вибір книжки, тож ми звужували так: пошукова поведінка → пошук професійної інформації → як люди знаходять і оцінюють професійні книжки.

Англійські академічні терміни знаходять більше релевантного контенту
Формулювання типу "як люди вибирають книги" дають мало. А от book selection criteria, book discovery behavior чи online review processing знаходять те, що звичайні запити пропускають. Ще одне джерело: список літератури самої статті та роботи, які її цитують. Одна вдала знахідка часто тягне за собою цілий ланцюжок не менш цікавих результатів.

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

Читати все від початку до кінця не обов'язково
Щоб зрозуміти, чи дослідження тобі підходить, зазвичай вистачає чотирьох розділів:
- Abstract: чи це взагалі про нашу проблему.
- Methods: кого, скільки, як і в якому контексті досліджували.
- Results: що встановили, окремо від того, як автори це пояснюють.
- Limitations: чого дослідження не доводить.

Чужі висновки перетворюються на власні питання
Чужі дослідження майже ніколи не співпадають із вашими потребами. Але що вони дають так це точніші питання для інтерв'ю.
Напр. Academic Book Discovery, Evaluation and Access розрізняє пошук конкретної книги і пошук літератури на якусь тему. Вони досліджували науковців, а не дизайнерів, але ми перетворили це на питання: наші читачі приходять за конкретною книжкою чи з запитом на вирішення своєї професійної проблеми? Інтерв'ю показали, що буває і так, і так, межа часто розмита. Людина має тему чи кілька рекомендацій колег, але книжку ще не обрала.

Disconfirmation Effect on Online Rating Behavior показав, що оцінки частіше ставлять ті, чий досвід розійшовся з очікуваннями. Звідси виросла гіпотеза: добровільні відгуки можуть відображати переважно крайнощі. І справді, ті з наших читачів, хто взагалі пише відгуки, роблять це, коли книжка дуже сподобалась або дуже розчарувала.

Розбіжність важить не менше за збіг
Тріангуляцією називають перевірку одного питання кількома джерелами: зовнішніми дослідженнями, аналітикою, інтерв'ю. Збіг дає додаткові аргументи і збільшує вагу нашим висновкам. Мене ж більше зачепила розбіжність. В інтерв'ю з'ясувалося, що відгуки про бібліотеку вже існують, тільки не на сайті, а в постах у LinkedIn та Instagram. Жодна стаття цього не підказала. Тому дослідження, які суперечать гіпотезі, варто шукати так само цілеспрямовано, як і ті, що її підтверджують.

Використовуйте ШІ нещадно
ШІ дуже допоміг підібрати терміни, підсумувати довгі PDF і порівняти дослідження. Але траплялося, що підсумок звучав сильніше, ніж написали самі автори. Тож усе, що стає аргументом для рішення, я обов'язково вичитую, що й вам раджу.

І наостанок
Мені здається, ми як дизайнери часто поспішаємо з власним дослідженням, не перевіривши, чи хтось уже шукав відповідь. А шукали. Десятки років а іноді й сотні. Для мене цінність вторинних досліджень виявилася в запитаннях, які вони допомагають сформулювати.

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

Добрий вечір друзі. Як ваш день сьогодні? Всі на Дизаріумі? 😁

Я тут до вас із новим лонгрідом прийшов. Сьогодні про ергономіку