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

Тім Роман — 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 і порівняти дослідження. Але траплялося, що підсумок звучав сильніше, ніж написали самі автори. Тож усе, що стає аргументом для рішення, я обов'язково вичитую, що й вам раджу.

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

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

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

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

Менше кліків не завжди легше

З 1890 року, відколи Вільям Джеймс описав увагу як зусилля, дослідження раз у раз підтверджують: розумове зусилля обмежене, людина його відчуває і намагається уникати. Тож цілком логічно, що ми дедалі більше розвантажуємо голову. Що складніший світ, то більше доводиться тримати в пам'яті, і це заважає залишатись ефективним. Та й сенсу пам'ятати все немає. Частину цієї роботи ми виносимо в нотатки, автоматизуємо, делегуємо інтерфейсам - адаптуємось під реалії.

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

Ми переносили в новий кабінет ПУМБ Бізнес друк по дві платіжки на сторінку. Бухгалтери великих компаній давно про нього просили: менше паперу і вдвічі легший PDF. Я зробив два варіанти.
- Дві іконки принтера з цифрами 1 і 2, друк в один клік, як у старому кабінеті.
- Одна кнопка принтера, яка відкриває список з пунктами «Друкувати по 1 платіжці на сторінку» і «Друкувати по 2 платіжки на сторінку». Тобто два кліки.

У Maze кожен варіант проходила своя гомогенна група з 20 людей. Завдання виконали всі, і оцінили обидва варіанти майже однаково. Але з меню люди впорались на 21,6 с швидше (27,7 секунди проти 49,3 с з двома окремими іконками).

По тепловій карті я зрозумів, чому так відбувалось. Люди виділяли платіжки, знімали виділення, поки не лишалось рівно дві, і тільки тоді натискали на іконку друку з цифрою 2. Припускаю, що вони сприймали цифру 2 в іконці друку як лічильник виділених рядків. Тултіп про значення цих іконок з'являвся лише при наведенні. А от у випадаючому меню підпис видно одразу, його досить легко розпізнати. Іконку ж цифрою треба було розгадувати, і замість швидкого автоматичного мислення вмикалось повільне. Тому один клік когнітивно коштував людям більше, ніж два.

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

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

Що я виніс: перш ніж оптимізовувати кількість кліків варто порахувати, що людині доведеться для цього пригадувати, розгадувати й перевіряти. Частину цих зусиль можна оцінити ще до тесту. Курс Projector UX Design Advanced познайомив мене з предиктивною моделлю GOMS, і тепер я ще до того, як запускати тестування з реальними користувачами можу порахувати мінімальний час виконання завдання для кожного варіанту дизайну.

Це звісно ж не остаточний доказ, а всього лиш бенчмарка, яка допоможе сформувати припущення 😉

Доречі, я тут забігався - а через 6 хв стартує Мітап про Accessibility від ГО "Доступність Цифрова".

Тема - "Тулзи для Digital Accessibility".

Залітайте - Ось тут міт