Тодд Варфел. Прототипирование. Практическое руководство

   Когда я создаю прототип, то рассматриваю следующие вопросы:
   • использую ли я инструменты или среду, с которыми мне удобно работать;
   • есть ли у меня возможность эффективно передать аудитории этого продукта или его потребителям то, что я считаю нужным;
   • каким временем я располагаю;
   • какая степень точности необходима.
 
   На деле способ прототипирования не важен. Большинство моих прототипов созданы с помощью HTML и AJAX, но это объясняется характером моей работы и потребностями клиентов. Я делал прототипы с помощью Flash, Keynote и на бумаге.
   Когда прототип готов, я повторяю показ и критическое обсуждение. Я использую ту же базовую модель, показывая каждый раз только часть прототипа и предлагая клиенту или пользователю оценить ее. Основная разница в том, что я отвожу больше времени на показ и критику. В остальном процесс не меняется.

   Совет

Проект и набросок

   Проектируйте свой прототип на лекционной доске в ходе показа и обсуждения наброска. Тогда вы сможете по ходу дела вносить изменения в прототип.

Часть 4: тестирование

   Я делю тестирование на две категории: тестирование с клиентами и тестирование с конечными пользователями.

Тестирование с клиентами

   Тестирование с клиентами сочетает в себе показ, критическое обсуждение и создание набросков. Встречи длятся обычно 1,5–3 часа в зависимости от сложности прототипа.
   В ходе встреч я, как обычно, показываю по одному элементу прототипа и обсуждаю его. Вместо списка я использую планшет, чтобы сделать замечания к наброскам. Замечания в большинстве своем представляют собой небольшие метки или краткие комментарии от руки.
   Фиксация изменений на набросках гарантирует, что мы не будем использовать для этого таблицу. Текстовые замечания легко понять неправильно. Наброски помогают снизить этот риск. Их создание допускает сотрудничество, и клиент может внести свой вклад.
   Обычно я следую отработанной схеме при определении необходимых изменений в ходе процесса: больше набросков, меньше записей.
   Когда этап рассмотрения проекта закончен, клиент получает доступ к прототипу. Я прошу потребителя опробовать прототип в течение следующих двух или трех дней.
   Одна из целей создания прототипа – дать целевой аудитории возможность испытать его. Я хочу, чтобы клиент получил опыт работы с прототипом, использовал его. В ходе использования он либо обнаружит новые спорные моменты, либо поймет, что аспекты, казавшиеся ему спорными, на деле к таким не относятся.

Тестирование с конечными пользователями

   Тестирование с конечными пользователями – стандартный тест на удобство использования: 8–12 участников, 5–6 сценариев, аудио– и видеозапись, анализ, а после тестирования – сообщение о результатах. В главе 12 подробнее рассказано о тестировании прототипов.
   При любом тестировании я учитываю полученную в его ходе информацию в следующей версии прототипа.

Резюме

   Я рассказал о процессе прототипирования в Messagefirst. Надеюсь, это поможет новичкам в данной области увидеть, как прототипирование улучшает процесс проектирования. А бывалые профессионалы, возможно, найдут несколько полезных советов для усовершенствования используемых ими процессов прототипирования.
   Прототипирование – процесс, а не продукт, средство достижения цели. Вот несколько важных моментов, о которых нельзя забывать:
   • создание набросков – ключевая часть процесса прототипирования;
   • используйте метод дизайнерской студии: составление набросков; показ и критическое обсуждение. Это помогает быстро и последовательно улучшать прототип;
   • начинайте с количества, исследуя множество идей. Качество придет позже.
 
   В следующих двух главах я рассмотрю 5 различных способов прототипирования и 8 руководящих принципов его выполнения.

Глава 3. Пять моделей прототипирования

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

