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