Глава 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 и записи протокаста требуется очень мало усилий и времени. Я могу делать это часто в рамках рабочего процесса. А время, требующееся на создание прототипов и протокастов, с лихвой компенсируется экономией минут и часов на обсуждениях, которые неизменно давали только схематичные результаты. Вместо того чтобы тратить много времени на сложный, многофункциональный прототип полного приложения, я создавал прототипы и протокасты только для тех элементов интерфейса, которые действительно требовали пояснений. Эти составляющие обычно очень малы по объему, поэтому на их создание требуется немного времени; но при этом используются все преимущества прототипирования. В целом это дешевое, быстрое и безболезненное решение помогало мне обмениваться идеями и критическими замечаниями в случаях, когда слов недостаточно, а полнофункциональный прототип избыточен. Эффективное общение – важный элемент успешного проекта. Прототипы и протокасты помогают всем следить за ходом разработки и не отставать от коллег при небольших затратах времени и усилий.

Модель № 2: доработка и проектирование.

В перепроектировании используются две модели: «легкая ретушь» и радикальная переработка.

В первом случае сохраняется облик проекта, вносятся небольшие обновления. Может быть, вводится несколько новых функций, улучшений или исправлений, но в целом проект остается прежним. Это больше похоже на «причесывание», чем на перепроектирование.

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

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

Модель № 3: «продайте» свою идею в компании.

В большинстве случаев работа на благо потребителей и обеспечение большего удобства использования в итоге оказываются крайне выгодными. Чтобы проверить эту гипотезу на практике, консультационная фирма по вопросам удобства использования Teehan+Lax создала фонд UX Fund, который вкладывает средства в компании, нацеленные на обеспечение максимального удобства использования их продуктов, чтобы посмотреть, каковы будут результаты в сравнении с другими компаниями в отрасли.

В ноябре 2007 года этот фонд показал годовые темпы роста в 39,5%[13]. Эта величина сама по себе впечатляет. Она будет еще более впечатляющей, если сравнить ее с общим состоянием рынка в то время. В конечном итоге вложения в удобство использования наиболее интересны для бизнеса, но не все в это верят.

Несколько лет назад я участвовал в разработке одного из первых коммерческих продуктов VoIP (голосовая связь в интернете) на рынке. На самом деле это была моя вторая попытка в данной области; первая стала жертвой краха доткомов.

При поиске решения чаще всего рассматриваются конкурирующие варианты. Другой метод – посмотреть на похожие продукты (например, мобильные телефоны, домашние телефоны, телефоны для офиса). Еще один метод, мой любимый, – исследование новых моделей взаимодействия и решений. Каждая проблема имеет много вариантов решений, и выбрать лучшее иногда сложно.

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

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

Я описал свою идею менеджеру продукта и команде разработчиков, а затем показал им набросок (рис. 3.1). Рассмотрев его, они поняли концепцию. Менеджменту идея понравилась, но команда разработчиков хотела сделать группу статичных полей, поскольку это проще. (Ниже я расскажу, что произошло дальше.).

Прототипы – инструмент «продажи» технической реализуемости и ценности вашей концепции. В некоторых случаях они могут оказаться настолько эффективными, что высшее руководство даст распоряжение команде разработчиков просто создать их.

^{РИС. 3.1. Набросок динамически добавляемых полей.}

Совет. Лучше показать, чем рассказать. Не просто рассказывайте об идеях, а показывайте различные варианты проекта. Сделайте схематичный прототип разных вариантов возможных решений. Предъявите его другим членам команды и получите от них критические отзывы. Так можно использовать прототип в качестве инструмента для создания проектировочных решений.

Модель № 4: тестирование удобства использования.

Помните программу VoIP, о которой шла речь выше? Нам было нужно, чтобы группа разработчиков «купила» ее. Они не были уверены в пользе предложенного решения, и мы решили провести тесты на удобство пользования. Это помогло бы оценить, хороша концепция или нет. Если она эффективна – отлично. Мы смогли бы предоставить полученные данные руководству и разработчикам как сильный аргумент в пользу своей идеи. Если нет, то мы бы об этом быстро узнали и смогли бы рассмотреть другой вариант.

До начала тестов я был уверен, что люди получат рабочую модель с динамическим вводом, но не знал, будет ли она понятна. Я ожидал, что кто-то примет ее сразу, а кто-то поймет только в ходе использования.

Каркасное представление не вызывает бурных восторгов. Я никогда с таким не сталкивался. Дэвид Верба, Adaptive Path

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

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

