Как проверить прототип сайта до дизайна и разработки
Дайте будущему посетителю конкретную задачу и посмотрите, как он решает её по прототипу: выбирает услугу, разбирается в условиях и обращается в компанию. Зафиксируйте места, где ему не хватает информации или приходится помогать. Ниже — учебный прототип из четырёх экранов, пять заданий и журнал, который превращает наблюдения в решения для дизайнера и разработчика.
Определите решение, ради которого проводите проверку
Фраза «посмотреть, всё ли понятно» слишком широка. Команда может час обсуждать цвета и так и не выяснить, способен ли клиент выбрать нужную услугу. Начните с вопроса, ответ на который изменит проект: например, достаточно ли разделения на разовую помощь и регулярное обслуживание или посетителю требуется другой способ выбора.
В этой статье под этапом до дизайна понимается работа до подробного визуального оформления. Сам прототип уже является проектированием: вы определяете содержание, последовательность экранов и поведение элементов. Сначала проверяется логика, затем она уточняется вместе с оформлением и реализацией.
GOV.UK рекомендует задавать исследованию конкретные цели и проверять предположения, важные для следующего решения. Для небольшого сайта это можно записать тремя строками: что предполагаем, что хотим наблюдать и что изменим при обнаружении проблемы. Наличие документа на десятки страниц для такой записи не требуется.
Наш учебный вопрос: «Понимает ли офисный администратор разницу между постоянным обслуживанием техники и устранением конкретной неисправности?» Возможное решение после проверки — изменить названия услуг, добавить пояснение о составе работ или пересмотреть группировку. Выбирайте между ними по наблюдениям, а не заранее.
Отдельно перечислите то, чего прототип пока не подтверждает: скорость настоящего сайта, доставку уведомления, сохранение данных и работу интеграций. Эти пункты понадобятся при приёмке готовой реализации. Успешное прохождение схемы не является результатом их проверки.
Подготовьте четыре экрана для одного законченного маршрута
Возьмём вымышленную компанию по обслуживанию офисной техники. У неё есть разовый ремонт и регулярные работы. Все названия, условия и примеры ниже учебные; это не описание клиента или предложения Salestudia. Прототип можно перенести на бумагу, в презентацию или инструмент для макетов.
| Экран | Что на нём есть | Что подготовить для проверки |
|---|---|---|
| 1. Выбор услуги | Разовый ремонт и регулярное обслуживание | Два различимых варианта и переход к выбранной услуге |
| 2. Условия обслуживания | Плановые проверки и уход; ремонт отдельно; стоимость после списка техники; адрес и время уточняются | Реальные для вашего проекта условия вместо учебных; путь к запросу |
| 3. Запрос | Описание задачи, город, контакт и действие отправки | Возможность заполнить и исправить данные; демонстрационное состояние ошибки, если его проверяете |
| 4. Подтверждение | Запрос отправлен; время и стоимость ещё нужно согласовать | Понятное объяснение следующего шага и путь назад |
Для бумажной проверки участник показывает выбранный элемент, а ведущий выдаёт соответствующий следующий экран. Не раскладывайте перед ним весь маршрут: так вы заранее подскажете последовательность. В электронном прототипе свяжите эти же действия и проверьте переходы самостоятельно.
Текст должен позволять принять решение. Вместо «здесь будет описание» напишите состав услуги и ограничения. Если стоимость зависит от исходных данных, покажите от чего именно. Внешне аккуратный прямоугольник без содержания не позволит проверить понимание условий.
GOV.UK предлагает делать прототип настолько подробным, насколько нужно для проверки рискованных предположений. Для нашего вопроса не нужен весь будущий сайт. Нужны выбор услуги, достаточные условия и продолжение действия; остальные разделы можно исследовать отдельно.
Пригласите людей, которым знакома задача
Для сайта обслуживания техники полезнее участник, который действительно выбирает подрядчиков или организует работу офиса. Коллега-дизайнер хорошо заметит неровные отступы, но может понимать структуру благодаря профессиональному опыту. Это другой источник обратной связи.
Опишите критерии приглашения через опыт: какую задачу человек решал, какую роль выполнял, какая информация была нужна для выбора. Для примера подходят администратор офиса и сотрудник, согласующий обслуживание. Если их решения существенно различаются, рассматривайте их как разные группы, а не смешивайте впечатления в один вывод.
Небольшая качественная проверка помогает обнаруживать затруднения и выяснять их причины. Она не устанавливает процент всех будущих клиентов, которые столкнутся с проблемой. NN/g отдельно предупреждает, что показатели небольшой качественной выборки обычно не представляют всю аудиторию. Число участников выбирайте под задачи и группы, без обещания найти все ошибки за фиксированное количество встреч.
Заранее сообщите продолжительность, формат и то, что будет происходить. Если планируется запись, объясните её назначение и согласуйте её с участником. Для учебной формы подготовьте вымышленные данные. Настоящие контакты, платежи и отправка заявки здесь не нужны.
Учитывайте язык и устройство. Если сайт рассчитан на людей, выбирающих услугу с телефона, покажите соответствующий вариант. Проверка русской версии не подтверждает понятность немецкой: названия, длина текста и знакомство с терминами могут отличаться.
Дайте пять заданий без подсказок о кнопках
Задание описывает ситуацию и желаемый результат. Оно не должно воспроизводить путь по меню. NN/g рекомендует избегать подсказок и точного повторения названий элементов интерфейса: иначе участник может просто искать услышанное слово. Критерий наблюдения оставьте в заметках ведущего.
| Задание участнику | Что наблюдать | Признак понятного результата |
|---|---|---|
| 1. В офисе хотят заранее организовать уход за принтерами, чтобы регулярно проверять их состояние. Найдите подходящее предложение. | Как человек различает варианты и объясняет выбор | Выбрано обслуживание; участник может объяснить отличие от помощи при неисправности |
| 2. Перед обсуждением с руководителем выясните, за какие работы будет платить компания и что потребуется для расчёта. | Находит ли состав, исключения и исходные данные | Участник видит, что ремонт отдельно, а для оценки нужен список техники |
| 3. Выезд нужен в офис в другом городе после окончания рабочего дня. Выясните, можно ли уже рассчитывать на такое обслуживание. | Как трактуются неопределённые условия | Участник понимает, что адрес и время нужно согласовать; не принимает возможность запроса за обещание выезда |
| 4. Вы решили обсудить обслуживание. Покажите, как передадите компании задачу, используя выданные учебные данные. | Находит ли форму, понимает ли поля и может ли исправить ответ | Подготовлен понятный запрос; участник выполняет предусмотренное действие отправки |
| 5. Вы завершили обращение. Расскажите, что теперь произойдёт и что уже согласовано. | Как понимается подтверждение | Запрос отличается от заказа; стоимость и время ещё предстоит согласовать |
Для четвёртого задания выдайте карточку: «Офис, четыре принтера; требуется плановый уход; город — учебный; контакт — test@example.com». В бумажной версии ответы можно записать или проговорить. Такая модель проверяет смысл полей, но не работу клавиатуры и валидации электронной формы.
Задания образуют один маршрут, поэтому поздние действия зависят от того, что человек уже увидел. Зафиксируйте эту зависимость. Если нужно отдельно оценить первое впечатление от страницы услуги, проведите отдельную попытку с новым участником и заранее выбранной стартовой точкой.
Не требуйте единственного маршрута там, где допустимы несколько. Посетитель может открыть контакты из меню или перейти из услуги. Важен осмысленный результат. Другой путь становится проблемой, когда он приводит к неверным условиям, тупику или потере необходимых данных.
Сначала проверьте сам сценарий исследования
Проведите пробную сессию, чтобы обнаружить сломанные переходы, непонятное задание и слишком большой объём. В рекомендациях NN/g такая предварительная проверка помогает уточнить формулировки и порядок действий. Её результат используйте для исправления процедуры, отдельно от основной серии наблюдений.
Для нашего примера пройдите оба варианта с первого экрана. Даже если исследуется регулярное обслуживание, участник может открыть ремонт. Подготовьте ответный экран с кратким описанием и возможностью вернуться. Если этого экрана нет, отметьте ограничение: тупик может быть недостатком модели, а не ошибкой выбора человека.
Проверьте начальное состояние каждой попытки: открывается нужная страница, прежние ответы очищены, отсутствует подсветка, показывающая правильный клик. Ведущий должен понимать, когда разрешено сменить бумажный экран и какие действия модель пока не поддерживает.
Запишите обозначение версии, например P-01, и дату. Если между встречами меняется подпись или содержание, сохраните новую версию P-02. Наблюдения по двум версиям нельзя свести в одну строку без указания различий: участники видели разные условия.
Наблюдайте и уточняйте, не ведя человека за руку
Перед началом объясните, что оценивается понятность проекта, а не знания участника. Попросите по возможности рассказывать, что он ищет и чего ожидает. В руководстве GOV.UK для ведущего рекомендуются нейтральные инструкции, наблюдение и открытые уточняющие вопросы.
Когда человек остановился, сначала дайте ему возможность продолжить. Вопрос «Что вы сейчас пытаетесь найти?» поможет понять цель. Фраза «Посмотрите ниже, там условия» уже помогает выполнить задание. Если без помощи продолжить невозможно, вмешайтесь и отметьте это в журнале; дальнейшие наблюдения остаются полезными.
После неожиданного выбора спросите: «Что вы ожидали увидеть здесь?» После завершения — «Как вы поняли, что действие закончено?» Не объясняйте задумку автора до ответа. Иначе вы узнаете, согласен ли участник с объяснением, а не то, что сообщил ему экран.
Слова «всё удобно» тоже требуют контекста. Человек мог похвалить внешний вид, хотя до этого не нашёл состав услуги. Сохраните оба наблюдения. Положительная оценка не отменяет затруднения, а затруднение не делает бесполезным всё решение.
Если участник предлагает добавить поиск, запишите предложение, затем выясните, что он хотел найти. Причиной может быть непонятная группа услуг. Прямое исполнение каждой предложенной функции способно усложнить сайт, не решив исходную проблему.
Запишите действие отдельно от предполагаемой причины
Полезная запись позволяет другому человеку понять, что произошло. GOV.UK предлагает сначала фиксировать увиденное и услышанное, затем определять выводы и действия. Формулировка «посетитель невнимательный» смешивает наблюдение с оценкой и почти не помогает исправлению.
| Попытка и факт | Предположение о причине | Решение и повторная проверка |
|---|---|---|
| U-01, P-01, задание 1: открыл ремонт, вернулся, попросил объяснить варианты | Названия не показывают разницу между текущей поломкой и постоянным уходом | Добавить короткие пояснения; повторить выбор без объяснения ведущего |
| U-02, P-01, задание 2: включил ремонт в перечень оплачиваемых работ | Исключение отделено от основного состава и осталось незамеченным | Поставить ограничение рядом с составом; попросить пересказать предложение |
| U-03, P-01, задание 5: решил, что время выезда уже забронировано | Подтверждение воспринимается как завершение заказа | Уточнить статус и следующий шаг; проверить понимание после обращения |
В рабочем журнале добавьте устройство, язык, стартовый экран, помощь ведущего и ссылку на разрешённую запись или подробные заметки. Для результата используйте понятные отметки: самостоятельно, с помощью, не завершено, ограничено прототипом. Сохраните конкретное основание отметки.
Предположение ещё нужно проверить. Возможно, участник не понял слово, не заметил блок или получил неоднозначное задание. Эти причины требуют разных правок. Если запись недостаточно подробная, не повышайте уверенность формулировки; поставьте уточнение в следующий раунд.
Не переносите строки учебной таблицы в отчёт как реальные результаты. В действительном исследовании идентификатор участника связывается с вашей собственной записью, а вывод должен опираться на наблюдавшееся действие. Макет таблицы задаёт форму работы, но не заменяет её.
Выберите правки по последствиям для задачи
Начните с проблем, из-за которых человек выбирает неподходящую услугу, понимает условия неверно или не может обратиться. Затем разберите задержки и лишние действия. Замечания о предпочтительном цвете сохраняйте отдельно, пока не ясно, как они связаны с выполнением задачи.
| Последствие | Пример | Следующее действие |
|---|---|---|
| Не удаётся продолжить | Нужное действие недоступно на подготовленном экране | Уточнить, проблема ли это модели или проекта; восстановить маршрут |
| Сформировано неверное ожидание | Отправка запроса принята за подтверждённый визит | Исправить статус и объяснение; проверить понимание повторно |
| Задача решена с лишними усилиями | Условия найдены только после возвращения в другой раздел | Проверить размещение информации и связь страниц |
| Высказано предпочтение | Участнику больше нравится другой стиль кнопки | Сохранить как комментарий; выяснить, есть ли наблюдаемая проблема действия |
Не умножайте условные баллы так, будто они дают точную экономическую оценку. В небольшой проверке полезнее назвать последствие, повторяемость наблюдения и уверенность в причине. Единственная обнаруженная возможность отправить запрос не туда может требовать внимания независимо от частоты.
Для каждой принятой правки запишите владельца, изменяемый экран и критерий повторной проверки. «Улучшить понятность» замените на конкретное изменение: «Рядом с составом обслуживания объяснить, что ремонт рассчитывается отдельно». После этого проверьте, как новый участник пересказывает условия.
Повторите проверку и обозначьте границы выводов
После существенной правки проведите следующий раунд на сохранённой версии. Новые подходящие участники помогут уменьшить влияние знакомства с предыдущим вариантом. Если возвращаются те же люди, отметьте, что они уже проходили путь; это влияет на интерпретацию их действий.
Сравнивайте причины затруднений и наблюдаемое поведение. Запись «в первой серии три человека попросили объяснение, во второй такой помощи не потребовалось» описывает ваши встречи при указанных условиях. Она не даёт основания обещать будущий рост конверсии или заявлять процент улучшения для всей аудитории.
Это качественная проверка прототипа. Последовательный показ двух макетов нескольким знакомым сам по себе не становится статистическим A/B-тестом. Для вывода о различии показателей потребуется отдельный план эксперимента, распределение участников и обоснование объёма данных.
Прототип также не подтверждает полную доступность готового сайта. W3C рекомендует сочетать участие людей с инвалидностью с проверкой соответствия стандартам. Бумажный экран помогает обсуждать содержание, но по нему нельзя оценить семантику HTML, управление фокусом и фактическую работу вспомогательных технологий.
По завершении запишите открытые вопросы: какие группы не участвовали, какие устройства и языки не проверялись, где пришлось помогать и какие действия модель не поддерживала. Такой перечень помогает планировать следующий этап, а не перечёркивает полезность уже полученных наблюдений.
Передайте в разработку решения вместе с их основаниями
Результат проверки — версия прототипа, объяснение принятых изменений и список оставшихся вопросов. Дизайнеру и разработчику важно понимать, почему условие стоит рядом с кнопкой или почему подтверждение не должно обещать визит. Без этого обоснования найденное решение легко потерять при оформлении.
Соберите короткий пакет внутри проекта: экраны, задания, журнал, согласованные правки и сценарии будущей приёмки. Свяжите спорные решения с наблюдениями. Там, где данных пока нет, зафиксируйте рабочее предположение и способ его последующей проверки.
Перед запуском повторите ключевые задачи уже на работающем сайте и дополните их проверками, недоступными прототипу: настоящей формой, ошибками, доставкой обращения и выбранными устройствами. Содержание и реализация должны поддерживать один и тот же обещанный посетителю процесс.
- Понятно, какое решение должна поддержать проверка.
- Прототип содержит нужные условия и возможные продолжения действия.
- Участники знакомы с задачей, а задания не подсказывают путь.
- Помощь ведущего и ограничения модели отмечены.
- Факты отделены от предположений и предложенных исправлений.
- Для правок указаны ответственные и повторная проверка.
- Выводы не выходят за пределы проведённого исследования.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- GOV.UK — Plan a round of user research Источник проверен: 03.10.2026
- GOV.UK — How the alpha phase works Источник проверен: 03.10.2026
- NN/g — Writing Tasks for Quantitative and Qualitative Usability Studies Источник проверен: 03.10.2026
- NN/g — Checklist for Planning Usability Studies Источник проверен: 03.10.2026
- GOV.UK — Using moderated usability testing Источник проверен: 03.10.2026
- GOV.UK — Analyse a research session Источник проверен: 03.10.2026
- W3C WAI — Involving Users in Evaluating Web Accessibility Источник проверен: 03.10.2026
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.