Модель № 1: коммуникация

   Как я уже говорил, наличие типовой платформы для обсуждения снижает вероятность неправильного толкования. Прототипы – типовой язык образов. В любом конкретном проекте есть несколько разных групп, объединенных общими требованиями: выпускать продукт, поддерживать жизнеспособность компании и зарабатывать деньги. Но не забывайте, что команды говорят на разных языках и имеют собственные планы.
   Доводилось ли вам бывать в одной комнате с группой инженеров и маркетологов? Они не могут общаться друг с другом. То есть говорить-то они могут, но беседы не получается. Они друг друга не понимают. Они используют разные языки. Пригласите в одну комнату разработчика интерфейсов, архитектора информационных систем и специалиста по удобству использования – и можете запастись попкорном и колой, усесться поудобнее и наслаждаться представлением.
   Что же делать? Приготовьте бумагу или лекционную доску и проведите короткое занятие по совместной разработке прототипов. Оно не обязательно будет блестящим, но люди должны начать взаимодействовать и понять суть проекта. Пусть они работают вместе, делают наброски.
   Прототипирование как основа сотрудничества имеет ряд преимуществ. Во-первых, оно создает канал общения между двумя группами. Во-вторых, оно предоставляет им возможность научиться общаться друг с другом. Но главное – вовлечение проектировщиков и разработчиков в совместную реализацию идей помогает им строить взаимоотношения друг с другом.
   Когда проектировщики и разработчики связаны общими отношениями, результат оказывается отличным. Первые скорее дадут вторым попробовать что-то новое, чтобы расширить границы, использовать имеющиеся технологии таким образом, чтобы можно было создать нечто неожиданное, обойти имеющиеся ограничения или изобрести новую технологию (необходимость – мать изобретений). Проектировщики помогут разработчикам понять, что они действительно сделать могут, а чего не могут.
   Разработчики помогут понять сущность технологий, дав проектировщикам доступ к возможностям, о которых те даже не подозревали. Но они могут также «держать проектировщиков в узде»: не позволять им заплыть слишком далеко в море идей и погибнуть во время бури. Разработчики помогают проектировщикам увидеть, какое решение разумно и реализуемо.

   Совет

Используйте возможность сотрудничества

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

   Другая важная выгода от прототипирования как платформы для общения проявляется, когда команды разработчиков находятся далеко друг от друга. По мере роста компании команда становится сегментированной. Группа маркетинга сидит на одном этаже, проектировщики – на другом, разработчики – на третьем. Позже сотрудники могут оказаться в разных зданиях, а то и в разных городах. К тому же существует офшорный бизнес – ваши разработчики могут оказаться в Индии, России или Китае.
   В таких ситуациях общение между сотрудниками затруднительно. В современном мире оно происходит преимущественно с использованием телеконференций, служб мгновенных сообщений или электронной почты, даже если вы сидите в одном здании. А если сама компания находится в Калифорнии, а группа разработчиков – в Восточной Европе или в Азии, то возникают проблемы разных часовых поясов и языкового барьера. Они могут быть решены путем создания прототипов, помогающих установить контакт.
   Прототипы помогают устранить языковой барьер, действуя как платформа для коммуникаций, показывая, а не говоря. Прототипы также не зависят от часовых поясов. Можно потратить больше времени на показ ваших требований команде разработчиков и меньше на рассказ. Обратное тоже верно: команда разработчиков может создать прототип и показать вам, как они поняли ваши пожелания.
   Такой метод «покажи и расскажи» Роберт Хекман-младший называет протокастами (своего рода аналог подкастов^[11]). Хекман создает серию экранов, обычно в программе OmniGraffle, и затем записывает симуляцию работы важных элементов прототипа.

