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

Прототипирование интерфейсов – это процесс, при котором команда (разработчики, тестировщики, бизнес-аналитики, Product Owner и другие), которая работает над продуктом/проектом, получает некий прототип будущего возможного дизайна для web приложения или сервиса. Он является одним из ключевых этапов в создании продукта, сервиса или приложения. Этот процесс важен как на начальных стадиях (планирование будущего проекта), так и на стадии активной разработки.

Прототипирование интерфейсов имеет целый ряд преимуществ в случаях, когда:

• отсутствует четкое ТЗ (техническое задание);
• нет возможности “дергать” дизайнера каждый раз, когда необходимы правки в дизайне;
• необходимо обсудить подходы в UI/UX и выбрать лучший;
• необходимо рассмотреть совершенно разные подходы в реализации задачи;
• в разрабатываемой системе присутствует полноценный UI (набор готовых компонентов интерфейса).

Рассмотрим каждый пункт отдельно:

1. Отсутствует четкое ТЗ

В силу ряда причин заказчик не всегда уверен в том, чего именно он хочет и каким образом “это” должно функционировать - он часто видит лишь общую картину/концепт. Причинами часто могут служить недостаточная осведомленность в технической стороне задачи или же отсутствие уже реализованных решений в реальной жизни (среди конкурирующих продуктов и сервисов). К примеру, на моем текущем проекте (MotoCMS 3) мы работаем по методологии Scrum и у нас для решения подобных моментов существуют груминги (процесс предварительного ознакомления команды разработчиков с задачами для следующих спринтов, в присутствии заказчика). На грумингах прототипизатор (человек, занимающийся созданием прототипов пользовательского интерфейса) предоставляет “возможную” реализацию интерфейса под конкретно взятую задачу, которую в ближайшем будущем команда должна будет взять в работу. Команда в ходе обсуждения с заказчиком может вносить корректировки или, в некоторых случаях, полностью изменять предоставленный протопип до того момента, пока не будет достигнуто соглашение между командой и заказчиком. Прототипы интерфейсов (wireframe-ы, в данном случае) позволяют быстро менять первоначальную картину исходя из возможностей или новых требований.

2. Отсутствует постоянный дизайнер

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

3. Необходимо обсудить подходы в UI/UX и выбрать лучший

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

4. Необходимо рассмотреть совершенно разные подходы в реализации задачи

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

5. В системе присутствует полноценный UI (набор готовых компонентов интерфейса)

У нас на проекте присутствует готовый набор UI компонентов, с помощью которого можно с легкостью и без особых временных затрат “собирать” новые разделы или страницы приложения, используя только wireframe-ы. UI состоит из всевозможных кнопок, форм, блоков, панелей и виджетов, которые так или иначе могут встречаться в интерфейсе продукта. Это позволило почти полностью уйти от необходимости рисовать дизайны для каждого нового спринта или задачи.

Инструменты

Существуют десятки готовых решений (как desktop-ных приложений, так и cloud-based). Мы используем Balsamiq. Одним из главных преимуществ является существование онлайн-версии данного продукта, что позволяет получать доступ к просмотру и редактированию wireframe-ов прямо в браузере любого устройства. Также Balsamiq по большей части ориентирован на разработку именно web приложений (имеет достаточный набор стандартных для html элементов управления, есть возможность демонстрировать различные состояния элементов форм, например, активное поле ввода, выбранные состояния и т.д.). В нашем случае, после утверждения финальной версии wireframe-ов для конкретной задачи, они экспортируются в формате png и прикрепляются к соответствующей user story в Jira.

Как организовать грамотное прототипирование?

Нужно просто пробовать. Главное - не бояться “ужасного вида” и “оторванности” прототипов от реального дизайна. Естественно, ни в коем случае не советую реализовывать alpha-вариант будущего приложения с использованием прототипов, созданных в том же Balsamiq или любом другом сервисе. Прототипы важны для того, чтобы заложить фундамент и архитектуру будущего приложения, но не стоит принимать прототипы как дизайн и тестировать приложение на их основе (это пройденный этап и очень горький опыт 😐). Они в большей степени служат лишь для упрощения понимания и визуализации поставленной задачи разными членами команды проекта. Реализацию alpha-версии на ранних стадиях работы над проектом стоит доверить команде разработчиков (по крайней мере в тех случаях, когда финальных дизайнов еще нет).

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

Также не стоит заострять внимание на мелких деталях интерфейса. Все эти моменты будут проработаны дизайнером и front-end разработчиком.

Идеальным случаем является наличие полноценного набора всевозможных компонентов (UI), который тщательно проработан дизайнером и front-end разработчиком. Это даст огромный прирост к скорости разработки и внедрения новой функциональности, так как исключается время ожидания дизайнов, и дополнительно к этому практически любой новый раздел или страница приложения собирается из готовых деталей как конструктор.

Стоит ли тестировать прототипы?

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

Все что описано выше “основано на реальных событиях”. Основными косяками являются: попытки тестировать прототип приложения на основе wireframe “дизайнов” и излишнее внимание к деталям. Основные успешные примеры и выводы: практически полная независимость от команды дизайнеров (да, чтобы прийти к этому нужны время, силы и набор готовых компонентов UI, но это вполне реально); максимально быстрое принятие решений касательно будущих частей интерфейса приложения; возможность предварительной оценки сложности задачи при отсутствии финальных дизайнов.