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