Как бизнес-аналитику и 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.

Гранд-ретро

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

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

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

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

👍НравитсяПонравилось7
В избранноеВ избранном6
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Понравилось про «я не могу». Интересная концепция.

вспоминается классический анекдот:

Воспитательница в детском саду спрашивает: «Дети, в какой стране самые красивые игрушки?» Дети (хором): «В Советском Союзе!» Воспитательница «А в какой стране самые нарядные детские одежды?» Дети (хором): «В Советском Союзе!» Воспитательница: «А в какой стране самое счастливое детство?» Дети (хором): «В Советском Союзе!» Вдруг Вовочка начинает реветь. Воспитательница: «Вовочка, почему ты плачешь?» Вовочка (сквозь слезы): «Хочу жить в Советском Союзе!»

Ну тут досить суперечлива точка зору стосовно розподілу обов’язків. В більшості проектів якраз аналітик на етапі діскавері виявляє потенційних користувачів і їх потреби. Це один із основних аспектів аналізу

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

А чем описаное не Аджигайл?

Видео версия этой статьи, а вернее оригинальный вебинар доступен по ссылке
youtu.be/OhgB87l1PTw

Подписаться на комментарии