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

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

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

Я даже пытался обучать прототипированию с помощью новых инструментов. До этого я использовал Visio и Fireworks, но в других целях. И я никогда не имел опыта работы с Axure RP Pro.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые технические ограничения, например на размер страницы в 100 КБ, могут быть незаметными в прототипе. Их можно зафиксировать во вспомогательном документе, гораздо меньшем по размерам, чем 60–200 страниц.

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

Сочетание аннотированных каркасных представлений с техническим заданием может представить исходное ви́дение с точностью 70–80%. Остается слишком много возможностей для ошибок.

Что произойдет, если добавить AJAX[4] или другое приложение RIA (Rich Internet Applications – многофункциональные интернет-приложения)? Все начнет разваливаться на части, причем быстро. Ни техническое задание, ни аннотированные каркасные представления не могут отразить правила взаимодействий и переходов.

В основе традиционных взаимодействий лежат страницы. В AJAX и RIA часто используются состояния. Страница или экран могут содержать несколько слоев или виджетов, которые работают независимо друг от друга (и в то же время взаимосвязаны). Например, обновление канала RSS на странице не требует обновления всей страницы. Обновляется только виджет RSS, все остальные элементы остаются прежними.