Распределение обязанностей в IT-проекте: ВА и Дизайнер

Есть вечные темы. Среди них - как распределяются обязанности в проекте. Сегодня рассмотрим разделение задач между Дизайнером и Аналитиком. Этот вопрос волнует не только дизайнеров и аналитиков, но Project Manager-ов (может быть, больше всех ).

❓Проблема в чем? У аналитиков есть свой свод знаний, а у дизайнеров - свой. В реальности же их задачи, практики и даже инструменты очень часто пересекаются.
И "изнутри" это выглядит так:

• "аналитик изучает потребности пользователей и создает требования к системе, в том числе ее пользовательскому интерфейсу",
• "дизайнер (UX) изучает опыт пользователя и создает требования к пользовательскому интерфейсу"
• и далее - перечень примерно одинаковых практик, хотя называться они могут по-разному.

Давайте посмотрим на это с точки зрения процесса кроссфункциональной работы и accountability.

❓Почему вообще возник этот вопрос? 

На одном из уроков курса Business Analysis с дизайнером мы говорили не про UI и даже почти не про UX. Мы говорили о структуре системы, вернее пользовательского интерфейса системы.

Демонстрация результатов совместной  онлайн-работы
группы курса Business Analysis от AdvanceIT
по созданию структуры секций и экранов для LMS

Что нужно, чтобы создать структуру интерфейса?

Структура системы, это - Design (существительное). И "проектирование" - это тоже design (глагол). Это определение перечня элементов и блоков, связей между ними, и их группировка по категориям (разложение "по кучкам" по определенным признакам)

Структура интерфейса - это "инвентаризация" экранов, элементов и вкладок. Для того, чтобы

1. избежать "зоопарка" (и т.о. сократить объем работ для команды и сделать интерфейс понятным для пользователя)
2. проэстимировать объем работ
3. определиться с терминологией, которой команда называет разные элементы интерфейса, для однозначного понимания.

Перечень секций, экранов, элементов идет "на вход" Дизайнеру, который "рисует" для них wireframes и визуальный дизайн.

👉 Как создать перечень секций, экранов, элементов 

Он основывается на пользовательском флоу и на том, как пользователь взаимодействует с системой, как он ее воспринимает. 

Это относится:

• как удобству и эффективности достижения цели пользователя, с которой он приходит в систему (например: купить билет или сделать отчет),
• так и к восприятию системы в целом, пониманию ее (например: Draw.io менеджерам и аналитикам очевиднее и понятнее, чем Invision, поэтому больше вероятности, что они будут пользоваться первым, даже если второй более заточен под специфические задачи и sexy )

👉 Как определяется пользовательский флоу?

На основании задач пользователя в системе! 

То есть сначала нам нужен перечень пользовательских требований. Аналитики могут делать это в виде перечня Use Cases или Use Case diagram.
Т.о. на вход к User Flow нужны Use Cases.

👉 Как определяется перечень Use Cases?

На основании изучения потребностей и задач пользователей и владельцев системы. Наши рекомендации по тому, как это сделать читайте здесь.
А мы пока перечислим задачи, которые нужно сделать, чтобы понять объем работ и начать "рисовать" требования (wireframes). И попытаемся понять, кто может за них отвечать.

Задачи, предшествующие визуальному дизайну, и ответственные

1. Выявление задач владельцев системы - Business Analyst.
2. Выявление пользователей и их потребностей - Business Analyst с привлечением Дизайнера. Если это будет только Дизайнер, без ВА то кто и как создаст видение продукта и перечень пользовательских требований? Тут и ВА, и Дизайнер могут пользоваться одними и теми же инструментами: JTBD, Value Proposition Canvas, Persona, описание процесса/ сценария и пр.
3. Формирование видения (концепции) продукта - Business Analyst.
4. Формирование перечня Use cases или User Stories (главное, чтобы было указание цели пользователя) - Business Analyst, традиционно. Но уверены, Дизайнеры тоже на это способны, если нет ВА.
5. Определение последовательности переходов пользователя между экранами (user flow) для определенных Use Cases - Дизайнер, традиционно. Но уверены, Business Analyst тоже на это способны.
6. Определение перечня и группировки секций и экранов - это могут делать Аналитики, а иногда даже Разработчики. Но лучше Дизайнеры, т.к. они скорее будут основываться на user flow.
7. Создание wireframes, структуры конкретных экранов - могут Аналитики, но лучше Дизайнеры.
8. Создание визуального дизайна - Дизайнеры.

В реальности все зависит от продукта/ проекта, состава команды и ее компетенций. Но Business Analyst должен уметь составлять перечень секций и экранов, так же как и рисовать wireframes.

Но это уже другая тема. Следите за обновлениями нашего блога!