Как бизнес-аналитику и UX/UI-дизайнеру наладить гармоничную работу для создания продукта

Создание идеального продукта занимает немало времени и требует эффективного сотрудничества. Если не установить ​​конкретные и четкие процедуры взаимодействия, конфликты, скорее всего, будут неизбежны. Особенно это касается профессионалов, смотрящих на продукт с разных ракурсов: бизнес-аналитиков (BA) и дизайнеров UX/UI. Этот тандем можно сравнить с ралли: чтобы добраться до финиша, двум товарищам по команде нужно поддерживать четкую коммуникацию и играть по одним правилам.

Достичь этого вполне реально. Поэтому мы, Business Analysis Competency Lead Наталья Пелых и Design Lead Максим Шадрин из Ciklum, делимся советами и рекомендациями о том, как грамотно выстроить процессы, наладить коммуникацию и сообща добиваться цели.

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

Динамика UX/UI и BA

Сотрудничество BA и UX/UI похоже на связку пилота и штурмана в раллийных гонках. В одиночку успешно добраться до финиша гораздо сложнее: ведь нужно двигаться очень быстро и одновременно следовать дорожной карте. Аналогично ралли, в тандеме бизнес-аналитика и дизайнера важна быстрая обратная связь и четкая коммуникация действий. Все это — залог хорошего результата.

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

Как этого добиться? Продолжим нашу метафору о ралли: в рамках каждого проекта есть 5 пит-стопов, которые помогут создать гармоничное рабочее пространство.

Первая встреча

Важно поймать одну волну при запуске проекта. BA приходит со своим видением бизнес-процессов, а дизайнер — со своими идеями реализации.
Эти две концепции могут противоречить друг другу. Вот почему так важно сформировать общее понимание и задать правильный вектор с самого начала.

Команде необходимо определиться с форматом работы на проекте, например:

• определить каналы коммуникации, частоту митингов и синкапов, а также формат: например, операционные задачи в общем чате, стратегические — в переписке, статус задач — в соответствующем таск-менеджере;
• решить, на встречу с клиентом идет только BA или только дизайнер. Или же они будут представлять команду вместе;
• выбрать подходящий для всех темп работы и регулярность апдейтов.

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

Еще одна проблема, которая может возникнуть в ходе проекта — это жаргон двух специальностей: одни и те же термины могут по-разному восприниматься ВА и дизайнером. А названия одних и тех же компонентов могут отличаться у разных команд, например, поп-ап/поп-овер и так далее. Вполне вероятно, вы слышали похожий диалог:

— Где эта сторя про нотификации?
— Вообще-то это эпик!
— Неважно, мне нужна линка.

Тут на помощь придет вовремя созданный глоссарий. Чтобы избежать путаницы, создайте общий документ на Google Drive или в любой другой удобной и доступной для всей команды системе и поддерживайте его актуальным.

Логика дробления бэклог-задач у бизнес-аналитика и дизайнера также могут расходиться. Что стоит сделать для эффективной совместной работы?

• выделите/создайте отдельный тип задач, который будет использовать исключительно дизайн-команда;
• сформулируйте правила управления ими.

Это позволит быстро и удобно отслеживать прогресс по их выполнению.

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

Например:

• BA создает родительский эпик;
• дизайнер создает UX/UI таск-плейсхолдер для проработки базового сценария и сколько угодно подзадач внутри таска-плейсхолдера для декомпозиции и распределения UX и UI задач на команду.

Если вы чувствуете, что задачи разные, к примеру, вам нужна отдельная задача для юзабилити-тестирования или интервью с пользователями, вы можете создавать их под этим родительским таском-плейсхолдером. Важно добавлять ссылки на прототипы — как финальный артефакт для команды и BA.

Создание лейблов в Jira или любом другом аналогичном инструменте позволяет легче отслеживать прогресс.

Как это работает?

• бизнес-аналитик декомпозирует эпик на стори;
• добавляет на них правильный лейбл «UX/UI is required», что становится для дизайнера призывом к действию;
• лейблы-индикаторы позволяют дизайнеру легко фильтровать стори, чтобы понять, где требуется его вовлечение;
• дизайнер берет задачи в работу и отмечает прогресс, меняя лейбл на «UX/UI in progress». Когда задача завершена, ссылка на финальный прототип прикрепляется к таске и лейбл снова меняется на «UX/UI done».

