Я уже писал про классификацию и два основных пути создания интерактивных прототипов. В большинстве случаев мы делаем как раз цветной прототип. По сути, это обычная верстка HTML-шаблонов страниц на основе визуального дизайна, включающая в себя JavaScript-взаимодействия. Разница в том, что эти шаблоны еще много раз поменяются и дополнятся.
Автоматические средства создания прототипов на основе схем страниц — те же Axure RP Pro и Intuitect — я стараюсь не использовать. Они и сами по себе заточены под типовые задачи, так что когда нужно делать что-то нестандартное, все их преимущества теряются. Зато добавляется сложности варки каши из топора. Поэтому мы стараемся делать прототипы вручную, с помощью обычных программ для HTML-верстки.
Процесс достаточно прост. На вход верстальщику поступает набор дизайн-макетов, на выходе — набор HTML-файлов. Расписывать тут особо нечего, лучше обратиться к любой статье по HTML-верстке. Но есть пара моментов, которые важны при создании прототипов:
После того как прототип готов, начинается его обсуждение и юзабилити-тестирование. А значит пачками приходят изменения. Причем далеко не всегда понятно, как именно нужно подправить какой-нибудь элемент интерфейса. Даже после долгих обсуждений и серии набросков есть как минимум пара альтернативных решений. Лучше всего реализовать все спорные альтернативы — подготовить несколько версий тех страниц прототипа, где находятся элементы для обсуждения.
Тут есть вариант увлечься. По-хорошему, конечно, при всех изменениях нужно обновлять весь пакет документации — схемы страниц (wireframes), макеты дизайна, HTML-шаблоны, сценарии юзабилити-тестирования. Но если прогонять для каждой правки весь цикл проектирование -> дизайн -> верстка -> юзабилити-тестирование, можно потратить уйму времени. Которого потом не хватит на проработку более важных решений. Так что если это не многолетний проект и нет армии проектировщиков и дизайнеров, нужно рисковать целостностью документации в пользу более качественного интерфейса. Где-то этапы цикла упрощать, где-то — выкидывать. Точнее, оставлять на следующие циклы. Главное хотя бы вести журнал изменений — чтобы после окончания экспериментов внести их в документацию.
Про сам процесс юзабилити-тестирования лучше расписать в отдельной статье. А еще лучше — обратиться к отличному пособию Влада Головача. Отмечу только, что по ходу работ удобнее показывать промежуточные результаты коллегам или просто знакомым. Есть, например, хорошие практики экспертных оценок. А вот тестирование проводить уже в конце или на нескольких важных промежуточных точках.
Еще один важный момент — поддержка прототипа. Если его использование планируется в качестве одного из источников документации, как это описано в первой части, нужно чтобы он всегда отражал последнюю версию интерфейса. Разработчики часто обращаются к нему как к последней инстанции. И если там что-то устарело — очень вероятно что будет устаревшим и в уже работающей версии. Значит к прототипу должен быть приписан постоянный верстальщик, фиксирующий все изменения.
Главное не забывать, для чего и для кого делается интерактивный прототип. Тогда он будет не дороговатой игрушкой для кого-то из участников процесса, а здорово поможет на многих этапах работы над проектом. Да и продать идею инвестору или партнеру, имея на руках осязаемую вещь вместо просто набора обещаний на бумаге, намного проще.
Читайте первую часть материала с классификацией интерактивных прототипов и вторую, с описанием подходов к процессу их создания.
Оригинал: Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 3. Особенности процесса
Процесс создания
Автоматические средства создания прототипов на основе схем страниц — те же Axure RP Pro и Intuitect — я стараюсь не использовать. Они и сами по себе заточены под типовые задачи, так что когда нужно делать что-то нестандартное, все их преимущества теряются. Зато добавляется сложности варки каши из топора. Поэтому мы стараемся делать прототипы вручную, с помощью обычных программ для HTML-верстки.
Процесс достаточно прост. На вход верстальщику поступает набор дизайн-макетов, на выходе — набор HTML-файлов. Расписывать тут особо нечего, лучше обратиться к любой статье по HTML-верстке. Но есть пара моментов, которые важны при создании прототипов:
- Продуманные названия файлов. Перечень файлов интерактивного прототипа и их названий лучше расписать перед началом работы. Я стараюсь следовать принципу хлебных крошек — например, “catalog.html”, “catalog-category.html” и “catalog-category-item.html”. Так и в списке файлов ориентироваться проще — часто нужно показать конкретную страницу прототипа. И связность интерфейса лишний раз помогает проверить.
- Линковка страниц по ходу верстки. Прототип должен быть связан между собой для удобства юзабилити-тестирования и просто работы с ним. Если страница сверстана и на нее ведут ссылки, в них должен быть URL страницы. Банально, но если этим не заниматься сразу, придется потратить тонну времени на это после окончания верстки. Хотя сам прототип обычно делает верстальщик, связыванием страниц лучше заниматься проектировщику — он знает о взаимодействиях интерфейса гораздо лучше.
- Актуальный контент. Для лучшего восприятия прототипа и заказчиком, и пользователями, лучше использовать не lorem ipsum и заменители картинок, а тестовые данные. В последнее время я стараюсь готовить их даже до начала проектирования. Это помогает лучше понять контекст использования системы, отдельные ее особенности. Да и воспринимается гораздо лучше. Плюс по характеру тех же названий новостей проще понять суть проекта и команде разработки, и самому проектировщику.
- Не слишком увлекаться валидностью и красотой кода. Прототип будет меняться часто и быстро, так что тратить время на кристально чистый код не нужно — это только тормозит процесс. Лучше переверстать HTML начисто как только закончатся активные эксперименты с прототипом.
Использование прототипа
После того как прототип готов, начинается его обсуждение и юзабилити-тестирование. А значит пачками приходят изменения. Причем далеко не всегда понятно, как именно нужно подправить какой-нибудь элемент интерфейса. Даже после долгих обсуждений и серии набросков есть как минимум пара альтернативных решений. Лучше всего реализовать все спорные альтернативы — подготовить несколько версий тех страниц прототипа, где находятся элементы для обсуждения.
Тут есть вариант увлечься. По-хорошему, конечно, при всех изменениях нужно обновлять весь пакет документации — схемы страниц (wireframes), макеты дизайна, HTML-шаблоны, сценарии юзабилити-тестирования. Но если прогонять для каждой правки весь цикл проектирование -> дизайн -> верстка -> юзабилити-тестирование, можно потратить уйму времени. Которого потом не хватит на проработку более важных решений. Так что если это не многолетний проект и нет армии проектировщиков и дизайнеров, нужно рисковать целостностью документации в пользу более качественного интерфейса. Где-то этапы цикла упрощать, где-то — выкидывать. Точнее, оставлять на следующие циклы. Главное хотя бы вести журнал изменений — чтобы после окончания экспериментов внести их в документацию.
Про сам процесс юзабилити-тестирования лучше расписать в отдельной статье. А еще лучше — обратиться к отличному пособию Влада Головача. Отмечу только, что по ходу работ удобнее показывать промежуточные результаты коллегам или просто знакомым. Есть, например, хорошие практики экспертных оценок. А вот тестирование проводить уже в конце или на нескольких важных промежуточных точках.
Еще один важный момент — поддержка прототипа. Если его использование планируется в качестве одного из источников документации, как это описано в первой части, нужно чтобы он всегда отражал последнюю версию интерфейса. Разработчики часто обращаются к нему как к последней инстанции. И если там что-то устарело — очень вероятно что будет устаревшим и в уже работающей версии. Значит к прототипу должен быть приписан постоянный верстальщик, фиксирующий все изменения.
Нужно определиться в самом начале, что в проекте является эталоном интерфейса — схемы страниц (wireframes), макеты дизайна или интерактивный прототип. Поддерживать все три слоя дороговато, да и менеджеру не хватит времени на достойный контроль качества всех трех процессов. Правда, по итогу часто все равно получается «шапку и футер смотрите в прототипе, тело страницы — в wireframes». Это во многом решается постоянным присутствием проектировщика, который расскажет, где правильно.
Главное не забывать, для чего и для кого делается интерактивный прототип. Тогда он будет не дороговатой игрушкой для кого-то из участников процесса, а здорово поможет на многих этапах работы над проектом. Да и продать идею инвестору или партнеру, имея на руках осязаемую вещь вместо просто набора обещаний на бумаге, намного проще.
Читайте первую часть материала с классификацией интерактивных прототипов и вторую, с описанием подходов к процессу их создания.
Оригинал: Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 3. Особенности процесса
