5 причин, почему вам не стоит прототипировать

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

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

А вот электронный прототип для электронного же продукта (сайта) сопоставим по стоимости с созданием полноценного дизайн-проекта. И это странно.

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

«Вот вам карта сайта в виде многуровневого списка или UML-диаграммы, а вот список того, что должно быть на каждой странице».

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

Прототип ставит телегу впереди лошади

Расположение элементов не должно доминировать над контентом. Для иллюстрации этого пункта я ввёл в «Яндекс.Картинки» запрос «прототип сайта». Вот второй результат:

Хороший прототип — хоть сейчас в дизайн, вёрстку и внедрение. Правда, потом перед заказчиком встанут вопросы:

1. Если описать услуги коротко, то хватит пары предложений, а если подробно — три минимум. Один абзац — ни туда, ни сюда. Что делать?

2. «Новинки услуг»? Нам что, каждую неделю по новой услуге добавлять?

3. О чём писать в прекрасном блоке про прибор? И, главное, зачем?

4. Погодите, снова услуги? А первого блока не хватит?

5. О, и проекты снова. И чем они отличаются от первого блока?

Исполнитель объяснит, что мы тут можем поставить любую информацию, услуги заменить на биографию директора (и место для фотки есть), а вместо нижнего портфолио разместить логотипы клиентов. Только в чём заключалась его работа: раскрасить и оживить сетку или создать эффективную страницу? Если второе, то стоило начать с контента: получить материалы, придумать, понять, что его слишком мало или слишком много, отобрать материалы в правильной последовательности, окрасить в нужные эмоции, подобрать картинки — и потом уже отдавать в прототип...

Стоп, разве не лучше отдать сразу в дизайн?

Ещё пара примеров:

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

2. Каждый товар в списке представлен как обычно: горизонтально ориентированная картинка, под ней — название, короткое описание, цена. Но картинки заказчика могут быть совершенно разными (некоторые предметы больше по высоте, чем по ширине). То же с длиной названия. Продумывать внешний вид плитки должен дизайнер. И только после того, как изучит вводные данные.

Понимаете? Без контента ни прототип, ни дизайн смысла не имеют. Если по уму-то.

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

Прототип искажает вводные

Представьте себе задачу: организовать навигацию по большому объёму продуктов с энным количеством характеристик. Первое, что приходит в голову — скопировать «Яндекс.Маркет».

Окей, пишем в ТЗ «сделать фасетный фильтр, как в „Яндекс.Маркете“» и перечисляем характеристики для выборки. Рисуем прототип, дизайнер делает шаблон, программируем, загоняем данные. И лишь после этого выясняется, что:

• Большинство популярных запросов выдают либо слишком много, либо слишком мало результатов. Часть характеристик нужно убрать (и вывести форму фильтра сверху). Ещё лучше — придумать новые.

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

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

• Фасетный поиск в принципе не совсем подходит: смысл существования одного параметра зависит от значения другого.

Что нужно сделать: внести продукты скриптом и с самым простым интерфейсом проверить популярные запросы, а результат предоставить дизайнеру. Прототип здесь никак не поможет, только помешает.

Другой пример: вид и структура виджета авторизованного пользователя зависит от его группы, наличия заказов, аватара, уровня доступа... Логику можно (и нужно!) описать текстом. Опять-таки, прототип не поможет, скорее, введёт дизайнера в заблуждение.

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

Прототип сводит роль дизайнера к раскрашиванию картинок

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

При «прототипной» схеме в команде есть некий аналитик, который отвечает за преобразование задачи клиента в формализованный вид: ТЗ, прототип с проработанным UX. А есть дизайнер, который... Который что? Умеет подбирать цвета, шрифты и знает фотошоп?

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

И снова: зачем же ему прототип, если проще всё сделать в фотошопе?

Прототип практически ничего не говорит о каждой конкретной странице

Да, сформировать доверие к проекту и вызвать определённые эмоции ничуть не менее важно, чем правильно расположить блоки на странице. А доверие и правильные эмоции — епархия двух специалистов: редактора (он же контентщик) и дизайнера. Одна сторона медали — текст определённого объёма, правильная подача, эмоциональная окраска, другая — грамотно подобранная графика, шрифты, цвета, расположение и оформление. Но продаёт вся медаль, а не какая-то её сторона. Или не продаёт.

Что полезнее для заказчика или фокус-группы: не очень аккуратный «почти конечный» дизайн страницы с «почти конечными» текстами, цветами, фотками, шрифтами — или чёрно-белая страничка с текстом из «Яндекс.Рефератов» и прямоугольниками с подписью «фотка улыбающегося ребёнка»?

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

Прототипы вредны для современных методик разработки

Если вы развиваете проект по принципу MVP, прототип не принесёт вам никакой пользы. Некрасивый, но рабочий сайт «без CSS» (например, если вы разрабатываете свой проект по идеологии Progressive Enhancement) в прототипе не нуждается. Красивый, но с минимальными функциями — тоже. И уж тем более прототипы не понадобятся для превращения первого MVP во второй и третий.

То же справедливо не только для гибкой, но и для непрерывной разработки, когда после «завершения» проекта вы обвешиваете его метриками и продолжаете экспериментировать с А/Б-тестами, добавляете новые страницы и сценарии навигации.

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

* * *

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

1. Совмещать создание интерактивного прототипа и «картинки» при помощи сервисов типа Invision или Marvel.

2. Как платформу разработки сайта использовать конструктор, поддерживающий тонкую настройку дизайна, вроде Webflow или «Флоксим».

3. Если вы привязаны к другой платформе — использовать конструкторы из второго пункта как средство прототипирования.

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

* * *

Алексей Бородкин Директор по продукту Notamedia

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