Тест-сессии

Тест-сессия — это экспертная оценка интерфейса работающего продукта. Во время тест-сессии люди из команды разработки сами проходят пользовательские сценарии и стараются оценить этот опыт.

Разработчики Контура редко пользуются продуктами, которые создают, так как эти продукты для бухгалтеров, предпринимателей, логистов — то есть для B2B-сегмента. Часто такие разработчики фокусируются на создании новых возможностей, но могут забывать об общей картине сервиса. Тест-сессия позволяет посмотреть на работающий продукт широко, как его видит обычный пользователь.

Тест-сессии инициирует любой человек из команды разработки:

• Привлеките представителя бизнес-команды, чтобы составить список продающих и удерживающих сценариев. Бизнес заинтересован в том, чтобы они работали максимально хорошо, и лучше понимает, на что сейчас важно обратить внимание.
• Дополните список частотными сценариями, они больше всего влияют на пользовательский опыт. В Контуре с этим помогли бы UX-исследователи или аналитики.
• Включите в список сценарии, которые в обычной жизни сложно проверить — например, первый вход или подключение новой организации. В таких местах «скапливается пыль», потому что сложно ввести интерфейс в это состояние. В Контуре с этим помогли бы аналитики или тестировщики.
• Вместе с представителем бизнеса отсортируйте сценарии по приоритету и по дате последней проведённой по ним тест-сессии.

Тест-сессии желательно проводить регулярно — раз в полгода или год. Это позволит иметь актуальную картинку по сервису. Можно и чаще, если сценариев в продукте много и результаты предыдущей сессии уже обработаны.

Важно, чтобы тест-сессии проходили с минимумом затрат и с максимумом одобрения команды — тогда их будет проще сделать регулярными и полезными.

• Выберите сценарии, которые можно пройти за 1–2 часа.
• Назначьте ответственного человека из команды на каждую запланированную сессию — его задача обработать результаты и передать их в планирование.
• Синхронизируйте план с бизнес-командой и руководителем разработки, чтобы тест-сессии не были для них сюрпризом, и они запланировали время под исправление багов.
• Расскажите о планах команде разработки. Пусть они тоже будут готовы помочь с организацией, поучаствовать и принести новые задачи.
• Если это не первая тест-сессия, проведите анализ прошлых: оцените, сколько багов закрыли, сколько нет, и почему. Подумайте, что можно улучшить.

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

• При прохождении сценария оцените все аспекты сервиса: читайте подсказки, переходите по ссылкам справки и анализируйте их.
• На встрече фиксируйте только наблюдения и вопросы. Не уходите в технические детали и не придумывайте решения.
• Старайтесь не выбиваться из тайминга.
• Не забудьте сделать видеозапись встречи — она может пригодиться, чтобы подтвердить найденные проблемы.

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

Проведите встречу-презентацию для команды, включая представителей бизнеса: расскажите, что вскрылось на сессии, и соберите обратную связь.

Оформите задачи и загрузите их в соответствующий бэклог. Некоторые пойдут сразу в разработку, другие потребуют проработки дизайна.

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

Какие бывают варианты:

• Выделенный ресурс на дизайнерский долг — процент от ресурсов команды, который регулярно тратится на исправление багов и рефакторинг интерфейса.
• День приборки — выделяется ограниченное время (желательно регулярно), когда команда исправляет как можно больше багов. Менеджеру проще выделить день, чем планировать каждую мелкую задачу.
• Лёгкие баги вёрстки можно править прямо с фронтендером: дизайнер садится рядом и показывает, что исправить. Так проще выпросить час работы, чем двигать десяток задач.
• Дизайнер может участвовать в планировании и продвигать задачи по долгу на обсуждениях.

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

• Обновляйте статусы и дополняйте описания багов по мере их реализации. Это поможет оценить эффективность тест-сессии.
• Храните документацию в публичном пространстве — у всей команды должен быть доступ.