В первой части материала я расписал цели создания интерактивного прототипа. Теперь расскажу о процессе работы над ним в нашей компании. Работа над интерактивным прототипом начинается после того как спроектированы схемы страниц (wireframes) и отрисован их визуальный дизайн. Процесс в среднем длится пару недель, после чего начинается его самостоятельное плавание. Модель интерфейса изучают и комментируют заказчик, пользователи и разработчики.
Сам по себе интерактивный прототип — это сверстанные в HTML и соединенные между собой ключевые страницы системы. Подхода может быть два.
Сделать его можно быстро и дешево, особенно если использовать инструменты быстрого прототипирования вроде Axure RP Pro или плагина к MS Visio Intuitect. Еще более здорово, что получить его можно уже на раннем этапе проектирования, не дожидаясь отрисовки визуального дизайна. А значит и начать юзабилити-тестирование — тоже.
Но, во-первых, многие по опыту знают, что показывать сырые материалы (те же wireframes) неподготовленному клиенту опасно. Можно провести много времени за убеждением его в том, что это еще не дизайн системы и дальше будет по-другому. Во-вторых, когда дело доходит до вполне конкретных пикселей, а не относительных величин и набросков, восприятие интерфейса может сильно поменяться. Ну и в-третьих, при проектировании лучше заниматься только одним «слоем» работ. Как только начинаются постоянные переключения между задачами разного характера — продумыванием диаграмм и схем и проработкой кликов и наведений курсора мыши — снижается и продуктивность, и качество, и глубина проработки.
Делать его стоит в тех случаях, когда либо бюджет очень маленький и денег хватит только на простейшую модель. Либо наоборот, когда денег и времени хватит на оба прототипа — и ранний черно-белый, и нормальный цветной. Хотя есть еще один отличный кейс применения ранних моделей. Недавно к нам пришел клиент, который принес с собой созданный в Axure прототип продукта. В нем были все ключевые страницы будущего сервиса и нам было гораздо проще тут же оценить сроки и стоимость его проектирования и разработки. Этап проектирования «начистовую» требовался в любом случае, зато предпроектный анализ здорово упростился — первоначальный прототип уже дал многие ответы.
Гораздо проще общаться с заказчиком, пользователями и разработчиками, имея на руках модель интерфейса, которая выглядит максимально похоже на финальный результат. Тут как раз начинают работать те бонусы для аудитории, которые описаны в первой части материала. Заказчик может с гораздо большим успехом показать прототип инвесторам или руководству, партнерам или рекламодателям. Не нужно, как в случае со схемами страниц (wireframes), на каждом этапе долго и не всегда результативно объяснять, что это еще не дизайн. Юзабилити-тестирование также проходит с меньшими оговорками, да и эффект от него ближе к реальности. Ну и в общении с разработчиками выручает постоянно.
Правда, делать цветной прототип может быть достаточно дорого и долго. Кросс-браузерностью на этом этапе мы стараемся не заниматься — обычно берем IE7 и, возможно, Firefox. Во-первых, это отнимает много времени. Во-вторых, с прототипом идут постоянные эксперименты и делать их нужно быстро, так что тут не до поддержки аккуратности и логичность кода. Поэтому его в любом случае нужно будет переверстывать с нуля. Практика показывает, что геморрой и туча багов при разработке не стоит экономии на переделке. Так что работы верстальщику тут найдется много.
В некоторых случаях выгодно не заморачиваться с юзабилити-тестированием прототипа, а быстро запустить бета-версию системы. И уже получая обратную связь, быстро вносить корректировки — это как раз случай с вебдванолевой постоянной бетой. Например, в случае с разработкой новой версии EPAM PMC мы так и поступили. Но такой подход больше подходит для проектов с гарантированной и лояльной аудиторией, чем для тиражных (будь то количество проданных копий или объем трафика) продуктов с сильными конкурентами.
Тратить большие бюджеты на абсолютно полный прототип мало кто готов, да и смысл это имеет только для уж очень долгосрочных проектов. Поэтому важно выбрать оптимальный набор страниц и взаимодействий, которые войдут в модель интерфейса. Вот на что стоит ориентироваться:
В прототипе стоит показать и проверить по крайней мере основные возможности системы. Например, для сайта поиска работы это будут ведение резюме и вакансий, поиск подходящей работы и кандидатов, предложения работы и отклики на вакансии, оперативное получение информации о новых вакансиях и резюме. Значит нам нужны как минимум страницы профайлов работодателя и соискателя, формы добавления вакансии и редактирования резюме, списки предложений и страница одного из них, архив откликов и предложений работы, страница настройки уведомлений.
Для этого стоит объединить все важные функции системы в реальные сценарии работы с ней. К первоначальному составу стоит добавить служебные функции. Например, для того же сайта поиска работы нужно чтобы со страницы информации о вакансии можно было бы отправить отклик на нее. А после отправки пользователю было бы показано сообщение о том, что все прошло хорошо. И, возможно, что он уже отправлял отклик на другую вакансию этого работодателя. Значит нужно сделать версию страницы информации о вакансии с сообщением об успехе. Либо, например, передавать в cookies данные о том, что на ней нужно показать скрытый блок с этим сообщением.
Еще лучше, если будут показаны более сложные сценарии. Например, пользователь получил приглашение зарегистрироваться на сайте. После заполнения формы регистрации, ему предложили заполнить резюме. А после заполнения резюме — найти подходящие вакансии по нескольким критериям. В список необходимых в прототипе страниц добавляются ввод приглашения, регистрация, авторизация и поиск вакансий на основе резюме. Ну и не забываем, что кроме соискателя у нас есть еще и работодатель — ему может понадобиться оплатить услуги по размещению вакансий.
Возможно, что заказчику может понадобиться показать будущему партнеру или инвестору дополнительные возможности будущего продукта. Например, импорт списка вакансий из MS Excel-файла или интранет-системы. Так что список необходимых страниц снова расширится.
Теперь понятно, что, в каком виде и объеме нужно делать. Пора браться за строй-инструменты.
Читайте первую часть материала с классификацией интерактивных прототипов и третью, с особенностями процесса их создания.
Оригинал: Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 2. Подходы к процессу
Подходы к прототипированию
Сам по себе интерактивный прототип — это сверстанные в HTML и соединенные между собой ключевые страницы системы. Подхода может быть два.
Черно-белый прототип на основе схем страниц
Сделать его можно быстро и дешево, особенно если использовать инструменты быстрого прототипирования вроде Axure RP Pro или плагина к MS Visio Intuitect. Еще более здорово, что получить его можно уже на раннем этапе проектирования, не дожидаясь отрисовки визуального дизайна. А значит и начать юзабилити-тестирование — тоже.Но, во-первых, многие по опыту знают, что показывать сырые материалы (те же wireframes) неподготовленному клиенту опасно. Можно провести много времени за убеждением его в том, что это еще не дизайн системы и дальше будет по-другому. Во-вторых, когда дело доходит до вполне конкретных пикселей, а не относительных величин и набросков, восприятие интерфейса может сильно поменяться. Ну и в-третьих, при проектировании лучше заниматься только одним «слоем» работ. Как только начинаются постоянные переключения между задачами разного характера — продумыванием диаграмм и схем и проработкой кликов и наведений курсора мыши — снижается и продуктивность, и качество, и глубина проработки.
Делать его стоит в тех случаях, когда либо бюджет очень маленький и денег хватит только на простейшую модель. Либо наоборот, когда денег и времени хватит на оба прототипа — и ранний черно-белый, и нормальный цветной. Хотя есть еще один отличный кейс применения ранних моделей. Недавно к нам пришел клиент, который принес с собой созданный в Axure прототип продукта. В нем были все ключевые страницы будущего сервиса и нам было гораздо проще тут же оценить сроки и стоимость его проектирования и разработки. Этап проектирования «начистовую» требовался в любом случае, зато предпроектный анализ здорово упростился — первоначальный прототип уже дал многие ответы.
Цветной прототип, основанный на принятом заказчиком визуальном дизайне системы
Гораздо проще общаться с заказчиком, пользователями и разработчиками, имея на руках модель интерфейса, которая выглядит максимально похоже на финальный результат. Тут как раз начинают работать те бонусы для аудитории, которые описаны в первой части материала. Заказчик может с гораздо большим успехом показать прототип инвесторам или руководству, партнерам или рекламодателям. Не нужно, как в случае со схемами страниц (wireframes), на каждом этапе долго и не всегда результативно объяснять, что это еще не дизайн. Юзабилити-тестирование также проходит с меньшими оговорками, да и эффект от него ближе к реальности. Ну и в общении с разработчиками выручает постоянно.Правда, делать цветной прототип может быть достаточно дорого и долго. Кросс-браузерностью на этом этапе мы стараемся не заниматься — обычно берем IE7 и, возможно, Firefox. Во-первых, это отнимает много времени. Во-вторых, с прототипом идут постоянные эксперименты и делать их нужно быстро, так что тут не до поддержки аккуратности и логичность кода. Поэтому его в любом случае нужно будет переверстывать с нуля. Практика показывает, что геморрой и туча багов при разработке не стоит экономии на переделке. Так что работы верстальщику тут найдется много.
Я успел побывать на многих фронтах веб-разработки, в том числе и в HTML-верстке. Шаблоны верстаются и объединяются в подобие прототипа и для обычных сайтов. Но это достаточно простые и понятные вещи, там не стоит задача экспериментов с интерфейсом — идет скорее просто обеспечение разработки.
В некоторых случаях выгодно не заморачиваться с юзабилити-тестированием прототипа, а быстро запустить бета-версию системы. И уже получая обратную связь, быстро вносить корректировки — это как раз случай с вебдванолевой постоянной бетой. Например, в случае с разработкой новой версии EPAM PMC мы так и поступили. Но такой подход больше подходит для проектов с гарантированной и лояльной аудиторией, чем для тиражных (будь то количество проданных копий или объем трафика) продуктов с сильными конкурентами.
Состав прототипа
Тратить большие бюджеты на абсолютно полный прототип мало кто готов, да и смысл это имеет только для уж очень долгосрочных проектов. Поэтому важно выбрать оптимальный набор страниц и взаимодействий, которые войдут в модель интерфейса. Вот на что стоит ориентироваться:
Ключевая функциональность
В прототипе стоит показать и проверить по крайней мере основные возможности системы. Например, для сайта поиска работы это будут ведение резюме и вакансий, поиск подходящей работы и кандидатов, предложения работы и отклики на вакансии, оперативное получение информации о новых вакансиях и резюме. Значит нам нужны как минимум страницы профайлов работодателя и соискателя, формы добавления вакансии и редактирования резюме, списки предложений и страница одного из них, архив откликов и предложений работы, страница настройки уведомлений.
Сценарии работы пользователя с системой
Для этого стоит объединить все важные функции системы в реальные сценарии работы с ней. К первоначальному составу стоит добавить служебные функции. Например, для того же сайта поиска работы нужно чтобы со страницы информации о вакансии можно было бы отправить отклик на нее. А после отправки пользователю было бы показано сообщение о том, что все прошло хорошо. И, возможно, что он уже отправлял отклик на другую вакансию этого работодателя. Значит нужно сделать версию страницы информации о вакансии с сообщением об успехе. Либо, например, передавать в cookies данные о том, что на ней нужно показать скрытый блок с этим сообщением.
Еще лучше, если будут показаны более сложные сценарии. Например, пользователь получил приглашение зарегистрироваться на сайте. После заполнения формы регистрации, ему предложили заполнить резюме. А после заполнения резюме — найти подходящие вакансии по нескольким критериям. В список необходимых в прототипе страниц добавляются ввод приглашения, регистрация, авторизация и поиск вакансий на основе резюме. Ну и не забываем, что кроме соискателя у нас есть еще и работодатель — ему может понадобиться оплатить услуги по размещению вакансий.
Возможно, что заказчику может понадобиться показать будущему партнеру или инвестору дополнительные возможности будущего продукта. Например, импорт списка вакансий из MS Excel-файла или интранет-системы. Так что список необходимых страниц снова расширится.
Теперь понятно, что, в каком виде и объеме нужно делать. Пора браться за строй-инструменты.
Читайте первую часть материала с классификацией интерактивных прототипов и третью, с особенностями процесса их создания.
Оригинал: Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 2. Подходы к процессу
