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

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

Не смею более отвлекать вас от прекрасной обучающей статьи – и желаю вам приятного чтения!

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

Тренд: прототипы стали привычнее

Уровень технической грамотности заказчиков, к счастью, повышается — люди всё больше интересуются тем, за что они платят деньги веб-студиям, и это хорошо. У нас даже был случай, когда заказчик сам сделал нам прототип с рабочими ссылками в Excel — правда, за 6 месяцев, но, тем не менее, такой факт имел место. Слово «прототип» уже многим знакомо, и это часто упрощает обсуждение внешнего вида будущего сайта. В идеальном случае можно быстро набросать что-то вместе с заказчиком в Ninjamock непосредственно на встрече, а потом уже детализировать с помощью инструментов помощнее — типа того же Axure.

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

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

Когда прототип нужен?

Когда заказчик нечётко представляет, чего он хочет

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

Когда проект сложен, и возможны критичные ошибки при проектировании интерфейсов

Без прототипа дизайнеры могут сделать очень красивый, но совершенно не функциональный дизайн, в котором не предусмотрена, например, жизненно необходимая кнопка «Назад», или кнопки «Удалить» и «Добавить в избранное» расположены слишком далеко друг от друга. Наличие этих кнопок может быть описано в ТЗ, но у прототипа перед ним есть главное преимущество — наглядность.

Когда с заказчиком сложно работать, потому что он постоянно меняет требования

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

Когда требуется максимум формальной документации — например, для участия в тендере

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

Когда требуется компромисс между интересами нескольких сторон

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

Когда прототип не нужен?

Когда «клонируется» некий готовый проект

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

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

Когда делается крайне простой стандартный сайт (например, посадочная страница)

Если клиенту требуется обычный лэндинг с блочной структурой («текст-кнопка-текст-кнопка»), делать прототип просто нецелесообразно — это пустая трата времени, которое можно израсходовать на что-то более полезное. Заказчику наверняка будет достаточно посмотреть на аналог будущей посадочной страницы — благо недостатка в таких примерах нет.

В заключении мне хотелось бы затронуть ещё один важный и неоднократно поднимавшийся вопрос: что нужнее — прототип или ТЗ? На самом деле, и ТЗ, и прототип можно рассмотреть как продукты, которые мы «продаём» разной целевой аудитории. Прототип нужен визуалам — заказчику и дизайнеру, а ТЗ как логическое описание системы ближе и понятнее программисту. Приоритет, конечно, у ТЗ, потому что проект нельзя сделать, не описав принципов его работы. А вот в качестве визуального «чертежа» проекта вам может послужить как прототип, так и какой-нибудь готовый сайт — при условии, что вы планируете сделать точно такой же.