Заказчик приходит со списком: главная, каталог, о компании, форма обратной связи. Список выглядит понятным, но он описывает не то, что человек будет делать на сайте, а то, из чего сайт состоит. Проектирование с учётом пользовательских потребностей начинается на шаг раньше — с вопроса, зачем сюда приходят и чем заканчивается удачный визит. Ниже — как мы ведём эту работу и что она даёт на выходе.
Потребность и пожелание — разные вещи
Пользователь редко формулирует потребность прямо. Он говорит «хочу фильтр по цене», хотя настоящая задача — быстро понять, укладывается ли товар в бюджет; и решаться она может по-разному. Если брать пожелания буквально, интерфейс обрастает элементами, каждый из которых кто-то когда-то попросил, а общая логика теряется.
Мы разводим три уровня. Задача — что человек пытается сделать. Ограничение — что ему мешает: спешка, телефон в руке, отсутствие данных под рукой. Пожелание — предложенное им решение. Проектируем по первым двум, третье используем как подсказку.
С чего начинаем: сбор фактуры
Перед первым эскизом нужно понять, кто и как пользуется сайтом сейчас. Мы собираем данные из нескольких источников, и важно, что почти все они уже существуют — их не надо создавать с нуля.
- Обращения в поддержку и отдел продаж. Самый честный список проблем: люди звонят там, где интерфейс не справился.
- Записи сессий и карты кликов. Показывают, где посетители останавливаются и куда жмут вместо нужной кнопки.
- Поисковые запросы внутри сайта. Прямая формулировка того, что человек не нашёл в меню.
- Отчёты по формам. На каком поле бросают заполнение и где чаще всего ошибаются.
- Разговоры с сотрудниками. Менеджеры знают возражения клиентов лучше любой аналитики.
Этого набора обычно хватает, чтобы сформулировать гипотезы. Дальше нужны люди: несколько коротких интервью с реальными пользователями дают больше, чем месяц обсуждений внутри команды.
Сценарии вместо структуры страниц
Результат исследования мы оформляем не как отчёт, а как набор сценариев. Сценарий описывает: кто, с каким намерением, с какого устройства, какие шаги проходит и что считается успешным завершением. Например: постоянный клиент хочет повторить прошлый заказ, заходит с телефона, помнит название товара приблизительно.
Дальше на каждый сценарий раскладывается путь по экранам, и здесь обычно вскрываются пробелы: в структуру не заложен вход для повторного заказа, история заказов спрятана в личном кабинете, а поиск не прощает опечаток. Такие вещи дешевле находить на схеме, чем в готовом коде.
Методы исследования: что каждый даёт
Методов много, но выбирать стоит по вопросу, на который нужен ответ, и по имеющемуся времени. Ниже — то, чем мы пользуемся чаще всего.
| Метод | На какой вопрос отвечает | Что нужно для проведения | Чем заканчивается |
|---|---|---|---|
| Интервью с пользователями | Зачем приходят и как решают задачу сейчас | Несколько человек из целевой аудитории | Список задач и ограничений |
| Анализ обращений | Где интерфейс не справляется | Выгрузка из поддержки и CRM | Перечень проблемных мест |
| Веб-аналитика и записи сессий | Где именно теряются посетители | Настроенные счётчики и цели | Карта потерь по шагам |
| Карточная сортировка | Как люди группируют разделы | Список разделов и участники | Структура меню и каталога |
| Тестирование прототипа | Понятен ли путь до заказа | Кликабельный прототип | Правки до начала вёрстки |
| Аудит существующего сайта | Что мешает прямо сейчас | Доступ к сайту и аналитике | Список доработок по приоритету |
Прототип и проверка до дизайна
Мы стараемся довести решение до кликабельного прототипа раньше, чем появится отрисованный макет. Прототип без цвета и картинок хорош тем, что обсуждение идёт про логику, а не про оттенок кнопки. На нём проверяется главное: находит ли человек нужный раздел, понимает ли, что происходит после нажатия, хватает ли ему информации для решения.
Тестирование не требует лаборатории. Достаточно нескольких участников, одной задачи и просьбы проговаривать вслух свои действия. Закономерность известная: первые несколько человек находят большую часть заметных проблем, дальше начинаются повторы. Гораздо важнее не количество участников, а то, чтобы это были не сотрудники компании — они знают, где что лежит, и проходят путь вслепую.
Что делать после запуска
Проектирование не заканчивается сдачей макетов. Мы фиксируем перед запуском, какие показатели считаем важными для каждого сценария, и смотрим их после.
- Доля людей, доходящих до целевого действия по каждому сценарию.
- Шаги, на которых чаще всего бросают путь.
- Ошибки заполнения форм по каждому полю.
- Число обращений в поддержку с вопросами, которые должен закрывать интерфейс.
- Внутренние поисковые запросы без результатов.
Первые недели после запуска дают самую полезную информацию: видно, какие гипотезы подтвердились, а какие требуют доработки. Планировать этот этап нужно заранее, вместе с бюджетом.
Ошибки, которые мы видим чаще всего
- Проектирование по внутренней структуре компании. Меню повторяет отделы, а не задачи посетителя.
- Один усреднённый пользователь. Интерфейс делают под всех сразу, и он не подходит никому конкретно.
- Опрос вместо наблюдения. Люди плохо предсказывают своё поведение, но хорошо показывают его, если дать задачу.
- Мобильная версия по остаточному принципу. Сначала рисуют широкий экран, потом сжимают, и на телефоне выпадает половина смысла.
- Всё важное сразу. Когда на экране выделено десять элементов, не выделен ни один.
- Нет состояний. Продуманы только удачные пути, а пустой список, ошибка и долгая загрузка выглядят как поломка.
Если сайт вроде бы работает, но посетители не доходят до заявки, начинать стоит не с редизайна, а с разбора сценариев и данных, которые уже собраны. Мы спроектируем интерфейс под задачи ваших пользователей: соберём сценарии, сделаем прототип и проверим его на людях до начала разработки.