Стартовый воркшоп

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

На этом этапе роль BA:

• изучить специфику бизнеса;
• очертить путь к эффективному достижению цели.

Роль дизайнера на этапе дискавери:

• выяснить, кто наши пользователи;
• выявить потребности пользователей и заинтересованных сторон;
• определить сильные и слабые стороны системы или приложения;
• понять контекст использования продукта и найти новые идеи для разработки.

Мы в Сiklum следуем методологии Design Thinking (дизайн-мышление) и Lean UX. С ее помощью мы стремимся понять пользователей, подтвердить или опровергнуть гипотезы и переосмыслить проблему, чтобы найти неочевидные альтернативные решения. Это требует более высокого уровня вовлечения BA в процесс.

Любая параллельная работа в отрыве друг от друга на этом этапе будет занимать намного больше времени, а ее ценность будет значительно меньше.

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

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

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

Планирование релизов

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

• Клиент не может без долгосрочного планирования релизов.
• Разработчик не может оценить релиз без полной картины.
• UX-дизайнер не может проработать E2E flow без требований.
• Бизнес-аналитик не может проработать стори сильно наперед.
• UI-дизайнер не может рассчитывать на то, что требования и прототипы финальные.

Это классическая проблема. Единственный способ выйти из этого цикла — это убедиться, что есть четкая система минимально необходимых входящих данных и отработанная схема передачи задач. BA может определить последовательность и приоритет задач и формировать бэклог-задач поэтапно. Для этого отлично подходит использование Miro как альтернатива бэклогу в Jira.

Как это работает:

• формируется идея и high-level E2E flow от UX;
• BA дает более четкие требования;
• проходит общая валидация;
• идем на второй круг с учетом комментариев от бизнеса и пользователей.

Иногда вы можете углубиться в анализ, чтобы достичь идеального варианта. Другими словами, analysis paralysis предполагает возможность долго работать над совершенными требованиями, чтобы убедиться, что вы точно все учли. В дизайне иногда можно проводить много исследований. Поэтому самое ценное — это опыт и понимание того, где лучше проработать UX-прототипы несколько раз и получить при этом лучший результат, чем надеяться, что все хорошо получится с первого раза.

Что из этого следует?

• Начинать дизайн без подробно описанных требований — это нормально.
• Бэклог в Jira не настолько очевиден для всех, как кажется бизнес-аналитикам.
• Избегайте паралича перфекционизма с помощью частых «релизов» дизайна.
• Ограничения стимулируют креатив!

Ежедневная работа в спринтах

На этом этапе часто приходится ориентироваться по ситуации. Ваша команда разработчиков — это бесценный источник потрясающих идей и ответов на вопросы о том, что можно сделать более эффективно, лучше или правильнее. Когда речь идет о тестировании готовых решений, обязательно привлекайте дизайнера к проверке функциональности. Это позволит ему иметь комплексное представление о работающем продукте и быстро выявить несоответствия между задуманным дизайном и фактической имплементацией.

Если кратко:

• Откладывая что-то на потом, заложите один «косметический» спринт на 4–6 основных спринтов.
• Вовлекайте дизайнера в проверку функционала.
• Попробуйте вести бэклог несоответствий имплементации и финального UI.

Гранд-ретро

Гранд-ретро — это итоговая встреча, которая проводится вместе с командой после завершения проекта. Момент, когда вся команда еще в сборе и стоит сделать паузу, чтобы немного порефлексировать.

Даже самый идеальный план сотрудничества, о котором вы договорились в самом начале, может поломаться.

Вы обсуждаете и фиксируете, что прошло хорошо, а что не совсем так, как было задумано. Какие паттерны взаимодействия стоит зафиксировать и забрать с собой в следующие проекты. Ретро в конце фазы разработки или проекта призвано выявить все проблемы взаимодействия и найти их решения для будущих инициатив.

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