Протокоммуникации

   Роберт Хекман-младший (www.rhjr.net, www.miskeeto.com)
   Несомненно, прототип может кратко рассказать о проекте взаимодействия или даже о приложении в целом. Но создание прототипов – не только материализация идеи для показа заинтересованным сторонам, как будет работать приложение, или оценки реализуемости проекта.
   В конечном счете прототип – средство общения. Его можно использовать для маркетинга или закрытия пробелов в общении между несколькими группами, работающими над проектом, а также для показа функций отдельных мелких элементов, которые нельзя описать словами или статичными картинками. В таких случаях при использовании правильных инструментов можно создавать прототипы, способные стать неотъемлемой частью проектирования.
   Рассмотрим конкретный пример.
   При работе над многофункциональными интерфейсами, например RIA или интерфейс «по требованию» в стиле Web 2.0^[12], иногда сложно детально описать многочисленные состояния одного экрана или одиночное взаимодействие с экраном через отдельные изображения. Чтобы разделить эти взаимодействия на удобоваримые компоненты, я обычно создаю раскадровку – серию эскизов, показывающих состояния экрана по мере взаимодействия. И, конечно, я стараюсь как можно лучше документировать взаимодействия, подробно отражая варианты использования в «документе описания проекта» (Design Description Document, см. www.rhjr.net/ddd). Однако часто этого недостаточно.
   При использовании раскадровок возникают две проблемы. Во-первых, мне необходимо визуализировать переход из одного состояния в другое, но я не имею возможности «проделать» этот путь воочию. Во-вторых, то же приходится делать клиентам. И хотя во многих случаях раскадровки приносят отличный результат, прототипы «оживляют» идею и дают возможность каждому изучать проект таким способом, который не может быть реализован с использованием только статичных изображений, даже в формате раскадровки.
   Теперь я иногда использую для работы по проектированию взаимодействия программу OmniGraffle. Она поддерживает назначение некоторых базовых функций на клики по каркасным представлениям и диаграммам. Это позволяет быстро создать и передать другим очень схематичный набросок прототипа, который можно «прощелкать», в виде документа PDF в любой момент. Таким образом, я не только могу представить документ, который каждый в состоянии открыть и опробовать. Создаваемый мною прототип выше уровнем, чем обычный видеофильм, показывающий работу прототипа и записанный с помощью инструментов SnapzProX (Mac) или Camtasia (Windows).
   Эти «протокасты» (www.rhjr.net/shorty/protocasting), как я их называю, – просто запись моего взаимодействия с прототипом, сопровождаемая голосовыми комментариями по поводу выполняемых действий. Это могут быть размышления, технические ограничения, предложения по улучшению и т. д.
   Протокасты – отличный инструмент не только для более четкого объяснения взаимодействия, чем при использовании раскадровки, но и для обзора удобства использования и важных исследований других характеристик. Я просто фиксирую изображение экрана, когда завершаю одну из задач приложения, и надиктовываю свои критические замечания, прежде чем переходить к следующей. Я даже могу говорить от лица гипотетического пользователя, например: «На самом деле я не понимаю, что означает этот значок… Может, я лучше нажму на эту кнопку и посмотрю, что произойдет… Ой, это не то, чего я хотел».
   Для создания прототипа в формате PDF с помощью OmniGraffle и записи протокаста требуется очень мало усилий и времени. Я могу делать это часто в рамках рабочего процесса. А время, требующееся на создание прототипов и протокастов, с лихвой компенсируется экономией минут и часов на обсуждениях, которые неизменно давали только схематичные результаты.
   Вместо того чтобы тратить много времени на сложный, многофункциональный прототип полного приложения, я создавал прототипы и протокасты только для тех элементов интерфейса, которые действительно требовали пояснений. Эти составляющие обычно очень малы по объему, поэтому на их создание требуется немного времени; но при этом используются все преимущества прототипирования.
   В целом это дешевое, быстрое и безболезненное решение помогало мне обмениваться идеями и критическими замечаниями в случаях, когда слов недостаточно, а полнофункциональный прототип избыточен.
   Эффективное общение – важный элемент успешного проекта.
   Прототипы и протокасты помогают всем следить за ходом разработки и не отставать от коллег при небольших затратах времени и усилий.