Есть множество книг, где рассказано, как писать код на HTML, CSS и JavaScript. Немало и публикаций, описывающих разработку программ на Java, Net, PHP, Python или Ruby on Rails. Если вам нужна книга о том, как создавать интерфейсы с помощью Flash, Dreamweaver, Photoshop или Visio, то такие тоже есть.

Нет разве что небольшой, но всеобъемлющей книги только о прототипировании для пользователей-практиков. Точнее, не было. Теперь она есть.

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

Для кого эта книга

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

Что представлено в книге

Книга состоит из трех основных разделов.

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

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

Раздел 3. В последней главе книги рассказано о процессе тестирования прототипа.

Дополнения к книге

На сайте книги (rosenfeldmedia.com/books/prototyping) есть ссылки на ресурсы, посвященные прототипированию, со статьями, видеоуроками, инструментами, шаблонами и примерами, упоминающимися в книге.

Все диаграммы, скриншоты и другие иллюстрации доступны на условиях лицензии Creative Common для загрузки и включения в ваши презентации. Их можно найти на сайте Flickr: www.flickr.com/photos/rosenfeldmedia/sets/.

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

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

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

Сформулировать аргументы в пользу того, что прототипирование необходимо при разработке автомобиля или системы наведения ракет, несложно. Однако доказать, что создание прототипов программных средств даст выгоду при реализации проекта, гораздо труднее.

Фактически это одна из самых сложных проблем.

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

Клиенты и менеджеры, не слишком хорошо знакомые с прототипированием, часто воспринимают его как затратное мероприятие, приносящее мало выгоды (или не приносящее ее вовсе). Чаще всего мне приходится отвечать на такой вопрос: «Как мне заставить босса или клиента заняться прототипированием? Они говорят, что у нас для этого нет ни времени, ни денег».

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

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

Прототипирование продуктивно

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

Процесс прототипирования часто приводит к инновациям и значительной экономии времени, усилий и денег. Он помогает материализовать идеи, создать нечто, что вы можете ощутить, испытать, проработать, протестировать (и просто поиграть с ним).

Прототипирование – возможность показать, рассказать, получить опыт

Прототипирование снижает вероятность неправильного восприятия

Возьмите 60-страничное техническое задание. Посадите в комнате 15 человек. Раздайте им документ. Пусть они его прочтут. Спросите у них, что именно вы разрабатываете. Скорее всего, вы получите 15 разных ответов. Теперь представьте, что в документе 200 страниц. Результат будет еще хуже.

Прототипы – гораздо более конкретное и осязаемое представление системы, которую вы разрабатываете. Они дают ощутимый опыт.

Когда мы перешли от технических заданий к прототипированию, то сразу заметили сокращение количества необходимых уточнений и переделок. Когда-то доля совпадений в интерпретации задания составляла 60–80%; теперь она достигала 90% и даже больше.

Оказалось, на разработку прототипа требуется меньше времени и усилий, чем на создание подробного технического задания и аннотированных каркасных представлений.

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

• Техническое задание объемом 60–200 страниц никто не захочет читать. Это не приносит удовольствия.

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

• Документация не дает возможности увидеть картину в целом. Приходится читать строчку за строчкой.

• Слова слишком часто можно истолковать по-разному.

Кроме того, прототипы имеют ряд преимуществ, которые помогают снизить вероятность неправильного толкования:

• Вы испытываете работу системы, а не просто читаете о ней.

• Прототипы поощряют игровое поведение. Когда вы даете человеку возможность поиграть с прототипом, повышается вероятность, что тот поймет, как должно работать ваше «детище».

Прототипирование позволяет сэкономить время, усилия и деньги

«У нас нет времени создавать прототип».

«Мы не можем позволить себе прототип. У нас на это нет средств».

Сколько раз вам приходилось слышать такие фразы от клиента, одного из ваших начальников или даже коллег-разработчиков?

Я слышал их десятки раз. Да, они имеют под собой некоторые основания. Разработка прототипа не бесплатна, но его преимущества перевешивают затраты, а главное, потери от неиспользования прототипирования.

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

Прототипирование сокращает объем напрасного труда

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

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

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

1. Задание написано не для «тех» людей. Дизайнеры и разработчики редко участвуют в создании технического задания. Его пишет бизнес-аналитик или другой специалист, не имеющий достаточных технических знаний. Поэтому нередко приходится несколько раз переделывать задание.

2. Слишком много времени и усилий. Количество времени, потраченного на создание, рецензирование и пересмотр технических заданий, весьма значительно. При разработке сложных систем этот процесс иногда занимает 3–9 месяцев, а иногда и больше. За это время многое может измениться.

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

4. Неправильное понимание. Количество неправильно понятых мест в техническом задании объемом 60–200 страниц нередко значительно. Непонимание ведет к затратам времени на переделку и отсрочке выпуска продукта.

