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

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

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

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 удобнее с точки зрения коллаборации, так как в ней могут работать несколько человек в режиме онлайн. Но она больше ориентирована на дизайн и имеет более узкие возможности для создания интерактива.