VMTech
Обсудить проект
← Все компетенции
ПРОДУКТ И РОСТ · 04

UX Design

Пользователь не «не разобрался». Он дошёл до шага, где не понял, что делать дальше, и ушёл. Наша работа — найти этот шаг раньше, чем он попадёт в продакшен.

Обсудить проект
КАК МЫ РАБОТАЕМ

Как находится шаг, на котором теряются люди

Не «переделать дизайн», а найти конкретное место, где ломается сценарий, и проверить исправление до разработки.

research.vmtech.rs
Сценарий: оформление заказа
LIVE
готово к разработке
Смотрим на данные уход: шаг 3
Говорим с людьми 5 интервью
Собираем сценарий 7 шагов
Прототип кликабельный
Проверка на людях задание выполнено
В разработку готово к разработке
КАК МЫ РАБОТАЕМ
  1. Смотрим на данныеАналитика показывает, на каком экране обрывается путь и сколько людей туда доходит
  2. Говорим с людьмиНесколько коротких интервью с теми, кто пользуется продуктом, и с теми, кто отвечает на их вопросы
  3. Собираем сценарийПуть раскладывается по шагам: что человек знает, что должен решить и чего ему не хватает
  4. ПрототипКликабельный макет собирается за дни, а не за месяц разработки
  5. Проверка на людяхДаём задание и смотрим, где человек останавливается — молча, без подсказок
  6. В разработкуВ работу уходит решение, которое уже прошло проверку, а не догадка
ЗНАКОМАЯ КАРТИНА

Почему «сделайте красиво» не решает задачу

Дизайн без исследования

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

Дизайн от сценария

  • Решения обсуждаются в терминах задачи пользователя, а не личных предпочтений
  • Форма спрашивает ровно то, что нужно сейчас, остальное — позже или само
  • Частые вопросы поддержки превращаются в подсказки и правки интерфейса
  • Ошибки находятся на прототипе, где исправление стоит часы
  • Сценарий проектируется с телефона, а десктоп получает больше места, а не наоборот
ОБЪЁМ РАБОТ

Что входит в UX-работу

Разбор задачи и аудитории

Кто пользуется продуктом, в какой ситуации и какое решение принимает на каждом шаге.

Аудит текущего интерфейса

Проходим сценарии сами и по данным аналитики отмечаем места, где путь обрывается.

Интервью

Короткие разговоры с пользователями и с теми, кто принимает их звонки и сообщения.

Карта сценариев

Основные пути от входа до цели, с точками, где нужны данные, решения или помощь.

Прототипы

Кликабельные макеты ключевых экранов — на них видно логику до того, как написан код.

Проверка с пользователями

Задание, наблюдение и короткий отчёт: где остановились, что поняли не так, что переделываем.

Тексты интерфейса

Подписи, подсказки и сообщения об ошибках, которые объясняют, что делать дальше.

Передача в разработку

Состояния экранов, поведение форм, пустые и ошибочные состояния — чтобы не додумывали в коде.

ЧЕМ ПРОВЕРЯЕМ

Инструменты, которые дают факты вместо мнений

Аналитика путейГде обрывается сценарий и сколько людей до этого шага доходит
Записи сессийВидно, как человек ищет нужное и на чём останавливается
ПрототипированиеКликабельные макеты для проверки логики до написания кода
Модерируемые тестыЗадание и наблюдение — самый честный источник о том, что непонятно
ДоступностьКонтраст, размеры целей, работа с клавиатуры и понятный порядок фокуса
Сравнение вариантовЕсли спор не решается логикой, вариант проверяется на трафике

Мы не обещаем конкретный рост конверсии: он зависит от продукта, цены и спроса. Мы отвечаем за то, что решения принимаются на фактах, а спорные места проверяются до разработки.

ВОПРОСЫ

Что обычно спрашивают

Чем UX отличается от UI?

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

Нужно ли исследование, если продукт уже работает?

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

Сколько нужно людей для теста?

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

Можно сразу рисовать макеты, без исследования?

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

Что вы отдадите в конце?

Карту сценариев, прототипы ключевых экранов, отчёт по проверке с конкретными наблюдениями и описание состояний для разработки. Всё в формате, который читает и разработчик, и человек из бизнеса, — без слайдов ради слайдов.