Как поженить Аналитика, Проектировщика интерфейсов и Дизайнера? Ярослав Перевалов

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

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

Рассмотрим ситуацию, в которой нужно построить процесс разработки продукта с пользовательским интерфейсом.

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

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

1. Менеджер продукта или Представитель бизнеса (Бизнес-эксперт);

8. Проектировщик пользовательского интерфейса;

11. Тестировщик (да-да, и тестировщик иногда может влиять на интерфейсные решения, такова суровая реальность).

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

1. На проекте демократичная обстановка и плоская структура;

2. Есть желание у всех участников сделать продукт лучше;

3. Считается целесообразным максимально учесть все доводы сторон;

4. Нет жёсткого регламента сбора, анализа и управлением требованиями (да-да, так тоже бывает).

Лебедь, рак и щука, да и только! Рано или поздно демократия закончится принятием волевого решения руководителем проекта. Будет ли принято оптимальное решение? Не факт. Должен ли руководитель проекта вникать в тонкости визуализации чекбокс-контрола на одной из стопятисот формочек пользовательского интерфейса? Далеко не факт.

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

Кроме того, практически у любого сферического продукта в вакууме есть требования, факторы и ограничения различного характера, которые:

1. Непосредственно влияют на облик продукта, его функционал, интерфейс и характер взаимодействия;

2. Добываются и анализируются специалистами разного профиля;

3. Необходимо комплексно учитывать в проектировании продукта, см. Рис. 1.

Рис. 1. Факторы, влияющие на облик продукта, которые приходится учитывать при проектировании

Чтобы навести порядок в этом хаосе, нужно, на мой взгляд, выполнить простейшее упражнение по организации процесса разработки, а именно:

1. Чётко определить зону ответственности каждого участника проекта;

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

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

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

Это был анализ: мы разложили по полочкам участников производства в разрезе их зоны ответственности.

Потоки данных из правой колонки можно изобразить на схеме, это будет синтез, см. Рис. 2.

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

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

Например, роль Заказчика может играть внутренний менеджер продукта или руководитель отдела маркетинга (Маркетолог замещает Заказчика) или наоборот, Заказчик может предоставить десяток различных бизнес-экспертов из разных подразделений предприятия.

Что касается команды, реализующей проект, то и тут возможны различные фокусы с фигурами. Например, в компании, в которой я работаю, как правило, аналитические работы по проекту часто выполняет один человек: сначала он честно влезает в шкуру бизнес-аналитика, собирает и формализует бизнес-требования, затем как системный аналитик проектирует и формализует проектные решения.

Ещё один фокус с фигурками: юзабилити-специалист может быть одновременно и исследователем, и проектировщиком интерфейса. Лично я не рекомендую такой подход – хотя оба и относятся формально к юзабилити-специалистам, но бэкграунд и навыки нужны различные, а кроме того, проектной нагрузки обычно хватает более чем на двоих.

Таким образом, если приглядеться к схеме, то в процессе проектирования и разработки пользовательского интерфейса выделяются три краеугольных фигуры – Аналитик, Проектировщик, Дизайнер.

И тут тоже возможны фокусы с фигурами.

Я обычно привлекаю всех своих аналитиков к проектированию интерфейсов. Аналитикам легче писать спецификации, имея макеты интерфейсов под рукой, легче согласовывать с Заказчиком функциональность на основе этих макетов. Наконец, у меня в команде нет профессиональных проектировщиков интерфейсов (кроме меня самого).

Тем не менее, проектирование интерфейсов – это не специализация аналитиков, и поэтому аналитики проектируют интерфейсы часто с ошибками.

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

В общем, если есть возможность иметь в команде профессионального проектировщика интерфейсов – его надо иметь.

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

И конечно, области ответственности между этими фигурами немного пересекаются, возможны споры между тупоконечниками и остроконечниками – тут важно сразу чётко эту ответственность определить в проектном регламенте, чтобы в процессе избежать неконструктивных коммуникаций. Например, так, как я предлагаю в Табл. 1.

Таким образом, бывают вполне себе работающие схемы Аналитик-Дизайнер, где роль проектировщика как-то распределена между ними.

Но не вздумайте заставлять Дизайнера проводить аналитику или Аналитика заниматься дизайном – эти специалисты с разных планет, вряд ли хорошо получится. За мою 20-летнюю карьеру я видел только пару людей, способных на такие подвиги.

Последний маленький совет: если посадить работать Аналитика, Проектировщика и Дизайнера в одно помещение и одно время, эффективность их взаимодействия и продуктивность работы возрастает в разы. Ещё более можно добавить эффективности, если рядом будут разработчики и тестировщики.