Нас приятно удивило, что все 12 участников сразу разобрались в модели взаимодействия по требованию. Каждый вводил информацию в текстовое поле, выбирал действие «добавить» и смотрел, как мы моделировали появление нового поля.

Я считаю, что успех объясняется рядом факторов. Во-первых, на экране был только один вариант действия, если не считать кнопки «Сохранить»: кнопка со значком «плюс», которую все воспринимали как кнопку добавления». (В данном случае мы также использовали всплывающую подсказку.) Уменьшение количества вариантов возможных действий сокращает вероятность непонимания. Во-вторых, размещение этого значка рядом с полем ввода помогало сделать вывод: «Это действие относится к этому полю».

Мы могли бы потратить часы, ходя кругами вокруг команды разработчиков и пытаясь «продать» им наше решение. А на деле им надо увидеть пример и результаты, а не просто услышать о них. Тогда они станут более восприимчивы, хотя сомнения останутся.

Однако если тест на удобство использования покажет положительный результат, им будет сложно заявить, что модель нерабочая, и в конце концов они «купят» идею.

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

Модель № 5: оценка технической осуществимости и стоимости.

Итак, у вас есть действительно хорошая концепция. Вы поработали с визуальным дизайнером (или вы сами дизайнер) и получили блестящий прототип. Но остается главный вопрос: можно ли это реализовать?

Множество отличных проектов было отвергнуто разработчиками или технологическими командами, убежденными, что реализовать эти идеи не удастся. Если вы проектировщик и у вас есть отличный проект без прототипа, вам предстоит жестокая и упорная битва.

Иногда на вашей стороне высшее руководство компании, которое заставит разработчиков реализовать ваш проект. А если нет? Если проект действительно сложен? Если в нем непросто разобраться? Тогда необходимо задуматься о создании прототипа.

Чтобы показать техническую реализуемость, не требуется уровень качества, близкий к реально работающей версии. Во многих случаях, если не почти всегда, можно имитировать или симулировать значительную часть пользовательского интерфейса. Этого достаточно, чтобы показать концепцию менеджменту или команде разработчиков, дать им возможность «купить» ее и определить, возможно ли ее реализовать и стоит ли вкладывать в нее деньги.

Реализуемость и целесообразность одинаково важны. Имея программу, вы можете сделать все, что захотите. Нужно лишь вложить в нее достаточно времени и ресурсов. Но в этом и кроется ловушка. Для бизнеса в целом может быть значительно хуже, если на разработку некоторой возможности или нескольких возможностей будут потрачены время и усилия. Окупаемость инвестиций – весомый аргумент и для разработчиков, и для руководства.

Для участников технологической команды окупаемость инвестиций означает соотношение размера кода и его функциональности. Работоспособность они определяют на основе технических аспектов. Один мой подчиненный, инженер, как-то заявил, что определяет работоспособность так: если он открывает окно терминала, то должен увидеть, что на компьютере запущен сервер Apache. А я ожидаю увидеть страницу в окне моего браузера. И обе эти ситуации означают, что Apache «работает».

Для бизнеса окупаемость инвестиций – соотношение вложений и прибыли. Затраты могут быть фиксированными, например при покупке компьютерного оборудования и программного обеспечения для создания рабочего места, или плавающими, например стоимость обслуживания или привлечения и удержания клиентов. Чем сильнее мы хотим получить чистое соотношение, тем больше практического опыта нам нужно, чтобы достичь «просветления»; на деле же бизнес несет финансовую ответственность перед «просветленными» работниками.

Большинство наших прототипов имели качество конечного продукта. HTML, CSS и JavaScript часто используются командой разработчиков для создания финальной версии. Нельзя сказать, что это типично, зато реализуемо.

Если вы создаете прототип с качеством конечного продукта, вопросов о реализуемости не возникает: разработчики получают презентационный образец с полной функциональностью. Единственное препятствие в этом случае – необходимость убедить руководство, что наша концепция хороша и время, необходимое для ее реализации разработчиками, ценно для компании. И эту проблему несложно решить.

Когда мы отдаем прототип пользователям, они видят немедленную выгоду. Предоставьте им несколько дней на тестирование – и они ваши. Если пользователи «купят» прототип, руководство последует их примеру.

