Парное проектирование интерфейсов

Почему понадобилось два специалиста по продукту

Полная энтузиазма и в спокойном режиме за месяц до отпуска я взялась за новый проект —— сайт для Федерации тенниса России. По нашим расчетам, я прекрасно успевала. Но разве может все идти по плану? —— Конечно, нет. Пришли коллеги из другого отдела и попросили помочь. Так вышло, что я знакома с их очень важным проектом, поэтому лучшим решением было привлечь именно меня. А дедлайн по Федерации тенниса никто не отменял. Стали думать, как успеть без потери качества — придумали усилить команду еще одним специалистом по продукту. Мы предвидели возможные сложности: потребуется время на погружение в проект, возможны проблемы при синхронизации версий прототипов. Так как проект был относительно несложным, мы решили попробовать, а заодно научиться чему-то новому

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

Итак, у нас два специалиста по продукту (у каждого половина рабочего времени на проект, то есть 80 человеко-часов), две недели, и необходимо спроектировать 20 шаблонов страниц сайта. На один шаблон закладываем в среднем три часа —— получаем 60 часов на проектирование. Еще необходимо 15 часов на правки и 5 часов на демо заказчику. Получаем имеющиеся у нас 80 человеко-часов, а значит, успеваем!

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

1. Приоритезируем шаблоны. На приоритет влияет важность и частота использования будущей страницы. Эти параметры мы получаем на основе персон, которые составляем для проектов.
2. Учитываем загрузку исполнителей на других проектах. Эту информацию получаем от менеджеров: какие задачи и к какому дню нужно выполнить. Отсюда понимаем, в какие дни и сколько часов исполнитель может работать над нашим проектом.
3. Планируем эффективные и комфортные для заказчика демо. В интересах всех сторон проводить демо как можно чаще. Чем раньше мы получим обратную связь, тем быстрее узнаем об ошибках и скорректируем решение. Заказчику проще анализировать результат небольшими частями. По этим причинам мы запланировали четыре демо с показом пяти шаблонов.

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

Проектирование

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

1. изучение задачи;
2. разработка прототипов;
3. демо.

Во время изучения задачи необходимо понять:

1. какую задачу решает каждый шаблон;
2. какой контент должен содержать;
3. как связан с другими шаблонами;
4. кто и в процессе каких сценариев попадает на страницу шаблона.

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

В процессе разработки прототипов основных сложности было две:

1. Споры между собой. Очень быстро мы их полюбили. Да, они отнимают время, но у нас всегда приводили к нахождению более эффективных решений. Это заряжает и затягивает. Главное, чтобы собеседники не воспринимали критику лично и не привязывались к своему мнению, а были настроены на совместный поиск лучшего решения.
2. Объединение версий. Обычно мы используем Axure RP Pro, где нет командных проектов и контроля версий. Так как сроки были сжаты, не было времени на подбор и внедрение подходящих инструментов, мы просто договаривались, кто и когда обновляет версию прототипа. Это весьма опасно, так как высок риск потерять какие-либо изменения, а еще требует дополнительного времени на коммуникацию и проверки. Для подстраховки мы сохраняли все версии прототипов на локальных компьютерах.

Финальные правки

После того, как заказчик согласовал все шаблоны, мы увидели необходимость «прибраться» в прототипе. В нашем случае внимания потребовали следующие моменты:

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

Правок было мало, но они заметно улучшили качество. Так получилось благодаря использованию мастеров* и договоренностям о стилях стандартных элементов.

*Мастеры — это особые виджеты, которые переиспользуются в рамках проекта. Изменение мастера меняет представление и поведение элементов внутри него во всех местах, где он используется.

Руководство к прототипам

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

Что получилось хорошо

Опыт парного проектирования оказался полезным для нас. При наличии возможности мы планируем практиковать его и на других проектах. Мы заметили следующие преимущества:

1. Работа над проектом идет быстрее. Мы успели к сроку только благодаря решению проектировать вдвоем.
2. В споре рождается истина: в диалоге часто получается придумать более оптимальное решение.
3. Качество выше за счет того, что исполнители находят ошибки друг друга и предлагают способы улучшения.
4. Обмен опытом. Он происходит сам собой в ходе работы. Это полезно для развития исполнителей, а значит, и для повышения качества продукта в целом.
5. Экспертиза не замыкается на одном участнике команды. Я уехала в отпуск со спокойной душой и уверенностью, что мой коллега закроет все оставшиеся по проекту вопросы.

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

Что планируем улучшить

Раз уж мы решили в дальнейшем применять парное проектирование, нужно учесть предыдущие ошибки и решить, как избежать проблем. Мы выделили такой список задач:

1. Подобрать инструмент для коллаборации. Мы выбрали *Axure RP Team и *Figma. Будем использовать оба инструмента и выбирать в зависимости от особенностей конкретного проекта.
2. Поощрять обсуждения решений и споры, развивать навыки переговоров. Выше уже писала, почему это хорошо.
3. Вести руководство в процессе проектирования интерфейса. Так он поможет не только следующим исполнителям, но и нам.

*Axure RP Team включает систему контроля версий и больше подходит для прототипов, так как позволяет создавать сложный интерактив.

*Figma удобнее с точки зрения коллаборации, так как в ней могут работать несколько человек в режиме онлайн. Но она больше ориентирована на дизайн и имеет более узкие возможности для создания интерактива.