Презентация доклада на конференции User eXpirience Russia 2012:

Распределение зон ответственности между юзабилити-специалистом, аналитиком и дизайнером как ключевой фактор построения эффективного процесса создания программного продукта from Yaroslav Perevalov

Дата публикации: 20 сентября 2012 г.

№ п/п	Роль	Зона ответственности: что делает и какие решения принимает	Кому и в каком формате передаёт информацию
1.	Бизнес-эксперт, Заказчик	Формирует ключевые бизнес-требования и расставляет приоритеты. Отвечает за стратегическое развитие продукта. Формирует показатели эффективности продукта, их контроль и оценку. Формирует бизнес-модель продукта.	Бизнес-аналитику: формулирует бизнес-требования. Руководителю проекта: помогает расставить приоритеты в списке фич.
2.	Маркетолог	Проводит исследования рынка, потребителей, конкурентный анализ. Формирует образ потребительских ожиданий.	Проектировщику интерфейса, дизайнеру, бизнес-аналитику: потребительские требования. Руководителю проекта: помогает расставить приоритеты в списке фич.
3.	Руководитель проекта	Определяет список фич на релиз. Формирует план работ на релиз. Управляет ресурсами.	Системному аналитику: список фич на релиз. Проектной команде: план работ на релиз.
4.	Системный архитектор	Учитывает аспекты технологической платформы, интеграции, программно-аппаратных решений. Ревью проектной документации, разработка технологической документации.	Бизнес-аналитику: технологические ограничения. Разработчику: модель данных (структура, потоки), описание архитектуры и пр.
5.	Бизнес-аналитик	Собирает, анализирует, формализует и согласовывает бизнес-требования к продукту.	Бизнес-требования: документ с четкими, непротиворечивыми и полными бизнес-требованиями, в том числе диаграммы бизнес-процессов, список ключевых показателей эффективности, ролевые модели (сценарии выполнения задач) и т.д., см. подробнее в статье про аналитику.
6.	Системный аналитик	Проектирует, детализирует, специфицирует и согласовывает проектные решения по реализации бизнес-требований.	Проектировщику интерфейсов: функциональные требования. Разработчикам и тестировщикам: спецификация на пользовательские интерфейсы и функционал.
7.	Юзабилити-специалист	Проводит исследования пользователей с целью построения моделей: кому и как важно и удобно какие задачи выполнять по какому сценарию. Формирует требования к функционалу и пользовательскому интерфейсу. Участвует в формировании приоритетов фич. Проводит юзабилити-экспертизу и юзабилити-тестирование продукта.	Проектировщику интерфейсов: требования к интерфейсу. Системному аналитику: требования к функционалу. Бизнес-аналитику: пользовательские требования (модели пользователей). Подробности о процессе проектирования интерфейсов см. в презентации и видео. См. также статью про юзабилити-специализации.
8.	Проектировщик интерфейсов	Формирует концептуальные и детальные макеты-прототипы пользовательского интерфейса: какую функциональность на основе каких контролов на каком экране как располагать. Согласование-обоснование дизайн-решений с Заказчиком, разработкой, дизайнером, юзабилити-специалистом. Разработка интерфейсных текстов (заголовки, наименования, сообщения и пр.). Вопросы информационной архитектуры.	Юзабилити специалисту: макеты для юзабилити тестирования (для поиска оптимальных проектных решений). Системному аналитику: оптимизированные макеты для специфицирования. Дизайнеру: оптимизированные макеты для художественного оформления.
9.	Дизайнер	Художественное оформление макетов пользовательского интерфейса: цветовая схема, типографика, графическое представление элементов интерфейса, градиенты, графическое оформление «заднего плана», «шапки и подвала», логотипов, пиктограмм, изображения, анимация и т.п. Согласование-обоснование дизайн-решений с Заказчиком, разработкой, проектировщиком интерфейсов.	Заказчику, разработке и проектировщику интерфейсов: макеты, определяющие стилевые решения и оформление продукта. Разработке и тестированию: дизайн-спецификация.
10.	Разработчик	Согласование проектных решений с проектировщиком интерфейсов, системным аналитиком, дизайнером. Программные решения, реализующие проектные решения.	Тестировщику: релизы для тестирования. Юзабилити-специалисту: релизы для юзабилити-тестирования. Системному аналитику и дизайнеру: релизы для авторского контроля.
11.	Тестировщик	Проведение функционального тестирования на основе спецификаций. Другие тестирования.	Баг-реквесты разработке, системному аналитику и проектировщику интерфейсов.

Usability.Ru	Статьи	Персоналии	Коллективы	Библиотека	Глоссарий	Обучение	Форум	Ссылки
Реклама: