За последние пять лет, в течении которых я занимаюсь проектирование сайтов, я точно понял, что прототип будет полезен всегда: будь это одностраничный сайт, типовой интернет магазин или новая социальная сеть (просто далеко не всегда за это стоит платить 300 000 рублей и нередко суммы в сто раз меньше будет достаточно). Одна из главных задач, которые решается на стадии прототипирования — это вывести на передний план контент будущего сайта и спроектировать информацию, когда начинается графический дизайн о информации все перестают помнить и это обычно создает проблемы.

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

Собственно я сам и наша компания используем для проектирования Adobe Indesign и в итоге мы получаем бумажный прототип и интерактивные PDF прототип, позже мы еще делаем HTML прототип, но уже на базе готового дизайна. Я придерживаюсь той позиции, что наиболее эффективным вариант подготовки прототипа сайта это использования статичных вайфреймов, в которых подробно прописаны и показаны интерактивные состояния. А использования ссылочных переходов можно рассматривать только как дополнительный элемент, облегчающий понимания прототипа в целом.

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

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

Могу сказать, что prototype.ru, судя по их сайту, очень серьезные и основательные ребята :-). А если над кем-то начинают шутить — это первый признак популярности.

Когда читал первый перечень пунктов, то наравне с частичным согласием по части доводов, в уме формулировались также и доводы против. Дойдя до второй части увидел, что все это уже сформулировано автором.

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

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

Хотелось бы ещё увидеть в комментариях примеры живых проектов, на которых по мнению автора (или сообщества) прототипирование действительно было необходимо или, скажем, где оно очень помогло провести разработку более эффективно и качественно.

Прекрасный текст! Полгода назад я был убежден, что тратить время на техническое задание — бессмысленно, если есть хороший прототип. Тем не менее, всегда к прототипам мы делали небольшое текстовое описание тех вещей, которые на прототипе — не очевидны. И обычно в первых строчках ТЗ: «Данное техническое задание является дополнением к прототипу приложения, расположенного по адресу www.prototip.ru. В случае расхождения технического задания и прототипа — приоритет имеет прототип. В случае расхождения утвержденного дизайна и прототипа — приоритет имеет дизайн».

Пока ничего не поменялось и похоже что на сложных проектах — нужно иметь оба документа. Хотя прототип покрывает около 80% потребностей.

Что касается «интриги» текста — наш опыт таков, что стоимость разработки проекта составляет около 12-14% от стоимости этапа разработки (таких дорогих прототипов, как у «интригантов» нам продавать не доводилось...). Вынести разработку прототипа в отдельный бренд — шикарная идея, и более того, хорошо выполненный прототип позволяет экономить на разработчиках, убирая все «творчество» и «я думал что так будет лучше» с программистов, на прототипистов, а это может быть в итоге дешевле (переделать прототип и дешевле, чем переделать код).

Полезная статья. Хороший ответ статье про контент (там высказывалась проблема несоответствия контента дизайну и тп).
Можно и нужно использовать прототипирование на этапе проектирования проекта.

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

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

Для крупных и сложных проектов возможно создание макетов, которые можно «прощёлкать».
Как правило в разработке немного подобных проектов — есть возможность продумывать их глубже и презентовать клиенту прототипы как можно доступнее, ближе к реальным условиям.

На практике CSFactory применяет прототипирование уже много лет. Отказываться не планируем. Всем от этого только легче.
Клиенту проще понять предлагаемое. Дизайнеру прототип помогает быстрее «въехать» в интерфейсы и не погружаться в нюансы логики проекта.
Кодеру и программисту чётко видны логические связки между спецификацией и реальными интерфейсами.

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

В качестве инструмента прототипирования мы применяем Microsoft Office Visio.

Ps: касательно трататайп

• сайты находятся на разных серверах/провайдерах/странах
• имя трататайп зарегано в 2011, а прототайп в 2000, но начало работать в 2007
• формат документа html5 у трататайп и html 4.01 у прототайпа
• при этом общая структура кода совпадает на 90% у обоих (хотя возможно просто копирование страницы и переделка статического кода под нужды)
• у трататайп нет рекламы, активностей smm, нет seo

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

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

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

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

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

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

Единственный открытый вопрос: кто должен заниматься разработкой прототипа? На мой взгляд, это отдельный специалист, обладающий хорошими знаниями в области интерфейсов, дизайна, юзабилити и программирования, либо это команда, которая знает свое дело и делает его на «отлично»!

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

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

И если вы следите за конкурентами, то последите, пожалуйста, и за нашей новой компанией, созданной для оказания услуг в области проектирования и разработки проектной документации для интернет-проектов http://www.umka.pro.

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

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

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

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

Относительно prototype.ru мы все очень внимательно следим за рынком и его игроками, и на этот счёт уже всё было выяснено (http://twitter.com/#!/darkboutique/status/136116217328058368 — Геллер Артём работает с этими людьми и http://www.facebook.com/groups/unitedigital/251443078245365 тут Артём опять подтверждает это).

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

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

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

На сегодняшний день существует масса инструментов для прототипирования: десктопный Axure PR http://www.axure.com/download, плагин Pencil Project для FireFox http://pencil.evolus.vn/en-US/Home.aspx, веб-сервисы https://gomockingbird.com/, http://www.mockflow.com/ и множество других. Выбор ограничен только вашими предпочтениями.

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

Да, что говорить, до сих пор в большинстве студий сотрудники совмещают в себе несколько ролей:

• Верстальщика и веб-технолога
• Дизайнера и иллюстратора
• Менеджера по проектам и аналитика.

Проектирование для веба — как раз находится на таком стыке, только между дизайном и аналитикой. А сильными способностями в обоих этих сферах обладает не каждый арт-директор, не то что менеджер. Так что слабым звеном здесь является не утверждение прототипа с заказчиком, а работа с ним внутри команды.

В некоторых компаниях проектирование на себя действительно берёт арт-директор, в других фокус смещён на программные продукты и есть проектировщики.

У нас это происходит таким образом:
 

1. Сначала менеджером проводится подготовка: составляется «Анализ проекта», «Статическая структура сайта», выясняем, что именно нужно клиенту.
2. Менеджер проекта/аналитик создаёт блок-схемы главной и одной из вторичных страниц. Если есть сомнения, то в процессе консультируется с дизайнерами и арт-директором.
3. На основе блок-схем создаются эскизы. На эскизе дизайнер может внести правки в блок-схему, предложить улучшения или даже серьёзно её изменить.
4. Эскиз — частично решает вопросы дизайна интерфейса. Только на его основе создаётся прототип всего сайта.
5. На отрисовке всех шаблонов ещё раз проверяем прототип на прочность, решаем оставшиеся дизайнерские задачи.

Таким образом можно на каждом этапе иметь чёткое понимание того, что мы делаем и при этом оставаться гибкими!

Чего нужно бояться в прототипе:

• Прототип предлагает дизайнеру готовое решение... Но не рассказывает, откуда оно появилось. Важно общаться с дизайнерами и раскрывать для них все требования и причины ваших интерфейсных решений в прототипе.
• Прототип, если он слишком похож на готовый сайт — может только ещё сильнее смутить заказчика. Частично для этого и используют «mock-up» стиль.
• Не привязывайтесь сильно к прототипу, дизайнеры и технологи могут предложить лучшие решения.
• Прототип — даёт небывалую скорость. Надо понимать где остановиться и уже переходить к разработке. Слишком сложные и «долгие» прототипы тоже никому не нужны.

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

А на сайтах прототип.ру и трататип.ру написана полная правда, на обоих.

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

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

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

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

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

Прототипировали разными средствами разработки, от Axure до Flash, на роль технического писателя избирались и проджект-менеджеры, и программисты, и дизайнеры.

http://pro.kinetica.su/paylogic/ → http://www.pay-logic.ru/
http://pro.kinetica.su/manhattan/ → http://manhattan-pizza.ru/

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

По итогам нескольких кейсов сделаны следующие выводы:

• Разработка интерактивного прототипа трудозатратна на первом этапе только в случае прототипирования действительно сложного по интерфейсам и функционалу сайта, т.к. требует участия всей будущей команды: проджект-менеджера, арт-директора, дизайнера, верстальщика, программиста, копирайтера. С другой стороны, такое прототипирование вовлекает всю команду в процесс на старте проекта, и время на реализацию сокращается так значительно, что срок сдачи наступает едва ли не быстрее, чем планировалось. При этом работа аккаунт-менеджера по сдаче/приёмке готового сайта клиенту становится существенно проще. В общем, «лучше день потерять, потом за 5 минут долететь» ©
• Разработка прототипа для сайта стандартного функционала является полезной формальностью: создается такой прототип в Axure за 1 день только силами проджект-менеджера, но при этом вовлечение клиента в процесс происходит очень быстро. Есть и положительный психологический момент с точки зрения аккаунта — студия не теряется на месяц после предоплаты, высокое доверие сохраняется до конца проекта. Однако, стоит отметить, что прототип, созданный PM единолично, приводит к большому количеству тиражных решений в портфолио: менеджеру свойственно унифицировать свой труд («сработало 2 раза — сработает и на 10-й»), а дизайнеру легко свалиться в «раскрашивание скелета». Для того, чтобы избежать шаблонов в портфолио, при проведении брифинга мы тщательно изучаем потребность и готовность клиента платить за уникальную визуальную концепцию. Если будущий сайт предполагает наличие креатива, то прежде, чем PM приступит к прототипированию, арт-директор и дизайнер проекта предлагают «скетч в карандаше» (например, http://www.kinetica.su/sozdanie_sajtov/news/dizajn_firmennogo_stilya_i_razrabotka_sajta_shkoly_tancev_chili/).

Некоторые тезисы этой статьи представляется мне спорными, но в целом написано хорошо.

Вообще все больше склоняюсь к мнению, что для успешной реализации проекта большее значение имеют люди, а не качественное ТЗ или детально проработанные прототипы. Практика показывает, что насколько бы детальной и качественной ни была спецификация — всегда есть место для ошибок. Как говорится: все, что можно понять неправильно — будет понято неправильно. А все потому, что реализацией проекта занимаются люди, которые его не проектировали. Они не видят картину целиком и не понимают, к чему приведут те небольшие изменения, которые они делают.. а они их обязательно делают =)

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

С прототипом или без — однозначного ответа быть не может. От чего он зависит в конкретном случае — можно судить по тем «За» и «Против», которые изложил автор статьи. Я работала и так, и эдак, существенной разницы не заметила. Поэтому лично для себя я этот вопрос решаю по двум факторам:

1. По сложности проекта и объему планируемого контента. Чем сложнее и больше, чем больше нового для нас функционала — тем более привлекательна идея создания прототипа.
2. По комфорту в работе для менеджеров как со стороны заказчика, так и со стороны исполнителя. Если им так удобнее, значит прототип нужен. (Причем для заказчика прототип может быть удобен именно менеджеру, руководству его показывать как раз совсем не стоит — начальники любят видеть готовую картинку).

Согласен с автором данной статьи на 100%. Этап создания прототипа, является обязательным этапом в компании AGENTE. Обычно нашим клиентам мы говорим что, невозможно построить дом, не имея проектной документации, тоже самое и с сайтом или мобильным приложением или любой другой информационной средой или интерфейсом.

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

Из опыта нашей компании добавлю:

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

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

— Большой плюс прототипирования в том, что все участники проекта четко представляют себе, где что будет расположено и из чего состоять. Дизайнер знает, что рисовать, клиент потом не удивляется увиденному дизайну, менеджер всегда может опираться на прототипы (и конечно же ТЗ) при общении с клиентом.

— При грамотном прототипировании значительно возрастает вероятность принятия дизайн-концепции. В нашей компании она возросла с 70% до 90%

Наша задача, как разработчиков, разъяснить клиенту важность прототипирования.

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

Тем не менее, я скептично отношусь к отдельным разработкам прототипов, в моём понимании процесс прототип->функционал должен осуществляться и контролироваться одним исполнителем.

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

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

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

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

Вот только один вопрос возникает, как оценить правильность сделанного прототипа?

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