Пользователь не «не разобрался». Он дошёл до шага, где не понял, что делать дальше, и ушёл. Наша работа — найти этот шаг раньше, чем он попадёт в продакшен.
Не «переделать дизайн», а найти конкретное место, где ломается сценарий, и проверить исправление до разработки.
research.vmtech.rs
Сценарий: оформление заказа
LIVE
готово к разработке
Смотрим на данные
уход: шаг 3
Говорим с людьми
5 интервью
Собираем сценарий
7 шагов
Прототип
кликабельный
Проверка на людях
задание выполнено
В разработку
готово к разработке
КАК МЫ РАБОТАЕМ
01Смотрим на данныеАналитика показывает, на каком экране обрывается путь и сколько людей туда доходит
02Говорим с людьмиНесколько коротких интервью с теми, кто пользуется продуктом, и с теми, кто отвечает на их вопросы
03Собираем сценарийПуть раскладывается по шагам: что человек знает, что должен решить и чего ему не хватает
04ПрототипКликабельный макет собирается за дни, а не за месяц разработки
05Проверка на людяхДаём задание и смотрим, где человек останавливается — молча, без подсказок
06В разработкуВ работу уходит решение, которое уже прошло проверку, а не догадка
ЗНАКОМАЯ КАРТИНА
Почему «сделайте красиво» не решает задачу
Дизайн без исследования
Экраны рисуются по вкусу заказчика, а спорят о цвете кнопки, а не о сценарии
Форма просит данные, которые на этом шаге ещё не нужны, — и её бросают
Поддержка каждый день отвечает на один и тот же вопрос, но в интерфейс это не возвращается
Ошибку замечают после релиза, и переделка стоит уже разработки, а не макета
На телефоне интерфейс проверяют в последний момент — а оттуда приходит большинство
Дизайн от сценария
Решения обсуждаются в терминах задачи пользователя, а не личных предпочтений
Форма спрашивает ровно то, что нужно сейчас, остальное — позже или само
Частые вопросы поддержки превращаются в подсказки и правки интерфейса
Ошибки находятся на прототипе, где исправление стоит часы
Сценарий проектируется с телефона, а десктоп получает больше места, а не наоборот
ОБЪЁМ РАБОТ
Что входит в UX-работу
Разбор задачи и аудитории
Кто пользуется продуктом, в какой ситуации и какое решение принимает на каждом шаге.
Аудит текущего интерфейса
Проходим сценарии сами и по данным аналитики отмечаем места, где путь обрывается.
Интервью
Короткие разговоры с пользователями и с теми, кто принимает их звонки и сообщения.
Карта сценариев
Основные пути от входа до цели, с точками, где нужны данные, решения или помощь.
Прототипы
Кликабельные макеты ключевых экранов — на них видно логику до того, как написан код.
Проверка с пользователями
Задание, наблюдение и короткий отчёт: где остановились, что поняли не так, что переделываем.
Тексты интерфейса
Подписи, подсказки и сообщения об ошибках, которые объясняют, что делать дальше.
Передача в разработку
Состояния экранов, поведение форм, пустые и ошибочные состояния — чтобы не додумывали в коде.
ЧЕМ ПРОВЕРЯЕМ
Инструменты, которые дают факты вместо мнений
Аналитика путейГде обрывается сценарий и сколько людей до этого шага доходитЗаписи сессийВидно, как человек ищет нужное и на чём останавливаетсяПрототипированиеКликабельные макеты для проверки логики до написания кодаМодерируемые тестыЗадание и наблюдение — самый честный источник о том, что непонятноДоступностьКонтраст, размеры целей, работа с клавиатуры и понятный порядок фокусаСравнение вариантовЕсли спор не решается логикой, вариант проверяется на трафике
Мы не обещаем конкретный рост конверсии: он зависит от продукта, цены и спроса. Мы отвечаем за то, что решения принимаются на фактах, а спорные места проверяются до разработки.
ВОПРОСЫ
Что обычно спрашивают
Чем UX отличается от UI?
UX отвечает на вопрос «что и в каком порядке происходит», UI — «как это выглядит». Можно нарисовать красивый экран для сценария, который человеку не нужен, и наоборот — правильный сценарий испортить нечитаемой типографикой. В проекте это две разные работы, и мы разделяем их сознательно.
Нужно ли исследование, если продукт уже работает?
Тогда оно как раз дешевле: есть аналитика, есть реальные пользователи и есть поддержка, которая знает больные места наизусть. Часто хватает разбора данных и пяти интервью, чтобы найти шаг, на котором теряется заметная часть людей.
Сколько нужно людей для теста?
Для поиска проблем в сценарии обычно достаточно пяти-восьми человек из вашей аудитории: большинство серьёзных препятствий проявляется уже на первых участниках. Если задача — сравнить два варианта по цифрам, это другая история: там нужен трафик, а не интервью.
Можно сразу рисовать макеты, без исследования?
Можно, и иногда это оправдано — например, когда сценарий типовой и уже отработан рынком. Но если продукт нестандартный, экраны без сценария придётся переделывать после запуска, когда цена ошибки выше. Мы говорим прямо, когда исследование не нужно, — это тоже часть работы.
Что вы отдадите в конце?
Карту сценариев, прототипы ключевых экранов, отчёт по проверке с конкретными наблюдениями и описание состояний для разработки. Всё в формате, который читает и разработчик, и человек из бизнеса, — без слайдов ради слайдов.