Добре рішення інколи живе рівно два дні. Нещодавно я запропонував зберігати історію дій користувача у флоу 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. Я перевіряю, що дизайн виглядає так, як закладено в макетах. А якщо помічаю щось не моє, але очевидно зламане, теж підсвічую.
І реліз. На демо збираються сотні співробітників банку, щоб послухати, яка команда що релізить. Після релізу збираємо метрики й фідбек, усе це йде в беклог і на наступне коло планування.
Про це можна говорити довго і душно, тож якщо хочете детальніше про якийсь етап, пишіть у коментах.