Первое полезное действие в продукте
Как проверить первое использование продукта
Время чтения: 4 мин
Подходит для уровня: START · Запуск
Кому подойдёт. Тем, кто выпустил первую рабочую версию или видит регистрации без дальнейшего использования.
Содержание
Первое использование заканчивается не созданием учётной записи, а первым понятным результатом для человека. У сервиса учёта заявок это может быть внесённая заявка, которую удалось найти и передать исполнителю. У шаблона — собственный расчёт, который пользователь понимает. Пока результат не определён, трудно отличить полезную активность от блуждания по продукту.
В учебном примере предприниматель запустил кабинет для планирования работ. За неделю зарегистрировались двадцать человек. Автор рад, но никто не вернулся. Возможно, продукт не нужен. А возможно, после входа люди увидели пустой экран, не поняли, как добавить первый заказ, и ушли до знакомства с пользой. Эти причины требуют разных решений.
Определите первый полезный результат
Закончите фразу: «После первого использования человек сможет…» Описывайте действие в его жизни, а не вашу функцию. «Нажать кнопку отчёта» слишком узко. «Увидеть, какие заявки требуют ответа сегодня» — уже результат, который можно проверить.
Не делайте первую задачу искусственно маленькой только ради высокой доли завершений. Если сервис обещает согласовать встречу, простое создание карточки ещё не даёт человеку обещанной пользы. Одновременно не пытайтесь провести новичка через все настройки команды. Выберите минимальный завершённый путь, который имеет самостоятельный смысл.
Разведите действия пользователя и условия за пределами продукта. Для отправки первого приглашения человеку может понадобиться реальный адрес клиента, а для расчёта — сведения о расходах. Если данных нет, это не всегда ошибка интерфейса. Продукт может предложить учебный пример, объяснить подготовку или дать возможность вернуться позже.
Посмотрите на путь глазами нового человека
Начните с источника перехода: какое обещание человек видел до регистрации? Затем проверьте вход, подтверждение адреса, первый экран, ввод данных, выполнение действия и получение результата. Сложность часто возникает между частями, которые команда проверяла по отдельности.
GOV.UK рекомендует при проверке удобства наблюдать, как реальные или потенциальные пользователи выполняют подходящие задачи, и готовить сценарий наблюдения. Для первого использования важно не обучить человека заранее всему продукту. Иначе вы увидите, как работает ваша консультация, а не самостоятельный старт.
Попросите участника действовать на своём обычном устройстве, если это соответствует задаче. Не торопитесь подсказывать после первой паузы. Зафиксируйте, что он прочитал, чего ожидал и где остановился. Если помощь всё-таки потребовалась, продолжите проверку, но отметьте её: результат с подсказкой и без подсказки — разные наблюдения.
Измеряйте несколько понятных событий
Для небольшой версии достаточно простого журнала: начал, дошёл до ключевого действия, получил результат, потребовалась помощь, вернулся к следующей задаче. Не нужно сразу собирать десятки показателей, которыми никто не пользуется. Определите события так, чтобы два человека одинаково посчитали их по одному журналу.
Учебный пример: из двадцати новых пользователей четырнадцать создали первую заявку, девять передали её исполнителю, шесть сделали это без вашей помощи. Доля самостоятельного завершения среди всех начавших — 6 / 20 = 30%. Среди четырнадцати создавших заявку — около 43%. Оба числа могут быть правильными, но отвечают на разные вопросы; знаменатель нельзя менять незаметно.
На таком малом объёме точные проценты не являются устойчивой нормой. Смотрите также на причины остановки. Три человека не нашли нужную кнопку, двое не знали данные клиента, ещё двое ожидали другую возможность. Исправлять всё одной длинной инструкцией будет неэффективно.
- Начали
- 20 новых пользователей.
- Заявка
- 14 создали первую заявку.
- Передача
- 9 передали её исполнителю.
- Без помощи
- 6. Это 30% от всех начавших и около 43% от 14 создавших заявку. Знаменатели разные.
На малой группе проценты не являются устойчивой нормой. Трое не нашли кнопку, двое не знали данные клиента, двое ожидали другое. Эти причины не складывают в одну долю.
Убирайте препятствие в том месте, где оно возникает
Если человек не понимает пустой экран, покажите образец результата и один ясный следующий шаг. Если путает обязательное и необязательное, пересмотрите поля. Если ошибается в формате, объясните его рядом с вводом и помогите исправить без потери всей работы.
Не закрывайте проблему бесконечными всплывающими подсказками. Пользователь может старательно пролистать обучение и всё равно не понять, зачем действие нужно ему. Сначала проверьте сам путь: можно ли убрать лишний шаг, отложить настройку, дать подходящее значение по умолчанию. Предположения и автоматические значения должны быть заметны там, где влияют на результат.
Отдельно проверяйте доступность: читаемость, навигацию с клавиатуры, понятность подписей, использование без зависимости только от цвета. Небольшая группа удобных вам участников может не выявить затруднения других людей. Не объявляйте весь продукт доступным после одной успешной проверки.
Практическое задание
Опишите первый полезный результат и составьте путь из наблюдаемых событий. Проведите проверку с новыми пользователями, отмечая помощь и причины остановки. Выберите одно существенное препятствие, измените соответствующий участок и повторите наблюдение.
В итоговой записи разделите три вывода: результат понятен; его удаётся получить; человек хочет использовать продукт снова. Эти выводы связаны, но не заменяют друг друга. Если задача выполнена легко, а возвращаться незачем, дальнейшая работа касается ценности и частоты потребности, а не только удобства кнопок.