Проект без аналитиков или как продуктовому дизайнеру жить в “Кто помнит какой бизнес-процесс мы согласовали?”

Иногда так бывает, что проект мал, незрел или скромен. Аналитиков нет, некому заполнять конфлюенс, продукт оунер занят развитием продукта, а разработка пилит все, что нужно успеть до релиза. Часто это бывает сопряжено с некоторой кадровой текучкой, разной скоростью разработки, сменой приоритетности задач и вот это вот все. Если посмотреть со стороны то это будет выглядеть как будто хамелеон в образе Джигурды жонглирует кодом, людьми и прошлогодней картошкой. В таких ситуациях некоторые начинают жаловаться, что мол “проект не очень и надо валить…”, а мне кажется, что это просто отличная возможность для продуктового дизайнера помочь настроить процессы, облегчить работу всем и выйти на новый уровень, так сказать.

(Для тех, кто не любит читать - внизу схема)

В типичных крупных Agile командах обычно есть аналитики, которые анализируют процессы, делают схемы, бережно их хранят и следят за своевременным обновлением. В маленьких командах для этого есть либо продукт оунер либо продуктовый дизайнер.

1. С чего начать

Точкой старта должны стать ключевые процессы в продукте. Можете ли вы их быстро и четко сформулировать? Это может быть покупка (лучше понимать, что чаще всего покупают), создание заявки на звонок или создание объявления. Если макеты процессов есть, то собирайте их последовательно друг за другом и выгружайте в Miro (б\п) или Overflow (около 12$\мес.) - отличные инструменты, где можно хранить процессы. Если нет макетов, то описываете схематично словами процесс по шагам. Например: юзер открыл приложение, нажал кнопку регистрации, попал на экран ввода данных и т.д. (Ну или по принципу JTBD). Далее вы нехитрыми движениями рук проставляете стрелочки от макета к макету, пока не останется ни одного контрола, участвующего в этой песне, без стрелки куда он должен вести. Не забываем про кнопки “обратного хода”.

2. Смотрим по сторонам

Когда кажется, что все сделано, вы абстрагируетесь и пытаетесь понять какие смежные системы/приложения/интеграции присутствуют в данном процессе и начинаете привязывать скриншоты из них, шаг за шагом, по всей цепочке. Это очень важно, т.к. основная доля ошибок приходятся на эти стыковки. Например, на стороне продукта регистрация закончена, вот success экран и все гуд. Но есть же еще подтверждение по e-mail. Как юзеру перейти в имейл быстрее, пока не забыл, куда ведет ссылка из письма, как вернуть его в тот процесс, с которого он пошел регистрироваться. Короче, бесшовный UX должен быть восторжествовать.

3. Несем на суд

Далее вы показываете продукт оунеру свое творение. Важно! Не надо сразу на него сваливать все ваши схемы ключевых процессов. Да и делать их все махом тоже не надо, т.к. правки в одном могут кардинально изменить другой.

Оунер сказал “ДА”. Порадовались? Теперь соберите команду и покажите им.

Разработчики часто дают дельные советы, которые зазнавшиеся продакт дизайнеры, бывает, слушать не любят. А еще вы могли упустить какой-нибудь стоп-фактор типа “Мы технически не можем сразу отправлять письмо с подтверждением e-mail” и тогда вы идёте вносить правки во флоу...

4. Финал

По итогу внесения всех правок и ещё одного согласования, вы фиксируете эти схемы и отныне они должны являться яблоками примирения при возникновении вопроса "Какой бизнес-процесс мы согласовали?".

Не забудьте, что их нужно будет дополнить алертами, ошибками, все возможными проверками и запросами разрешений. Все это счастье должно быть аккуратно сложено, подписано и быть на виду.

Прикрепляйте флоу каждого процесса, где больше одного экрана, к задачам в свои таск-трекеры и документацию.

По моему опыту и опросам команд эти схемы экономят время дизайнеру, продукт оунеру, тестировщику и разработке на 50-70%.

Самая объемная работа будет в начале, зато потом вы просто будете дополнять схемы и много раз скажете себе гран мерси, за то, что не приходится спорить со всеми о чем там договаривались.

Как и обещала - написанное в схеме: