Как сделать прототип сайта до визуального дизайна

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

Что должно получиться

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

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

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

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

Из чего это складывается

Как выбрать подробность

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

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

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

Как это сделать по шагам

1. Зафиксируйте сценарий. Опишите, кто приходит, что уже знает и что хочет получить. Укажите начало и ожидаемое завершение. Например: человек выбирает подходящую услугу, читает условия и отправляет обращение с понятным подтверждением. Это учебный сценарий, который нужно заменить своим.
2. Соберите содержание. Подготовьте названия услуг, ограничения, поля формы и объяснения результата. Если часть данных пока неизвестна, явно отметьте пробелы в рабочем документе. Не заполняйте их вымышленными обещаниями или случайными условиями.
3. Набросайте экраны. Разместите информацию в порядке принятия решения. Сначала покажите то, что помогает понять предложение, затем — подробности и действие. Рисуйте блоки достаточно грубо, чтобы их было легко переставлять.
4. Свяжите действия с результатами. У каждой важной ссылки или кнопки должно быть понятное продолжение: другой экран, раскрытие блока, сообщение или изменение состояния. Покажите возвращение назад там, где посетитель может изменить решение.
5. Добавьте сложные случаи. Продумайте отсутствие результатов, ошибку ввода, недоступный вариант и успешное завершение. Отдельно проверьте, что происходит с уже введённой информацией при исправлении ошибки.
6. Подготовьте задание для проверки. Опишите цель без подсказки о нужной кнопке. Вместо «откройте раздел услуг» предложите найти подходящий вариант при заданных условиях. Не называйте путь, который вы как раз хотите проверить.
7. Понаблюдайте за прохождением. Попросите участника объяснять, что он ожидает увидеть. Не ведите его по макету, пока он пытается разобраться. Записывайте остановки и неверные ожидания, а помощь ведущего отмечайте отдельно.
8. Исправьте и сохраните решения. Измените проблемные места и снова проверьте тот же сценарий. Зафиксируйте текущую версию, оставшиеся вопросы и границы модели. Только затем переходите к подробному оформлению или разработке.

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

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

Что проверить на телефоне

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

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

Частые ошибки

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

Использовать случайный текст вместо содержания. Условная короткая подпись помещается в карточку, а настоящее название переносится и вытесняет действие. Добавляйте реалистичные по смыслу и длине тексты. Персональные данные для проверки заменяйте безопасными учебными примерами.

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

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

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

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

Как проверить

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

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

Подход к выбору подробности описан в руководстве GOV.UK по прототипированию и материале The National Archives. Их рекомендации помогают выбрать способ проверки; внутренние правила государственных команд не становятся автоматически обязательными для вашего проекта.

Чтобы связать модель с задачей посетителя, начните с разбора UI и UX. Порядок работы с подрядчиком описан в статье как заказать дизайн сайта. Если нужна помощь с прототипом, разместите понятную задачу в разделе дизайна сайтов.

Вопросы и ответы

Прототип обязательно должен быть кликабельным?

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

Нужно ли рисовать все страницы сразу?

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

Можно ли делать прототип без готовых текстов?

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

Чем прототип отличается от дизайна?

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

Можно ли сразу передать прототип разработчику?

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

Когда прототип можно считать готовым?

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