Почти каждый второй клиент, который приходит к нам за новым сайтом, просит сразу показать дизайн. Желание понятное: хочется увидеть результат, оценить «красоту», показать руководству. Но если начать с цвета и шрифтов, обсуждение неизбежно уходит во вкусовщину, а вопросы структуры, логики и сценариев остаются нерешёнными до момента, когда их исправление стоит в разы дороже.
Прототип — это чёрно-белая схема страниц, на которой видно, какие блоки где стоят, что в них написано, куда ведут кнопки и как пользователь проходит путь от входа до заявки. В этой статье разберём, зачем нужен этот этап, из чего он состоит и как понять, что прототип сделан хорошо.
Чем прототип отличается от макета
Путаница в терминах встречается постоянно, поэтому сначала договоримся о словах. В нашей практике есть три уровня проработки, и каждый отвечает на свой вопрос.
- Схема структуры (карта сайта) отвечает на вопрос «какие страницы есть и как они связаны». Это дерево разделов, иногда с пометками о типах страниц.
- Прототип отвечает на вопрос «что находится на каждой странице и в каком порядке». Здесь уже есть блоки, заголовки, примерные тексты, формы, кнопки, состояния элементов.
- Дизайн-макет отвечает на вопрос «как это выглядит». Цвета, типографика, фотографии, иконки, анимации.
Прототип намеренно лишён визуального оформления. Серые прямоугольники вместо фотографий, один шрифт, никакой палитры. Это не недоработка, а принцип: когда на экране нет цвета, люди обсуждают смысл. Стоит добавить синий фон — и половина совещания уйдёт на спор, достаточно ли он «фирменный».
Какие проблемы решает этап прототипирования
Главная ценность прототипа в том, что он переносит дорогие ошибки на дешёвую стадию. Передвинуть блок в прототипе — минута работы. Передвинуть его в готовом дизайне — час, в свёрстанном сайте — полдня, а если блок завязан на данные из CMS, может потребоваться доработка бэкенда.
Согласование логики до визуала
Однажды мы делали сайт для производителя промышленного оборудования. На этапе прототипа выяснилось, что отдел продаж и маркетинг по-разному видят главный сценарий: продажам нужно, чтобы посетитель скачал опросный лист, маркетингу — чтобы оставил контакт для консультации. Если бы мы сразу ушли в дизайн, этот конфликт всплыл бы на сдаче. В прототипе мы просто нарисовали оба варианта, обсудили и выбрали гибридную схему: опросный лист доступен без регистрации, а под ним — короткая форма «Не хотите заполнять? Перезвоним и поможем».
Контент начинает жить раньше
Прототип заставляет думать о текстах. Нельзя нарисовать блок «Преимущества», не понимая, какие это преимущества и сколько их. Заказчик начинает собирать фактуру — цифры, кейсы, фотографии объектов — пока дизайнер ещё не приступил к работе. В итоге к моменту вёрстки контент уже есть, а не пишется в последний вечер перед запуском.
Точная оценка разработки
Разработчик, глядя на прототип, видит фильтры, калькуляторы, личные кабинеты, интеграции. Он может честно оценить трудоёмкость. Без прототипа оценка строится на словах «ну, там будет каталог», и в процессе всплывают сюрпризы, которые съедают бюджет.
Из чего состоит хороший прототип
Мы видели прототипы, которые представляли собой три прямоугольника с подписями «шапка», «контент», «подвал». Такой документ бесполезен: в нём нечего согласовывать. Рабочий прототип содержит гораздо больше.
- Все типовые страницы. Не только главная, но и внутренние: страница услуги, карточка товара, каталог, статья блога, контакты, страница «спасибо» после заявки, страница 404.
- Реальные или близкие к реальным тексты. Заголовки должны быть настоящими, а не «Заголовок блока». Иначе невозможно оценить, поместится ли формулировка и понятна ли она.
- Состояния интерактивных элементов. Что видит пользователь, если форма заполнена с ошибкой? Если в фильтре нет товаров? Если корзина пуста? Эти экраны часто забывают, а потом дорисовывают на ходу.
- Мобильная версия. Хотя бы для ключевых страниц. Порядок блоков на телефоне не всегда совпадает с десктопным, и это лучше решить сразу.
- Комментарии. Пояснения к логике: откуда берутся данные, что происходит при нажатии, какие поля обязательны.
Хороший прототип можно отдать разработчику и копирайтеру без устных пояснений, и оба поймут, что делать.
Низкая и высокая детализация: что выбрать
Прототипы бывают разной степени проработки, и выбор зависит от задачи и бюджета. Сравним два крайних подхода.
| Параметр | Низкая детализация | Высокая детализация |
|---|---|---|
| Как выглядит | Схематичные блоки, условные подписи | Точная сетка, реальные тексты, все элементы интерфейса |
| Сколько времени | Несколько дней | Одна-три недели в зависимости от числа страниц |
| Когда подходит | Лендинг, небольшой сайт-визитка, ранняя проверка идеи | Интернет-магазин, корпоративный портал, сервис с личным кабинетом |
| Риски | Детали всплывают на этапе дизайна | Можно увязнуть в мелочах до утверждения общей логики |
Мы обычно идём в два шага: сначала быстрая схема главных страниц, чтобы договориться о логике, затем детальная проработка. Так заказчик не тратит время на обсуждение отступов, пока не решено, нужен ли вообще этот раздел.
Кликабельный прототип и тестирование
Статичные картинки хорошо показывают состав страницы, но плохо передают ощущение навигации. Поэтому для проектов со сложными сценариями мы связываем экраны между собой: кнопки ведут на нужные страницы, меню раскрывается, форма переходит в состояние «отправлено». Получается кликабельная модель сайта, которую можно открыть в браузере или на телефоне.
Такой прототип удобно показывать живым людям. Не нужен большой бюджет на исследования: достаточно пяти-шести человек из целевой аудитории и простых заданий вроде «найдите стоимость доставки в ваш город» или «оставьте заявку на расчёт». Наблюдая за ними, мы видим, где они застревают, что пропускают, какие слова не понимают.
Из практики: в прототипе сервиса доставки обедов для офисов мы спрятали выбор даты в отдельный шаг. Четверо из шести тестировщиков не заметили, что заказ оформляется на завтра, а не на сегодня. Исправление заняло десять минут в прототипе. После запуска это стоило бы десятков возмущённых звонков.
Что проверять на тестах
- Находят ли люди главное действие без подсказки.
- Понятны ли названия пунктов меню и разделов.
- Хватает ли информации для принятия решения на ключевых страницах.
- Не возникает ли желания вернуться назад и перечитать.
Типичные ошибки на этапе прототипа
За годы работы мы собрали список того, что чаще всего портит пользу от прототипирования. Большинство ошибок связано не с инструментами, а с процессом.
Прототип делается без участия заказчика. Дизайнер рисует его по брифу и присылает на согласование одним файлом. Заказчик листает, говорит «вроде нормально» и подписывает. Через месяц выясняется, что половина блоков не отражает реальность бизнеса. Прототип нужно обсуждать голосом, проходя по каждому экрану и проговаривая логику.
В прототип тащат дизайн. Начинают подбирать шрифты, вставлять фотографии, «чтобы было понятнее». В итоге обсуждение снова скатывается во внешний вид, а прототип теряет гибкость.
Тексты-заглушки. «Lorem ipsum» или «Здесь будет текст о компании» — прямой путь к тому, что текст так и не напишут, а блок окажется либо пустым, либо заполненным водой.
Забытые второстепенные страницы. Главная проработана до пикселя, а страница политики конфиденциальности, результаты поиска и сообщения об ошибках остаются на усмотрение верстальщика.
Нет связи с SEO. Структура разделов и посадочных страниц должна учитывать семантику. Если прототип рисуют без понимания, по каким запросам сайт будет продвигаться, потом приходится добавлять страницы и перекраивать меню. Когда параллельно планируется SEO-продвижение, мы подключаем специалиста ещё на этапе карты сайта.
Как прототип встраивается в общий процесс
В нашем рабочем цикле прототипирование стоит между аналитикой и дизайном. Последовательность выглядит так:
- Бриф и интервью с заказчиком, изучение конкурентов и аудитории.
- Карта сайта и список типовых страниц.
- Прототип ключевых страниц, обсуждение, правки.
- Прототип оставшихся страниц и мобильных версий.
- Тестирование кликабельной модели, если проект этого требует.
- Утверждение и передача в дизайн.
После утверждения прототипа дизайнер работает гораздо быстрее и увереннее. Он не изобретает структуру, а сосредоточен на визуальной подаче: как сделать так, чтобы уже согласованная логика выглядела убедительно. Правок на этапе дизайна становится заметно меньше, потому что спорить о содержании уже не нужно. Подробнее о том, как устроен этот этап у нас, можно прочитать на странице разработки дизайна.
Отдельно скажем про доработку существующих сайтов. Даже если вы не делаете сайт с нуля, а меняете один раздел или добавляете новый функционал, прототип нужен. Например, переделка оформления заказа в интернет-магазине — это пять-семь экранов, каждый из которых влияет на конверсию. Нарисовать их схемой и проверить логику дешевле, чем выкатывать и откатывать изменения на живом сайте.
Вывод
Прототип — это не лишняя бумажка и не способ растянуть сроки. Это самый дешёвый момент проекта, когда можно поменять что угодно без потерь. Он помогает договориться внутри команды заказчика, заранее собрать контент, точно оценить разработку и проверить сценарии на реальных людях.
Если вам предлагают сразу перейти к дизайну, минуя прототип, спросите, как будут согласовываться структура и логика страниц. Если ответ звучит как «по ходу разберёмся», будьте готовы к тому, что разбираться придётся долго и за дополнительные деньги. Мы всегда начинаем с прототипа — и именно поэтому наши дизайн-макеты редко уходят на третий круг правок.