5. Несущественные детали. Техническое задание нередко заполнено описанием малозначимых или незначимых функциональных возможностей. На их создание и тестирование требуется время. Результат – потеря времени на их описание в техзадании, их внедрение и тестирование (часто такие возможности вообще впоследствии не используются).

6. Слишком позднее обнаружение ошибок. В техническом задании сложно обнаружить ошибки, пока система не начнет работать. Чем позже ошибка обнаружена, тем дороже ее исправление.

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

1. Решения принимаются правильными людьми. Дизайнеры и разработчики могут использовать свои опыт и знания и принимать грамотные решения.

2. Выживание наиболее приспособленных. Генерируется и испытывается множество идей, «выживают» сильнейшие из них.

3. Адаптивность. Прототипы могут быть доработаны с учетом новых возможностей и требований.

4. Снижение вероятности неправильного понимания. Прототип – визуальное, а иногда и физическое представление системы. Его сложнее понять неправильно, чем бумажный документ объемом 60–200 страниц. Снижение вероятности неправильного понимания сокращает количество переделок. Результат – меньшие затраты и более ранний выход на рынок.

5. Точность. При использовании прототипирования создаются продукты, более точно соответствующие желаемым характеристикам. Результат – меньшие потери при проектировании, разработке и переделках.

6. Раннее обнаружение несоответствий. Прототипирование помогает обнаружить несоответствия на ранних стадиях проектирования и разработки. Чем раньше будут выявлены проблемы, тем дешевле обойдется их исправление.

7. Снижение рисков. Прототипирование помогает снизить риски, уменьшая вероятность неправильного понимания и выявляя проблемы на ранних этапах.

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

Прототипирование показывает реальные ценности

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

После этих изменений в компании заметили ряд существенных улучшений:

• На разработку прототипа и 16-страничного дополнительного документа требуется меньше времени и сил, чем на написание 200-страничного техзадания.

• Точность оценки стоимости проекта и его продолжительности повысилась на 50%.

• Количество уточняющих запросов от команды разработчиков сократилось на 80%.

• Количество переделок и исправлений ошибок после выпуска продукта уменьшилось до 25% от уровня предыдущих проектов.

• Вся команда согласилась, что прототипирование проще, чем традиционная модель.

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

Резюме

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

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

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

• прототипирование дает возможность показать и рассказать;

• прототипирование снижает вероятность неправильного восприятия;

• прототипирование позволяет сэкономить время, усилия и деньги;

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

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

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

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

• Все эти процессы относятся к проектированию.

• Для коммуникации при разработке используются искусственно созданные объекты.

• Конечный результат – вещественный объект, который люди могут испытывать и использовать.

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

При создании программного обеспечения о проектировании часто задумываются слишком поздно. Акцент делается на технологиях или функциональности. А в архитектурном или промышленном проекте – именно на проектировании. Форма следует за функциями.

Кроме того, разработка программ воспринимается как производственный процесс, а архитектурное и промышленное проектирование – как ремесло, умение.

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

Отсутствие дизайнерской студии

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

В студии вы создаете проект или прототип и показываете его товарищам по учебе. Они критикуют вашу работу, показывая ее сильные и слабые стороны.

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

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

На что похож процесс прототипирования

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

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

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

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

Марк Сандерс, изобретатель складного велосипеда Strida, описывает на YouTube процесс, который он использовал при создании своего «детища»[7]. Когда я смотрел это описание, я отметил следующее:

• Сандерс не думал о том, какие идеи хорошие, а какие плохие. Он создавал эскизы, чтобы исследовать все возможные идеи.

• Когда эскизов накапливалось много, он оценивал их, исходя из первоначальных целей создания продукта. Так отбирались лучшие идеи.

• Эскизы использовались только до этого этапа. Чтобы убедиться в работоспособности идей, ему приходилось создавать модели или прототипы.

• Эскизы сыграли решающую роль в усовершенствовании проекта и разработке модели Strida2.

В своем видео Марк описывает достаточно типичный процесс прототипирования, включающий следующие элементы:

• создание эскизов;

• оценку;

• создание модели;

• испытание.

В моей компании Messagefirst используется подход, подобный описанному Марком, но с небольшими отличиями. Мы берем страницу из книги дизайнерской студии и применяем модель с демонстрацией проекта и его критической оценкой. Так что наш видоизмененный процесс выглядит так:

• создание эскизов (набросков на демонстрационных досках или бумаге, программного кода);

• демонстрация и критическая оценка;

• моделирование (прототипирование);

• тестирование.

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

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

^{РИС. 2.1. Диаграмма итеративного процесса разработки и критических оценок}

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

Теперь давайте подробно рассмотрим наш процесс прототипирования, начиная с создания наброска.

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

Я предпочитаю устанавливать рамки для «времени делать наброски». Это заставляет сотрудников работать быстро и не вдаваться в детали.

Цель создания набросков – не конкретизация идей (этим мы занимаемся на стадии разработки прототипа), а определение концепций, «вытаскивание» их из головы максимально быстро и переход к следующей стадии.

Совет

Количество важнее качества

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

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

