Работая с клиентскими исследованиями в Тестографе, я регулярно сталкиваюсь с одной ситуацией: команда уже собрала аккуратный прототип в Figma, продумала меню и несколько раз обсудила структуру внутри продукта, но во время тестирования пользователи начинают искать нужные функции совсем не там, где ожидали дизайнеры. Причем сам интерфейс может выглядеть логичным — проблема обнаруживается именно в его информационной архитектуре.
Проверять такую структуру только с помощью кликабельного прототипа не всегда удобно. На поведение участника влияют расположение элементов, размер кнопок, иконки, цвета, подписи и другие визуальные подсказки. В результате сложно отделить две разные вещи: пользователь действительно понимает логику продукта или просто замечает нужный элемент на экране.
Для такой задачи полезен Tree Testing — метод исследования, при котором участнику предлагают найти нужный раздел или функцию в текстовой иерархии без привычного интерфейса. Убирая визуальный слой, мы можем посмотреть непосредственно на структуру: понятно ли пользователю, куда идти, правильно ли названы категории и не конкурируют ли между собой соседние разделы.
Именно поэтому Figma и Tree Testing хорошо дополняют друг друга. В Figma команда проектирует будущий интерфейс и его навигацию, а с помощью Tree Testing проверяет, насколько эта навигационная модель совпадает с представлениями пользователей. Причем сделать это можно еще до того, как разработчики начнут реализовывать интерфейс.
В этой статье я разберу весь процесс на практике: как превратить структуру из Figma в дерево, подготовить задания для участников, провести исследование и интерпретировать полученные данные. Отдельно остановлюсь на метриках и ошибках, которые могут привести к неправильным выводам.
Материал будет полезен UX/UI-дизайнерам, исследователям, продуктовым менеджерам и командам, которые проектируют сайты, приложения, личные кабинеты, интернет-магазины и другие продукты со сложной навигацией. Основная задача здесь не в том, чтобы получить еще одну оценку макета, а в том, чтобы ответить на более конкретный вопрос: сможет ли пользователь найти нужную информацию, если оставить ему только логику нашей структуры?
Tree Testing, или древовидное тестирование, — это метод исследования информационной архитектуры, при котором пользователю показывают структуру сайта или продукта в упрощенном виде. Вместо полноценного интерфейса он видит иерархию разделов и подразделов и должен определить, где находится информация или функция, необходимая для выполнения конкретного задания.
Допустим, мы проектируем личный кабинет сервиса. В его основном меню есть разделы «Профиль», «Документы», «Платежи», «Настройки» и «Поддержка». Пользователю дают задачу: «Вы хотите изменить банковскую карту, с которой списывается оплата за подписку. Где вы будете это делать?»
Участник последовательно выбирает ветки дерева. Например:
или:
Для исследователя интересен не только конечный ответ. Важно посмотреть, какую ветку пользователь выбрал первой, насколько прямым был его маршрут, возвращался ли он на предыдущий уровень и какие разделы конкурировали между собой.
Что именно мы проверяем
На практике с помощью Tree Testing я рекомендую разделять как минимум три исследовательских вопроса.
Чем Tree Testing отличается от Card Sorting
Эти методы часто используют при работе с информационной архитектурой, но задачи у них разные.
Card Sorting помогает понять, как сами пользователи группируют информацию. Участникам дают набор карточек — например, названия функций или типов контента — и предлагают объединить их в логичные группы. В открытом Card Sorting они также могут самостоятельно назвать получившиеся категории.
Tree Testing работает с другой стороны. Структура уже существует, а задача исследования — проверить, смогут ли пользователи успешно ориентироваться внутри предложенной иерархии.
Поэтому методы удобно применять последовательно. Card Sorting может дать материал для проектирования архитектуры, после чего команда собирает структуру и проверяет ее с помощью Tree Testing.
А почему не протестировать сразу прототип Figma
Это возможно, но результат будет отвечать уже на более широкий вопрос.
В прототипе участник видит визуальную иерархию: положение меню, размеры элементов, цветовые акценты, иконки, изображения, подсказки. Все это помогает ориентироваться. Если пользователь успешно выполняет задание, мы не всегда можем определить, что именно помогло ему найти нужную функцию.
Tree Testing намеренно убирает эти подсказки.
Представим, что раздел «История платежей» находится в неожиданном месте, но дизайнер сделал на главном экране заметную кнопку «Посмотреть операции». При тестировании прототипа пользователь быстро решит задачу. Можно сделать вывод, что навигация работает.
Но если убрать эту кнопку, станет заметно, что через основную структуру пользователь не понимает, где искать историю. Tree Testing позволяет обнаружить именно такую проблему.
Поэтому я не рассматриваю его как замену тестированию прототипов Figma. Это два уровня проверки. Tree Testing отвечает прежде всего на вопрос «Понятно ли, где искать?», а usability-тестирование прототипа — «Получается ли выполнить действие в реальном интерфейсе?»
Когда Tree Testing особенно полезен
Метод хорошо работает, когда у продукта появляется или существенно меняется информационная архитектура. Например, команда проектирует новый сайт, перерабатывает личный кабинет, объединяет несколько сервисов, меняет каталог интернет-магазина или пытается упростить перегруженное меню.
Полезен Tree Testing и перед редизайном. Иногда команда начинает с визуального обновления, хотя источник пользовательских трудностей находится глубже — в самой структуре. Если человек не понимает, в каком разделе искать функцию, изменение цвета меню или расположения кнопок эту проблему не решит.
При этом тестировать дерево ради самого тестирования не стоит. Если продукт состоит из трех экранов и нужное действие всегда находится перед глазами пользователя, отдельное исследование информационной архитектуры может не дать команде существенной новой информации.
Для меня главный критерий простой: есть ли у пользователя реальный выбор между несколькими направлениями поиска? Если да и ошибка в этом выборе мешает выполнить задачу, Tree Testing становится полезным инструментом.
А связка с Figma позволяет проверить эту логику достаточно рано — до того, как спорное решение превратится в готовый интерфейс, который значительно дороже переделывать.
Самая полезная часть связки Figma и Tree Testing начинается в тот момент, когда мы перестаем воспринимать макет как набор экранов и смотрим на него как на систему пользовательских маршрутов.
В Figma структура продукта обычно распределена между фреймами, компонентами, меню, модальными окнами и переходами. Для Tree Testing все это нужно упростить до дерева: какие варианты видит пользователь на первом уровне, что открывается после выбора каждого из них и где в конечном итоге находится нужная информация или функция.
Здесь есть важный принцип: в Tree Testing нужно переносить не макет, а его информационную архитектуру.
Как превратить макет Figma в дерево
Представим, что в Figma спроектирован личный кабинет с таким меню:
В разделе «Проекты» пользователь может открыть конкретный проект, а внутри него перейти к результатам, интеграциям или настройкам доступа. В «Оплате» находятся тариф, способы оплаты и документы.
Для Tree Testing эта структура может выглядеть так:
Проекты
→ Мои проекты
→ Результаты
→ Интеграции
→ Доступ
Оплата
→ Тариф
→ Способы оплаты
→ Счета и документы
Настройки
→ Профиль
→ Уведомления
→ Безопасность
После этого мы можем задавать пользователю задачи, не показывая сам интерфейс. Например: «Вам нужно скачать закрывающий документ за прошлый месяц. Где вы будете его искать?»
Если большинство участников уверенно выбирает «Оплата → Счета и документы», структура поддерживает этот сценарий. Если значительная часть начинает искать документы в «Проектах» или «Настройках», появляется гипотеза для дальнейшего анализа.
Не переносите из Figma все подряд
Одна из распространенных ошибок при подготовке Tree Testing — попытка максимально точно воспроизвести прототип. В результате дерево превращается почти в текстовую копию интерфейса.
Это не требуется.
Если кнопка «Сохранить» завершает редактирование профиля, ее обычно нет смысла делать отдельным узлом дерева. То же касается декоративных элементов, всплывающих подсказок, состояний кнопок и технических экранов.
Я рекомендую задавать для каждого элемента простой вопрос: может ли пользователь рассматривать его как направление поиска?
Если да — элемент потенциально нужен в дереве. Если нет — скорее всего, его можно исключить.
Tree Testing должен сохранять реальные варианты навигационного выбора, но не обязан воспроизводить каждый экран продукта.
Что делать с фильтрами, табами и вложенными меню
Здесь универсального правила нет. Решение зависит от исследовательской задачи.
Допустим, пользователь ищет отчет за определенный период. Если выбор периода происходит только после того, как человек уже нашел раздел «Отчеты», фильтр по датам не относится к проверяемой информационной архитектуре. Его можно оставить для последующего usability-тестирования прототипа.
Но если в интерфейсе есть табы «Отчеты», «Статистика» и «Экспорт», между которыми пользователь должен выбрать правильное направление, эти элементы уже становятся частью навигационной задачи. Тогда их стоит представить как отдельные ветки.
По этой же причине не нужно механически копировать количество уровней из Figma. Иногда несколько последовательных экранов фактически относятся к одному смысловому уровню. А один экран, наоборот, может содержать несколько независимых направлений навигации.
Уберите визуальные подсказки
Именно здесь Tree Testing дает преимущество перед обычной проверкой кликабельного прототипа.
Представим, что в Figma дизайнер разместил большую карточку «Добавить участника команды», добавил к ней заметную иконку и вынес в верхнюю часть страницы. Пользователь может быстро найти функцию благодаря визуальному акценту.
Но если по основной навигации эта функция находится в неожиданной ветке, проблема останется незаметной.
В Tree Testing участник видит только названия разделов. И если он выбирает «Настройки» вместо «Команда», мы получаем гораздо более чистый сигнал о том, как человек понимает архитектуру продукта.
Поэтому не стоит добавлять в дерево пояснения вроде «здесь можно управлять сотрудниками», если именно понятность названия «Команда» мы собираемся проверять. Такое описание фактически подскажет правильный ответ.
Не каждую проблему нужно сразу исправлять в Figma
После первых результатов возникает соблазн перенести любой неудачный маршрут пользователя в список изменений. Я бы не рекомендовал работать таким образом.
Допустим, 7 из 20 участников выбрали неожиданную ветку. Само по себе это еще не говорит, что раздел необходимо переносить. Нужно посмотреть, насколько системно проявляется ошибка, какой был первый выбор, возвращались ли пользователи назад и одинаково ли ведут себя разные сегменты аудитории.
Кроме того, причина может находиться в формулировке задания. Если сценарий допускает несколько интерпретаций, участники вполне логично могут выбирать разные ветки.
Поэтому между результатами Tree Testing и редактированием макета должен быть этап интерпретации.
На практике рабочий цикл выглядит так:
Последний этап особенно важен. Если после исследования мы переименовали раздел или переместили функцию, это пока только новая гипотеза. Повторный тест показывает, действительно ли изменение сделало маршрут понятнее.
Именно в таком формате я считаю связку Figma и Tree Testing наиболее полезной. Figma остается рабочей средой дизайнера, а Tree Testing становится способом проверить решения до того, как команда вложит ресурсы в их разработку.
Качество Tree Testing во многом определяется не самим деревом, а заданиями. Можно идеально перенести структуру из Figma, собрать достаточное количество участников и все равно получить слабые данные, если сценарии подсказывают правильный путь или допускают несколько трактовок.
При консультировании по методологии опросов я обычно предлагаю начинать не с формулировки заданий, а с исследовательских гипотез. Сначала определяем, что именно вызывает сомнения у команды, и только после этого решаем, какие действия должны выполнить участники.
Сначала сформулируйте гипотезы
Предположим, команда сомневается, где разместить управление доступом сотрудников: внутри «Команды» или в «Настройках». Исследовательский вопрос можно сформулировать так: понимают ли пользователи, где искать изменение прав другого сотрудника?
Это значительно полезнее общего вопроса «Понятна ли пользователям наша навигация?». Второй слишком широкий и не дает критерия, по которому можно интерпретировать результат.
Для одного исследования можно подготовить несколько подобных гипотез:
Так мы заранее определяем проблемные маршруты и не пытаемся протестировать каждый пункт меню только потому, что он присутствует в Figma.
Формулируйте задачу через ситуацию
Одна из наиболее частых методологических ошибок — использовать в задании те же слова, которые участник увидит в дереве.
Например:
Неудачный вариант:
Если в дереве есть пункт «Способы оплаты», исследование почти ничего не проверяет. Мы фактически сообщили пользователю название правильной ветки.
Лучше описать реальную ситуацию:
Более удачный вариант:
Теперь участнику приходится самостоятельно интерпретировать задачу и сопоставлять ее со структурой.
Другой пример.
Неудачный вариант:
Если раздел называется «Команда», ответ практически содержится в вопросе.
Более удачный вариант:
Такой сценарий гораздо ближе к реальному поведению пользователя.
Не превращайте сценарий в загадку
Избегая подсказок, можно уйти в другую крайность и сделать формулировку слишком абстрактной. Пользователь должен понимать, какой результат ему нужен.
Например, задание «В компании произошли кадровые изменения. Что вы будете делать?» не подходит для Tree Testing. Здесь непонятно, должен ли участник удалить сотрудника, изменить его роль, добавить нового человека или сделать что-то еще.
Хорошее задание содержит достаточно контекста для принятия решения, но не называет правильную категорию.
При подготовке сценариев я использую простой тест: сможет ли человек понять конечную цель, не зная структуры нашего продукта? Если нет, формулировку стоит уточнить.
Проверяйте несколько маршрутов, а не все дерево
Если структура содержит 50–100 конечных элементов, это не означает, что участнику нужно дать десятки заданий.
Длинный Tree Testing создает усталость. Участники начинают действовать быстрее, меньше вчитываются в формулировки и чаще выбирают ветки методом исключения. В итоге последние задания могут измерять уже не понятность архитектуры, а желание человека быстрее закончить исследование.
Я предпочитаю выбирать наиболее важные сценарии: частые действия, критичные для продукта маршруты и те части структуры, по которым у команды есть реальные сомнения.
Количество заданий зависит от сложности дерева и сценариев, поэтому универсального числа здесь нет. Для одного проекта десять коротких задач могут проходиться легко, а для другого пять сложных сценариев уже потребуют заметной концентрации.
Перед основным запуском полезно провести несколько пробных прохождений и посмотреть не только на ответы, но и на время, необходимое человеку для завершения исследования.
Учитывайте порядок заданий
Есть еще один эффект, который легко пропустить. Выполняя первое задание, пользователь знакомится с деревом. Во втором он уже знает часть структуры, а к последним сценариям может запомнить расположение многих разделов.
Поэтому результаты первых и последних заданий получены не совсем в одинаковых условиях.
Если исследование большое и методика позволяет, порядок сценариев можно варьировать между участниками. Если такой возможности нет, не стоит помещать все наиболее важные задания в конец теста.
Также следует избегать последовательности, при которой одно задание раскрывает ответ на следующее. Если участник только что нашел раздел «Счета и документы», следующая задача про скачивание акта уже будет проверять в том числе его память.
Сегментация начинается до сбора данных
Одна и та же структура может быть очевидной для опытного пользователя и непонятной для новичка.
Например, сотрудники, которые давно работают с профессиональным B2B-сервисом, могут хорошо знать отраслевую терминологию. Новому клиенту те же названия ничего не скажут. Если объединить обе группы, итоговый процент успешности получится средним и скроет важное различие.
Поэтому еще до запуска стоит определить, какие характеристики участников потенциально влияют на навигационное поведение: опыт использования продукта, роль, тип компании, частота выполнения определенной задачи или другие релевантные признаки.
В исследование можно добавить несколько предварительных вопросов, чтобы затем сравнивать результаты групп. На этом этапе удобно использовать онлайн-опросы Тестографа: в одном исследовании можно собрать необходимые характеристики респондента, ответы на дополнительные вопросы и данные, которые понадобятся для дальнейшей сегментации.
При этом сегментировать аудиторию «на всякий случай» тоже не стоит. Если разбить небольшую выборку на множество групп, в каждой останется слишком мало наблюдений для содержательного сравнения.
Проведите пилот перед основным запуском
Даже тщательно составленный сценарий может восприниматься не так, как предполагал исследователь. Поэтому перед сбором основной выборки я рекомендую дать тест нескольким людям, которые не участвовали в его подготовке.
Нас интересует не процент правильных ответов, а качество методики. Понимают ли участники задания? Нет ли терминов, которые они трактуют по-разному? Не содержат ли формулировки случайных подсказок? Не пропущена ли в дереве ветка, которую человек логично ожидает увидеть?
Если пилот показывает неожиданное поведение, сначала стоит проверить методику и только затем делать вывод о проблеме интерфейса.
В этом и заключается одна из особенностей хорошего Tree Testing: мы проектируем не просто набор кликов по дереву, а контролируемую исследовательскую ситуацию. Чем меньше в ней случайных подсказок и неоднозначностей, тем увереннее можно связывать полученные маршруты с информационной архитектурой, которую команда создала в Figma.
Tree Testing можно воспринимать как отдельный UX-метод, но на практике исследованию часто требуется больше данных, чем просто выбранная участником ветка. Нам может понадобиться определить его опыт, роль, причины выбора, уверенность в ответе или впечатление от структуры. Поэтому я предпочитаю рассматривать древовидное тестирование как часть более широкого сценария исследования.
В Тестографе можно собрать такой сценарий с помощью опроса: провести респондента через необходимые задачи, дополнить их вопросами и сохранить данные для последующего анализа. Особенно это полезно, когда Tree Testing нужно связать с сегментацией аудитории или качественной обратной связью.
Сначала определите структуру исследования
Я бы не начинал с переноса всего дерева из Figma. Сначала полезно выписать исследовательскую схему:
Например, мы хотим проверить, где пользователи ожидают найти управление правами сотрудников. Сначала можем определить опыт респондента, затем описать ситуацию и предложить выбрать раздел. После выбора — при необходимости спросить, почему этот вариант показался наиболее подходящим.
Такая последовательность позволяет получить не только ответ «куда нажал пользователь», но и контекст этого решения.
При этом дополнительные вопросы нужно использовать умеренно. Если после каждого выбора просить человека подробно объяснять ход мыслей, исследование быстро станет утомительным. Открытые вопросы лучше оставлять для наиболее спорных или важных сценариев.
Воспроизведите логику дерева
Для Tree Testing участнику не нужен визуальный макет из Figma. Ему нужна последовательность выборов.
Предположим, первый уровень архитектуры выглядит так:
Если участник выбирает «Оплата», на следующем шаге он должен увидеть только соответствующие подразделы:
Такую механику можно выстраивать через логику опроса и ветвление: дальнейший путь респондента зависит от сделанного ранее выбора.
Здесь важно сохранить структуру, которую мы действительно хотим проверить. Если в Figma пользователь сначала выбирает основной раздел, а затем подраздел, не стоит объединять эти два уровня только для того, чтобы сократить исследование. Иначе мы изменим сам навигационный выбор.
Но и буквально воспроизводить каждый экран не нужно. Как я уже отмечал выше, Tree Testing проверяет информационную архитектуру, а не последовательность экранов интерфейса.
Представим двух участников.
Первый сразу проходит:
Второй сначала выбирает:
Оба в итоге нашли правильный раздел. Если смотреть только на конечный результат, мы запишем два успешных выполнения. Но с точки зрения качества архитектуры их опыт принципиально различается.
Именно поэтому при проектировании исследования заранее нужно решить, какие показатели мы хотим получить. В простом варианте это может быть конечный выбор. В более подробном исследовании полезно учитывать первый выбор, ошибочные направления и возвраты.
Если техническая схема исследования не позволяет надежно восстановить весь маршрут, можно дополнить количественную часть вопросом об уверенности:
Это не заменяет данные о маршруте, но помогает интерпретировать результат. Пользователь мог случайно найти правильный ответ после нескольких попыток и при этом оставаться совершенно неуверенным в структуре.
Добавьте качественный слой
Одна из самых полезных вещей, которую можно получить после проблемного задания, — объяснение участника.
Например:
Ответы могут показать то, чего не видно в процентах. Пользователи могут считать «Настройки» местом для любых административных действий, воспринимать «Команду» исключительно как список сотрудников или вообще не понимать термин, выбранный продуктовой командой.
Для таких случаев удобно использовать разные типы вопросов Тестографа: закрытые вопросы дают данные для сравнения, а открытые позволяют собрать формулировки самих пользователей.
Но здесь есть методологическая тонкость. Если после первого задания попросить человека подробно объяснить устройство меню, он начнет гораздо внимательнее анализировать структуру. Это способно изменить его поведение в следующих заданиях.
Поэтому качественные вопросы лучше размещать выборочно или переносить ближе к концу исследования.
Отделяйте Tree Testing от оценки дизайна
Если мы проверяем дерево, не стоит одновременно показывать участнику скриншоты из Figma и спрашивать, куда он нажал бы на настоящем экране.
В таком случае визуальная иерархия снова начинает влиять на результат, и мы перестаем понимать, что именно измеряем.
Лучше разделить исследование на этапы. Сначала проверить структуру без дизайна. Затем, если необходимо, провести отдельное тестирование прототипа Figma.
Если дерево работает хорошо, а в прототипе пользователи ошибаются, вероятный источник проблемы находится уже в интерфейсе: расположении элементов, визуальных акцентах, подписях или механике взаимодействия.
Если ошибки возникают еще на уровне дерева, имеет смысл сначала разобраться с архитектурой.
Собирайте данные о респондентах только тогда, когда они нужны
В Tree Testing легко увлечься сегментацией и добавить длинную анкету: возраст, должность, отрасль, размер компании, опыт, частоту использования продукта и десяток других параметров.
Каждый дополнительный вопрос увеличивает длину исследования. Поэтому я советую оставлять только характеристики, для которых существует понятная аналитическая гипотеза.
Если мы предполагаем, что опытные и новые пользователи по-разному понимают структуру, спрашиваем об опыте. Если продуктом пользуются администраторы и обычные сотрудники с совершенно разными задачами, фиксируем роль.
После сбора результаты можно анализировать и сравнивать между группами с помощью инструментов аналитики Тестографа.
Так мы получаем не просто общую цифру успешности, а можем увидеть, например, что опытные пользователи находят функцию без затруднений, тогда как новички систематически выбирают другую ветку.
Не пытайтесь сделать из опроса точную копию специализированного Tree Testing-инструмента
Это принципиальный момент. Если исследованию необходимы специализированные показатели вроде автоматического расчета directness, детальной записи каждого возврата по дереву или визуализации путей всех участников, нужно заранее убедиться, что выбранный технический инструмент действительно собирает такие данные.
Тестограф особенно полезен в другом сценарии: когда необходимо построить исследование вокруг пользовательских задач, использовать ветвление, собрать количественные и открытые ответы, добавить сегментацию и затем проанализировать полученные группы.
В моей практике сначала определяется методика и набор необходимых данных, а уже затем под них выбирается техническая реализация. Не наоборот.
Это защищает от распространенной ошибки: провести исследование, а после его завершения обнаружить, что для главного аналитического вопроса нужные данные просто не собирались.
Поэтому перед запуском Tree Testing я советую сделать маленькую таблицу: гипотеза → задание → ожидаемый маршрут → фиксируемые показатели → решение, которое мы сможем принять по результатам.
Если для какой-то задачи последняя колонка остается пустой, стоит подумать, действительно ли ее нужно включать в исследование.
После завершения Tree Testing легко свести результаты к одной цифре: например, 78% участников нашли правильный раздел. Но для анализа информационной архитектуры этого недостаточно. Одинаковый процент успешности может скрывать совершенно разные модели поведения.
В работе с результатами я предпочитаю идти от общего к частному: сначала определить успешность выполнения задачи, затем посмотреть первый выбор и маршруты, найти наиболее частые ошибочные ветки и только после этого сравнивать отдельные группы пользователей.
Успешность выполнения задания
Базовая метрика — Task Success Rate, то есть доля участников, которые в итоге выбрали правильный пункт дерева.
Рассчитывается она просто:
Допустим, 40 человек выполняли задание на поиск платежных документов. 32 участника пришли в нужный раздел. Успешность составляет 80%.
Но считать 80% автоматически хорошим результатом я бы не стал. Универсального значения, после которого информационная архитектура становится «правильной», нет.
Контекст имеет значение. Если пользователь редко ищет справочный материал, определенная доля ошибок может быть допустимой. Если же речь идет о критичной функции, которой регулярно пользуется почти каждый клиент, даже относительно небольшой процент затруднений заслуживает внимания.
Кроме того, нужно учитывать сложность дерева и самой задачи. Поэтому полезнее сравнивать результаты разных сценариев или двух вариантов архитектуры, чем пытаться найти универсальную норму.
Первый выбор часто важнее конечного
Один из показателей, на который я обращаю особое внимание, — первая выбранная ветка.
Представим, что 85% участников в итоге нашли функцию. Результат выглядит убедительно. Но только 45% сразу выбрали правильный основной раздел. Остальные сначала пошли в другие части дерева, вернулись и только затем обнаружили нужный путь.
С формальной точки зрения задача выполнена успешно. С точки зрения пользовательского опыта структура создает заметное трение.
Первый выбор хорошо показывает ожидание пользователя до того, как он познакомился с другими вариантами. Если ошибочные первые клики концентрируются в одной ветке, мы получаем особенно полезный сигнал.
Например:
Если правильный ответ находится в «Команде», я бы не интерпретировал эти 38% просто как ошибки. Скорее всего, «Настройки» выглядят для значительной части аудитории логичной альтернативой. Значит, нужно разбираться, почему две категории конкурируют.
Прямой и непрямой маршрут
Полезно различать пользователей, которые пришли к цели сразу, и тех, кто нашел ее после нескольких попыток.
Условно можно выделить:
Прямой успех:
Непрямой успех:
Неуспех:
Если анализировать только конечную точку, первые два маршрута будут одинаково успешными. Но именно непрямые успешные маршруты часто показывают скрытые проблемы архитектуры.
Пользователь способен решить задачу, но ему приходится исследовать интерфейс методом проб и ошибок.
Ошибочные ветки дают материал для изменений
Сам по себе факт ошибки не всегда объясняет, что нужно изменить. Гораздо полезнее посмотреть, куда именно уходят пользователи.
Если неправильные ответы распределились по всему дереву примерно равномерно, возможно, проблема находится в самом задании или пользователи вообще не понимают терминологию.
Если же большинство ошибок ведет в один конкретный раздел, перед нами сильная альтернативная гипотеза.
Допустим, функция экспорта результатов находится в «Проектах», но 60% ошибившихся участников ищут ее в «Аналитике». Это уже предмет для обсуждения с командой.
Возможны как минимум три решения: перенести функцию, изменить название категории или сделать доступ к ней из нескольких логичных точек. Tree Testing не выбирает решение за дизайнера — он показывает, где пользовательская модель расходится с архитектурой продукта.
Время выполнения используйте осторожно
Время может дополнять анализ, но я не советую рассматривать его отдельно от других показателей.
Человек может долго выполнять задание потому, что структура непонятна. Но он также мог отвлечься, перечитать условие или просто проходить исследование медленнее остальных.
Гораздо интереснее сочетание нескольких признаков:
Такая комбинация уже значительно сильнее указывает на проблему.
При анализе времени также полезно смотреть не только среднее значение. Несколько очень долгих прохождений способны сильно его увеличить. Медиана в таких случаях часто лучше отражает типичное поведение участников.
Сравнивайте задания между собой
Допустим, мы протестировали шесть сценариев и получили такие результаты:
Даже без условного «норматива» видно две проблемные области: права сотрудников и экспорт данных.
Дальше мы можем посмотреть ошибочные маршруты именно по этим сценариям и сформулировать гипотезы для следующей версии структуры в Figma.
Такой анализ полезнее попытки вывести среднюю успешность всего дерева. Среднее значение способно скрыть один критически неудачный маршрут за несколькими очевидными заданиями.
Сегментируйте результаты, если для этого была гипотеза
Предположим, общая успешность задания составляет 74%. После разделения аудитории выясняется:
Теперь вывод меняется. Проблема может быть не в том, что структура непонятна всем, а в том, что она требует знания внутренней логики продукта.
Для существующих клиентов это может быть терпимо, а для сервиса, который активно привлекает новых пользователей, — уже серьезный барьер.
То же относится к разным ролям. Администратор и обычный сотрудник могут по-разному интерпретировать слова «Управление», «Команда», «Доступ» или «Настройки», потому что решают разные задачи.
Не исправляйте каждый неудачный процент
Tree Testing дает данные, но решение все равно требует интерпретации.
Если из 50 человек два участника выбрали необычную ветку, это еще не основание перестраивать меню. Если же 20 человек независимо друг от друга совершили одинаковую ошибку, сигнал гораздо сильнее.
Я обычно смотрю сразу на несколько признаков:
Только после этого стоит возвращаться в Figma и менять архитектуру.
Главная ценность анализа Tree Testing не в том, чтобы получить высокий процент правильных ответов. Нам нужно обнаружить места, где ментальная модель пользователя расходится с моделью, заложенной продуктовой командой. Именно такие расхождения дают наиболее полезный материал для следующей итерации дизайна.
Разберем условный пример. Представим B2B-сервис для управления проектами. Команда готовит редизайн личного кабинета и уже собрала основную структуру в Figma. Одна из задач — сделать навигацию проще для новых пользователей.
На первом уровне находятся пять разделов:
Внутри «Проектов» расположены сами проекты, их результаты и экспорт данных. В «Команде» — сотрудники и приглашения. Управление правами пользователей дизайнеры поместили в «Настройки», поскольку воспринимают права доступа как системный параметр.
На внутреннем обсуждении такая архитектура выглядит логично. Но именно здесь возникает типичная проблема: структура отражает представление команды о продукте, а оно необязательно совпадает с представлением пользователей.
Определяем спорные маршруты
Вместо проверки всего меню я бы сначала выделил несколько решений, в которых команда не уверена.
Например:
Третья гипотеза выглядит наиболее очевидной, но она пригодится как сравнительный сценарий. Если участники легко решают одну задачу и заметно хуже другую, различия становятся информативнее, чем единый средний показатель по исследованию.
Переносим архитектуру из Figma в дерево
Для теста нам не нужны кнопки, карточки и остальные элементы макета. Оставляем только навигационную структуру.
Например:
Проекты
Аналитика
Команда
Оплата
Настройки
Теперь структура лишена визуальных подсказок Figma. Пользователь должен ориентироваться только по смыслу названий и их иерархии.
Составляем сценарии
Для экспорта можно предложить такую ситуацию:
Для проверки прав:
Для платежных документов:
Обратите внимание: в формулировках нет прямых повторений «Экспорт данных», «Права доступа» или «Счета и документы». Иначе мы проверяли бы способность сопоставлять одинаковые слова, а не понимание структуры.
Что показало исследование
Предположим, тест прошли 60 представителей целевой аудитории. Полученные ниже цифры условные — они нужны, чтобы показать логику анализа.
По платежным документам результат оказался ожидаемо высоким:
По экспорту данных правильную конечную точку нашли 72%, но только 48% начали с «Проектов». Еще 42% первым выбором указали «Аналитику».
По изменению прав сотрудника ситуация оказалась еще интереснее. До правильной точки дошли 67%, но «Настройки» первым выбором выбрали только 38% участников. 55% начали с раздела «Команда».
Если посмотреть исключительно на конечную успешность, можно решить, что структура в целом работает: большинство участников все-таки справилось. Первый выбор дает совсем другую картину.
Интерпретируем, а не просто считаем ошибки
В случае экспорта «Аналитика» явно конкурирует с «Проектами». Это объяснимо: пользователь может воспринимать экспорт как работу с данными и результатами, а значит, ожидать соответствующую функцию в аналитическом разделе.
Из этого не следует, что экспорт обязательно нужно переносить в «Аналитику». Если экспорт относится к конкретному проекту, текущее расположение может быть оправдано технически и концептуально.
Но теперь у команды появляется несколько вариантов: изменить название пункта, сделать путь заметнее или предусмотреть дополнительный вход из «Аналитики».
С правами сотрудников сигнал еще сильнее. Большинство участников связывает изменение возможностей конкретного человека прежде всего с самим человеком, а не с системными настройками.
Внутренняя логика команды была такой:
Логика многих пользователей оказалась другой:
Это и есть тот тип расхождения ментальных моделей, ради которого проводится Tree Testing.
Возвращаемся в Figma
После анализа команда меняет структуру.
Управление правами переносится:
Для экспорта принимается другое решение. Вместо полного переноса функции команда оставляет ее внутри проекта, но добавляет дополнительную возможность перейти к экспорту из аналитического раздела.
Теперь изменения можно отразить в Figma и проверить в следующей итерации.
Важно, что мы не редактируем макет просто потому, что «55% нажали не туда». Сначала формулируем объяснение поведения, затем выбираем продуктовую гипотезу и только после этого меняем архитектуру.
Проводим повторный тест
После изменений имеет смысл повторить ключевые задания на новой группе участников. Если использовать тех же людей, они могут запомнить структуру первого теста.
Предположим, после переноса прав доступа правильный первый выбор вырос с 38% до 79%, а итоговая успешность — с 67% до 91%.
Это уже аргумент в пользу новой архитектуры.
С экспортом улучшение может оказаться менее выраженным. Например, правильный первый маршрут вырос с 48% до 63%. Тогда команда решает, достаточно ли такого результата или необходимо искать третью версию структуры.
Именно здесь особенно хорошо проявляется польза связки Figma и Tree Testing. Исследование не заканчивается отчетом с процентами. Оно становится частью итерационного процесса:
Так команда постепенно отделяет решения, которые кажутся логичными изнутри продукта, от решений, которые действительно понятны пользователям. И чем раньше такое расхождение обнаружено, тем проще изменить архитектуру — особенно если разработка новой навигации еще не началась.
Tree Testing выглядит достаточно простым методом: берем структуру из Figma, превращаем ее в дерево, даем пользователям задания и смотрим, куда они идут. Но именно эта простота иногда создает ложное ощущение, что результат исследования можно интерпретировать буквально.
В проектах с опросами и UX-исследованиями я чаще вижу проблемы не на этапе сбора данных, а раньше — при постановке задачи и подготовке методики. Ниже разберу ошибки, которые способны заметно исказить результаты.
Тестировать интерфейс вместо структуры
Главная задача Tree Testing — изолировать информационную архитектуру от визуального оформления. Если вместе с деревом показывать участнику скриншоты Figma, иконки или расположение элементов интерфейса, эта изоляция исчезает.
Например, мы хотим понять, ожидает ли пользователь найти историю операций в разделе «Оплата». Если рядом показать экран, где платежная информация визуально выделена большой карточкой, результат будет зависеть уже не только от названия и положения раздела.
Если задача состоит в проверке визуальной понятности интерфейса, лучше использовать прототип. Если проверяем логику структуры — оставляем только дерево.
Давать правильный ответ в формулировке
Это одна из самых незаметных ошибок.
Допустим, конечный пункт называется «Управление уведомлениями», а задание звучит так:
Пользователю остается найти практически идентичную формулировку.
Лучше описать потребность:
Здесь участнику приходится самостоятельно определить, к какой категории относится задача.
После подготовки сценариев полезно буквально сравнить слова в заданиях с названиями веток. Совпадения не всегда являются проблемой, но каждое из них стоит проверить на наличие подсказки.
Делать дерево слишком подробным
Еще одна крайность — перенести из Figma каждый элемент интерфейса.
В результате участник получает огромное дерево, в котором смешиваются информационная архитектура, отдельные действия, технические состояния и элементы управления.
Если мы проверяем, сможет ли человек найти платежные документы, нам важен маршрут до соответствующего места. Кнопки «Скачать PDF», «Отправить на email» и «Назад» уже относятся к взаимодействию внутри найденного раздела.
Чем больше лишних элементов, тем больше шума появляется в результатах.
Считать любой непрямой маршрут провалом
Пользователь сначала выбрал неправильный раздел, вернулся и самостоятельно нашел нужный. Что записать — успех или ошибку?
Я бы сохранял оба факта.
Конечная задача выполнена успешно, но маршрут был непрямым. Именно такое разделение позволяет не потерять важную информацию.
Если большинство пользователей сначала идет в одну и ту же неправильную ветку, это сигнал о конкуренции категорий. Если непрямые маршруты редки и распределены случайно, проблема может быть значительно менее существенной.
Поэтому бинарного «нашел / не нашел» для хорошего анализа недостаточно.
Делать выводы по слишком маленьким группам
Представим, что исследование прошли 30 человек. После сегментации оказалось, что только четыре из них относятся к определенной профессиональной группе. Трое выбрали один маршрут.
Формально можно написать: «75% представителей сегмента ожидают найти функцию здесь». Но три человека — слишком слабое основание для подобного обобщения.
Особенно осторожно нужно работать с процентами в небольших выборках. Иногда полезнее указать абсолютные значения: «3 из 4 участников», чтобы масштаб данных оставался очевидным.
Сегментацию лучше планировать до запуска. Если сравнение новичков и опытных пользователей важно для решения, необходимо набрать достаточное количество участников в обеих группах.
Объединять аудитории с разными задачами
Обратная проблема возникает, когда всех респондентов анализируют вместе.
Например, в B2B-продукте есть администраторы и обычные сотрудники. Первые регулярно работают с доступами, оплатой и настройками организации. Вторые преимущественно выполняют задачи внутри проектов.
Одинаковая структура для этих групп может восприниматься совершенно по-разному.
Общая успешность в 70% мало что скажет, если у администраторов она составляет условные 90%, а у сотрудников — 50%.
Это не обязательно означает, что одну из групп нужно считать «неправильной». Возможно, продукту действительно требуются разные навигационные решения или более понятные названия для пользователей с разным уровнем доступа.
Менять архитектуру после единичного теста без проверки гипотезы
Tree Testing не выдает готовую новую структуру. Он показывает проблемное место.
Если пользователи массово ищут функцию в другом разделе, можно предположить, что ее стоит перенести. Но возможны и другие решения: переименование, изменение группировки, дополнительная точка входа или разделение слишком широкой категории.
Поэтому результат исследования я рассматриваю как основание для следующей дизайн-гипотезы, а не как прямую инструкцию.
Гораздо надежнее выглядит другой процесс:
Искать универсальный показатель «хорошего дерева»
Иногда команда хочет получить однозначный критерий: например, считать структуру успешной, если 80% пользователей выполняют задания правильно.
Проблема в том, что одинаковая успешность может означать разные вещи.
В одном сценарии 80% участников сразу находят правильную ветку, а остальные выбирают разные варианты. В другом — только 50% сразу идут правильно, еще 30% находят цель после возвратов, причем почти все сначала ошибочно выбирают один конкретный раздел.
Цифра одна, качество структуры разное.
Поэтому я бы не превращал Tree Testing в экзамен, который архитектура должна «сдать» с определенным баллом. Полезнее смотреть на сочетание успешности, первого выбора, маршрутов, ошибочных веток и различий между сегментами.
Хорошее исследование должно не просто ответить «работает структура или нет», а показать где именно пользователь начинает сомневаться и почему.
Если после Tree Testing команда понимает, какой участок архитектуры требует внимания, какие пользовательские ожидания с ним конкурируют и какую гипотезу нужно проверить следующей, исследование уже выполнило свою основную задачу.
Tree Testing особенно полезен не как разовая проверка готового меню, а как промежуточный этап проектирования. Он позволяет проверить информационную архитектуру отдельно от визуального решения и вернуться в Figma с конкретными данными: какие разделы пользователи путают, где начинают поиск и какие маршруты оказываются неожиданно сложными.
На практике я бы не противопоставлял Tree Testing другим UX-методам. Каждый из них отвечает на свой вопрос.
Если команда еще не знает, как пользователи группируют функции или контент, можно начать с Card Sorting. После формирования архитектуры — проверить ее через Tree Testing. Затем собрать интерфейс или кликабельный прототип в Figma и провести usability-тестирование уже с визуальным слоем.
Получается последовательность:
Это не обязательная схема для каждого проекта. Небольшому сайту с несколькими разделами полный исследовательский цикл может быть не нужен. Но чем сложнее продукт, чем больше в нем ролей, функций и уровней навигации, тем дороже обходится ошибка в архитектуре после разработки.
Проверяйте структуру до дорогих изменений
Одно из главных преимуществ Tree Testing — возможность работать с достаточно ранней версией продукта. Нам не обязательно ждать готового дизайна или разработки.
Если в Figma уже понятны основные разделы и их иерархия, эту структуру можно превратить в дерево и проверить ключевые пользовательские маршруты.
Предположим, исследование показывает, что половина новых пользователей ищет важную функцию не в том разделе, который выбрала продуктовая команда. Изменить несколько уровней архитектуры на этом этапе значительно проще, чем после разработки десятков связанных экранов.
Но экономия ресурсов — не единственная причина проводить такую проверку. Не менее важно то, что команда получает общий источник данных для обсуждения.
Вместо спора «мне кажется, пользователи будут искать здесь» появляется более предметный вопрос: почему значительная часть участников выбрала другую ветку и что именно они ожидали там увидеть?
Не заканчивайте исследование отчетом
Я считаю исследование действительно полезным, когда его результаты приводят к проверяемому решению.
Например, Tree Testing показал, что пользователи путают «Аналитику» и «Отчеты». Недостаточно добавить этот факт в презентацию. Нужно определить возможную причину: пересекаются ли значения названий, неправильно ли распределены функции или пользователю вообще не нужно такое разделение.
После этого команда создает новую версию структуры в Figma.
Если изменение существенное, следующий шаг — повторная проверка. Желательно привлечь новых участников, чтобы предыдущий опыт прохождения дерева не влиял на результат.
Так появляется полноценная исследовательская итерация:
В некоторых проектах одного цикла достаточно. В других потребуется несколько итераций, особенно если речь идет о большом каталоге, корпоративной системе или продукте с разными пользовательскими ролями.
Смотрите не только на правильный путь
Если из всей статьи оставить один практический принцип, я бы выбрал этот: в Tree Testing интереснее всего не то, что пользователь нашел, а то, где он ожидал это найти.
Правильный конечный ответ говорит об успешности задачи. Первый выбор и ошибочные маршруты помогают понять пользовательскую модель продукта.
Именно поэтому участник, который ошибся, иногда дает исследователю больше информации, чем тот, кто сразу выбрал предусмотренный командой маршрут.
Если десятки людей независимо друг от друга совершают одну и ту же «ошибку», я бы сначала проверил архитектуру, а не пытался объяснить результат невнимательностью аудитории.
Figma проектирует решение, Tree Testing проверяет его логику
В связке этих инструментов нет необходимости технически объединять их в одну систему. Их связь методологическая.
В Figma мы формулируем гипотезу о том, как должен быть организован продукт. В Tree Testing временно убираем дизайн и проверяем, работает ли заложенная в него логика без помощи визуальных подсказок. После анализа возвращаемся в Figma уже с данными и корректируем решение.
Для организации самого исследования можно использовать Тестограф, дополняя пользовательские сценарии вопросами, сегментацией и сбором обратной связи. Главное — заранее определить, какие данные нужны для проверки конкретной гипотезы, и не пытаться собирать показатели просто потому, что их можно измерить.
В работе с клиентскими исследованиями я придерживаюсь довольно простого правила: сначала определить решение, которое команда собирается принять по результатам исследования, а затем проектировать вопросы и метрики. Такой подход хорошо работает и для Tree Testing.
Тогда исследование перестает быть формальной проверкой макета. Оно становится способом обнаружить расхождение между двумя представлениями о продукте — тем, как его организовала команда, и тем, как его ожидает увидеть пользователь.
И чем раньше мы найдем это расхождение, тем проще исправить его в Figma, а не в уже разработанном продукте.