Практический пример: IntraLinks. Тодд Заки Варфел. Компания IntraLinks захотела переработать свое веб-приложение для виртуальных защищенных комнат данных. Приложение практически не менялось в течение пяти лет, его нужно было обновить. Какие-то необходимые изменения всегда очевидны; но требовалась помощь извне, чтобы вскрыть не столь явные проблемы. Поэтому они обратились в мою компанию Messagefirst. После четырех дней тестирования мы составили обширный список рабочих и нерабочих функций и представили ряд рекомендаций. Вооружившись этой информацией, команда проектировщиков IntraLinks приступила к задаче. За полтора года они усовершенствовали приложение и создали работающий, качественный, многофункциональный прототип. Это был один из лучших прототипов на моей памяти. Команда проектировщиков IntraLinks выполнила радикальный переход от веб-приложения, которое вело себя как портал, к веб-приложению, похожему на обычное приложение. Итоговый вариант стал результатом эволюции прототипов. Сотрудники IntraLinks не тратили полтора года на один-единственный прототип. Они показали мне ряд предыдущих версий. Многие из тех прототипов значительно отличались от последней версии, которую они были готовы представить пользователям. Они подвергали каждый прототип тестам, и результаты получались разными. В некоторых случаях другие проектировщики не чувствовали, что прототип понятен. Иногда руководству не нравилось направление, задаваемое прототипом будущему продукту. Поэтому был создан ряд прототипов, и постепенно разработчики пришли к тому варианту, который они хотели показать пользователям и услышать их отзывы. Это эволюционный процесс. Возможно, вы удивитесь: «Если это действительно так здорово звучит, то зачем они стали этот прототип тестировать?» Потому что для них это была новая концепция проектирования. Точнее, имелось несколько радикально новых концепций. Проектировщики хотели увидеть реакцию пользователей. Некоторые потребители применяли предыдущую версию в течение пяти лет. Даже если новый проект оказывался «лучше», его запуск стал бы катастрофой, если бы представители целевой аудитории не смогли с ним работать. Во-первых, старая версия была ориентирована на страницы: страница обновлялась после каждого действия, сопровождаемого нажатием кнопки. Это не значило, что приложение нерабочее; просто оно устарело и стало неэффективным. А в новой версии использовалась экранная модель с частично отсутствующими фиксированными состояниями и богатыми возможностями взаимодействия, которую часто называют RIA. В ней была масса современных функций, например перетаскивание, использование правого клика мышью, контекстные меню и автообновление. Как и в любом случае кардинального изменения интерфейса, разработчики хотели узнать, не испортили ли они продукт. А если приложение улучшилось, то насколько? Во-вторых, у них были актуальные вопросы. Смогут ли пользователи воспринять новую концепцию? Обнаружат ли они возможность перетаскивания? Как насчет кликов правой кнопкой и контекстных меню? Если они станут использовать эти возможности на одних участках приложения, на каких еще участках такие возможности будут уместны? Какие концепции не работают вовсе или нуждаются в улучшении? При рассмотрении этих изменений и имеющихся вопросов функциональный прототип с высокой точностью приближения был лучшим способом протестировать проект приложения перед запуском продукта. В целом участники позитивно отреагировали на новый дизайн. Некоторые отметили, что он напоминает другие приложения. Многие возможности взаимодействия, отличавшиеся от таковых в предыдущей версии IntraLinks, были знакомы из-за схожести с проводником Windows, Outlook и другими программами. Команда проектировщиков IntraLinks выгодно использовала знания, полученные при работе с другими приложениями, в своем новом проекте. Примерно половина участников обнаружила новые возможности: перетаскивание, правый клик и контекстные меню. Похоже, пользователи ожидали увидеть их в таком безупречном приложении. Те, кто таких функций не нашел, просто не думали о том, что они могут существовать в подобном веб-приложении. Однако когда их показали, участники очень обрадовались и стали искать их во всех частях приложения. Прототип и тестирование принесли огромный успех, подтвердивший многие решения, которые были приняты при проектировании. Разработчики доказали, что можно успешно совершить переход от программы, похожей на портал, к приложению, и обосновали ценность взгляда изнутри на дополнительные новые концепции систем передачи сообщений и множественных состояний. Для компании IntraLinks способность применять прототипы для изучения различных решений в ходе проектирования была первостепенной. Разработчики использовали прототипы для изучения решений, что особенно ценно при создании новой концепции дизайна или RIA.

Резюме.

Прототипы могут отличаться по качеству и функциональности, но наиболее типичное их использование включает:

• создание среды для совместного общения;

• переработку методом проектирования;

• «продажу» идеи своему начальнику или коллегам в компании;

• тестирование удобства использования;

• оценку технической реализуемости и стоимости.

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

В следующей главе я опишу восемь руководящих принципов прототипирования.