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


Процесс создания


Автоматические средства создания прототипов на основе схем страниц — те же Axure RP Pro и Intuitect — я стараюсь не использовать. Они и сами по себе заточены под типовые задачи, так что когда нужно делать что-то нестандартное, все их преимущества теряются. Зато добавляется сложности варки каши из топора. Поэтому мы стараемся делать прототипы вручную, с помощью обычных программ для HTML-верстки.

Процесс достаточно прост. На вход верстальщику поступает набор дизайн-макетов, на выходе — набор HTML-файлов. Расписывать тут особо нечего, лучше обратиться к любой статье по HTML-верстке. Но есть пара моментов, которые важны при создании прототипов:
  1. Продуманные названия файлов. Перечень файлов интерактивного прототипа и их названий лучше расписать перед началом работы. Я стараюсь следовать принципу хлебных крошек — например, “catalog.html”, “catalog-category.html” и “catalog-category-item.html”. Так и в списке файлов ориентироваться проще — часто нужно показать конкретную страницу прототипа. И связность интерфейса лишний раз помогает проверить.
  2. Линковка страниц по ходу верстки. Прототип должен быть связан между собой для удобства юзабилити-тестирования и просто работы с ним. Если страница сверстана и на нее ведут ссылки, в них должен быть URL страницы. Банально, но если этим не заниматься сразу, придется потратить тонну времени на это после окончания верстки. Хотя сам прототип обычно делает ��ерстальщик, связыванием страниц лучше заниматься проектировщику — он знает о взаимодействиях интерфейса гораздо лучше.
  3. Актуальный контент. Для лучшего восприятия прототипа и заказчиком, и пользователями, лучше использовать не lorem ipsum и заменители картинок, а тестовые данные. В последнее время я стараюсь готовить их даже до начала проектирования. Это помогает лучше понять контекст использования системы, отдельные ее особенности. Да и воспринимается гораздо лучше. Плюс по характеру тех же названий новостей проще понять суть проекта и команде разработки, и самому проектировщику.
  4. Не слишком увлекаться валидностью и красотой кода. Прототип будет меняться часто и быстро, так что тратить время на кристально чистый код не нужно — это только тормозит процесс. Лучше переверстать HTML начисто как только закончатся активные эксперименты с прототипом.


Использование прототипа


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

Тут есть вариант увлечься. По-хорошему, конечно, при всех изменениях нужно обновлять весь пакет документации — схемы страниц (wireframes), макеты дизайна, HTML-шаблоны, сценарии юзабилити-тестирования. Но если прогонять для каждой правки весь цикл проектирование -> дизайн -> верстка -> юзабилити-тестирование, можно потратить уйму времени. Которого потом не хватит на проработку более важных решений. Так что если это не многолетний проект и нет армии проектировщиков и дизайнеров, нужно рисковать целостностью документации в пользу более качественного интерфейса. Где-то этапы цикла упрощать, где-то — выкидывать. Точнее, оставлять на следующие циклы. Главное хотя бы вести журнал изменений — чтобы после окончания экспериментов внести их в документацию.

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

Еще один важный момент — поддержка прототипа. Если его использование планируется в качестве одного из источников документации, как это описано в первой части, нужно чтобы он всегда отражал последнюю версию интерфейса. Разработчики часто обращаются к нему как к последней инстанции. И если там что-то устарело — очень вероятно что будет устаревшим �� в уже работающей версии. Значит к прототипу должен быть приписан постоянный верстальщик, фиксирующий все изменения.

Нужно определиться в самом начале, что в проекте является эталоном интерфейса — схемы страниц (wireframes), макеты дизайна или интерактивный прототип. Поддерживать все три слоя дороговато, да и менеджеру не хватит времени на достойный контроль качества всех трех процессов. Правда, по итогу часто все равно получается «шапку и футер смотрите в прототипе, тело страницы — в wireframes». Это во многом решается постоянным присутствием проектировщика, который расскажет, где правильно.


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

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

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