^{РИС. 2.2. Набросок модуля настроек для видео на Vimeo, демонстрирующий толщину линий и пометки}[8]

Совет

Быстрый и яростный

Установите ограничения времени на создание набросков.

Я предпочитаю отводить на это 10–30 минут, а затем переходить к показу и критической оценке. Такой короткий период заставляет фокусироваться на продуктивных идеях, не вдаваясь в подробности.

Большинство наших набросков делается на бумаге с использованием специальных планшетов. Планшет – просто лист бумаги с набором небольших окошек-шаблонов. Он подобен планшету для раскадровки.

Вот как выглядит один из наших планшетов для набросков (рис. 2.3).[9]

^{РИС. 2.3. Пример планшета с несколькими набросками}

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

Совет

Хорошая идея не приходит одна

Использование планшета для набросков – отличный способ выдать несколько идей. Небольшое пространство стимулирует обдумывание отдельных элементов интерфейса. Такой планшет также подойдет для небольшой раскадровки, если необходимо описать проект AJAX или RIA.

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

Рассмотрим преимущества и недостатки набросков на бумаге, лекционных досках и в программном коде.

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

Одно из преимуществ набросков в коде – возможность их превращения в прототип. В условиях роста числа JavaScript-библиотек, CSS-фреймворков и шаблонизаторов вроде Ruby on Rails создавать наброски в коде становится все легче.

Преимущества

• Делать наброски в коде все легче, поскольку инструментов для этого становится больше.

• Наброски «оживают» – их можно опробовать на практике.

• Это дает возможность эффективно использовать написанный код.

Недостатки

• Не каждый умеет писать код.

• Для этого необходим компьютер.

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

• Это занимает больше времени, чем создание набросков на бумаге или лекционной доске.

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

Преимущества

• Обеспечивает возможность совместной работы.

• На лекционной доске может рисовать каждый.

• Одновременно могут участвовать несколько человек.

• Не нужен компьютер.

• Внести изменения очень просто: достаточно стереть рисунок и изобразить что-то новое.

Недостатки

• Перенести лекционную доску сложнее, чем код или лист бумаги.

• Наброски статичны.

• Перенести наброски с доски на рабочие материалы иногда сложно[10].

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

Преимущества

• Обеспечивает возможность совместной работы.

• На бумаге может рисовать каждый.

• Может участвовать несколько человек одновременно.

• Не нужен компьютер.

• Внести изменения просто – достаточно добавить в рисунок нужные элементы или взять другой лист бумаги.

• Этим можно заниматься когда угодно и где угодно.

• Наброски легко перемещать.

Недостатки

• Наброски статичны.

Демонстрация и критика – вероятно, наиболее важная часть процесса прототипирования. На этой стадии мы сосредоточиваемся на качестве.

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

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

Представляя наброски на обсуждение, мы часто крепим их к стене, как показано на рис. 2.4.

^{РИС. 2.4. Показ набросков в ходе их критического разбора в дизайнерской студии}

Будьте кратки. Как я упоминал ранее, демонстрация и критика – вторая стадия, для которой мы устанавливаем жесткие рамки. Фактически на нее выделяется еще меньше времени, чем на набросок. Я стараюсь ограничивать время демонстрации двумя минутами, а обсуждение – тремя.

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

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

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

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

Резюме

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

Прототипирование – процесс, а не продукт, средство достижения цели. Вот несколько важных моментов, о которых нельзя забывать:

• создание набросков – ключевая часть процесса прототипирования;

• используйте метод дизайнерской студии: составление набросков; показ и критическое обсуждение. Это помогает быстро и последовательно улучшать прототип;

• начинайте с количества, исследуя множество идей. Качество придет позже.

В следующих двух главах я рассмотрю 5 различных способов прототипирования и 8 руководящих принципов его выполнения.

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

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

А когда мы с Джедом Вудом обсуждали взаимодействие с пользователями, возникло гениальное определение. Джед помог мне понять, что такое прототипирование: способ разработки своих проектов.

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

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

Как я уже говорил, наличие типовой платформы для обсуждения снижает вероятность неправильного толкования. Прототипы – типовой язык образов. В любом конкретном проекте есть несколько разных групп, объединенных общими требованиями: выпускать продукт, поддерживать жизнеспособность компании и зарабатывать деньги. Но не забывайте, что команды говорят на разных языках и имеют собственные планы.

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

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

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

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

Разработчики помогут понять сущность технологий, дав проектировщикам доступ к возможностям, о которых те даже не подозревали. Но они могут также «держать проектировщиков в узде»: не позволять им заплыть слишком далеко в море идей и погибнуть во время бури. Разработчики помогают проектировщикам увидеть, какое решение разумно и реализуемо.

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

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

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

Такой метод «покажи и расскажи» Роберт Хекман-младший называет протокастами (своего рода аналог подкастов[11]). Хекман создает серию экранов, обычно в программе OmniGraffle, и затем записывает симуляцию работы важных элементов прототипа.