Когда команда проектирует новый интерфейс в Figma, довольно легко попасть в ловушку собственной логики. Дизайнеры, продакт-менеджеры и разработчики месяцами работают с продуктом, знают его функции и понимают внутреннюю терминологию. Поэтому структура, которая кажется команде очевидной, для нового пользователя может выглядеть совершенно иначе.
Представим личный кабинет сервиса с несколькими десятками функций. Команда распределила их по пяти разделам, подготовила навигацию и уже начала собирать прототип в Figma. Внутри проекта все выглядит последовательно: каждый пункт находится там, где его ожидают увидеть разработчики и владельцы продукта. Но после запуска выясняется, что пользователи регулярно открывают не те разделы, ищут нужную функцию через несколько экранов или вообще не понимают, к какой категории она относится.
Проблема здесь может быть не в визуальном дизайне. Интерфейс способен быть аккуратным, современным и технически удобным, но при этом опираться на информационную архитектуру, которая отражает представление команды о продукте, а не ментальную модель пользователя.
Именно в таких ситуациях полезен Card Sorting — метод карточной сортировки. Участникам исследования предлагают набор объектов — например, названия функций, страниц или категорий — и просят распределить их по группам. В зависимости от методики пользователь либо самостоятельно формирует категории, либо сортирует карточки по заранее заданным разделам.
Для меня как специалиста Тестографа, работающего с анализом данных и методологией опросов, ценность такого исследования заключается не только в самой сортировке. Намного интереснее момент, когда ответы нескольких десятков участников начинают превращаться в структуру данных. Мы можем увидеть, какие элементы люди стабильно воспринимают как связанные, где мнения расходятся и какие названия категорий оказываются неоднозначными.
В результате появляется возможность обсуждать информационную архитектуру не только на уровне «мне кажется, этот пункт должен находиться здесь». У команды возникают пользовательские данные, с которыми уже можно работать при проектировании.
Связка Figma + Card Sorting особенно полезна на раннем этапе, когда изменение структуры еще относительно дешево. Вместо того чтобы сначала детально прорисовывать десятки экранов, а затем обнаруживать проблемы навигации во время UX-тестирования или после запуска продукта, можно раньше проверить сам принцип организации информации.
При этом Card Sorting не следует воспринимать как инструмент, который автоматически спроектирует интерфейс. Если большинство участников объединили несколько карточек в одну группу, это еще не означает, что дизайнер обязан буквально воспроизвести эту группировку в меню. На итоговую архитектуру влияют пользовательские сценарии, бизнес-требования, технические ограничения, частота использования функций и другие данные.
Поэтому в этой статье я предлагаю рассматривать Card Sorting не отдельно от дизайна, а как один из этапов исследовательского процесса: гипотеза о структуре → карточная сортировка → анализ результатов → изменение информационной архитектуры → прототип в Figma → дальнейшая проверка решения.
Разберем, как подготовить такое исследование, какие элементы макета стоит превращать в карточки, как избежать методологических ошибок и, главное, как интерпретировать полученные результаты так, чтобы они действительно помогали принимать решения в Figma.
Материал будет полезен UX/UI-дизайнерам, UX-исследователям, продуктовым командам и владельцам цифровых продуктов. Особенно — тем, кто проектирует сайты, приложения, личные кабинеты, каталоги и другие интерфейсы со сложной структурой и хочет проверять ее на пользователях до того, как значительная часть дизайна уже готова.
Card Sorting, или карточная сортировка, — это исследовательский метод, который помогает понять, как пользователи группируют информацию и какие связи между элементами кажутся им естественными.
Механика исследования выглядит просто. Мы берем элементы будущего или существующего интерфейса и представляем их в виде отдельных карточек. Это могут быть названия разделов интернет-магазина, функции приложения, пункты базы знаний, настройки личного кабинета или услуги компании. Затем участники распределяют карточки по категориям в соответствии с условиями исследования.
Допустим, мы проектируем сервис для управления проектами. В нем планируются функции «Создать задачу», «Участники команды», «История изменений», «Шаблоны», «Уведомления», «Отчеты», «Интеграции» и «Права доступа».
Команда может заранее решить, что «Участники команды» и «Права доступа» должны находиться в настройках, «Отчеты» — в аналитике, а «Шаблоны» — внутри раздела с задачами. Но пользователи необязательно воспринимают продукт таким же образом.
В Card Sorting мы можем не объяснять им внутреннюю логику продукта, а предложить самостоятельно разобраться с набором карточек. Именно здесь метод становится особенно полезным: он показывает не то, насколько человек понял уже созданную навигацию, а то, как он сам склонен организовывать представленную информацию.
Три варианта Card Sorting
На практике я рассматриваю выбор типа сортировки как часть методологии исследования. Нельзя сказать, что открытый или закрытый вариант сам по себе лучше. Они отвечают на разные вопросы.
Открытый Card Sorting
При открытой сортировке участник самостоятельно объединяет карточки и придумывает названия получившимся категориям.
Такой формат полезен, когда информационная архитектура еще не определена или команда готова существенно ее изменить.
Например, мы даем пользователю 25 функций будущего сервиса и просим объединить их так, как ему кажется логичным. Один участник может создать категории «Работа с проектом», «Команда», «Настройки» и «Аналитика». Другой — «Ежедневная работа», «Управление», «Отчеты» и «Интеграции».
Отдельный интерес представляют названия этих групп. Они позволяют увидеть не только связи между объектами, но и лексику, которую используют сами участники.
При этом я бы не советовал выбирать название раздела интерфейса простым голосованием. Если восемь человек назвали похожую группу «Управление», это еще не доказывает, что именно такое название будет хорошо работать в навигации. Оно может оказаться слишком широким или неоднозначным. Результат Card Sorting здесь становится источником гипотез, которые затем желательно проверить отдельно.
Закрытый Card Sorting
При закрытой сортировке категории уже определены исследователем. Задача участника — решить, куда относится каждая карточка.
Предположим, в Figma уже существует меню:
Мы хотим понять, насколько понятно распределение функций между этими разделами. Пользователь получает карточку «Экспорт данных» и выбирает категорию, в которой ожидал бы ее найти. Затем делает то же самое с «Уведомлениями», «Ролями сотрудников», «Архивом проектов» и остальными элементами.
Если большая часть участников относит определенную функцию не туда, куда ее поместила продуктовая команда, появляется повод внимательнее изучить этот участок архитектуры.
Но здесь важно не делать вывод слишком быстро. Например, распределение 60/40 не означает автоматически, что вариант с 60% правильный, а с 40% — неправильный. Возможно, сама карточка сформулирована неоднозначно. Возможно, категории пересекаются по смыслу. А иногда мы видим две разные ментальные модели у разных сегментов аудитории.
Поэтому проценты в Card Sorting — начало анализа, а не готовое дизайнерское решение.
Гибридный Card Sorting
Гибридный вариант находится между открытым и закрытым. Мы предлагаем участникам готовые категории, но разрешаем создавать собственные, если ни одна из существующих не подходит.
Для продуктовой команды это интересный сценарий, когда основная архитектура уже сформирована, но остается пространство для изменений.
Допустим, в проекте предусмотрено пять разделов. Большинство карточек пользователи успешно распределяют между ними, но для нескольких функций регулярно создают новую категорию «Безопасность». Это уже исследовательский сигнал: возможно, существующая структура недостаточно хорошо отражает отдельную пользовательскую задачу.
При этом сам факт появления новой категории еще не означает, что в интерфейс необходимо добавить шестой раздел. Сначала нужно разобраться, почему участники принимали такое решение.
Какие задачи можно решать с помощью Card Sorting
Чаще всего метод используют при проектировании информационной архитектуры. Однако под этим довольно широким определением скрывается несколько практических задач.
С помощью карточной сортировки можно исследовать:
Особенно полезным Card Sorting становится тогда, когда элементов достаточно много и существует несколько правдоподобных способов их организации.
Если в интерфейсе всего три функции и их назначение очевидно, полноценное исследование может быть избыточным. Но когда появляются десятки объектов, несколько уровней вложенности и пересекающиеся по смыслу категории, одной дизайнерской экспертизы становится недостаточно.
Чего Card Sorting не показывает
Одна из распространенных методологических ошибок — ожидать от карточной сортировки ответов на вопросы, для которых она не предназначена.
Card Sorting не показывает, сможет ли пользователь выполнить конкретный сценарий в готовом интерфейсе. Он также не отвечает напрямую на вопрос, заметит ли человек кнопку, поймет ли иконку, справится ли с формой или сколько времени ему потребуется для выполнения задачи.
Представим, что участники практически единогласно отнесли карточку «Смена пароля» в категорию «Безопасность». Это хороший аргумент в пользу такой смысловой связи. Но из результата нельзя сделать вывод, что пользователь без проблем найдет смену пароля в реальном интерфейсе.
В готовом продукте раздел «Безопасность» может находиться слишком глубоко. Его название может быть визуально незаметным. Пользователь может сначала искать пароль в профиле. На мобильном устройстве навигация вообще может работать иначе.
Все это уже требует других методов проверки.
Поэтому перед запуском Card Sorting я рекомендую сформулировать исследовательский вопрос максимально конкретно. Например:
или:
Такие формулировки намного полезнее абстрактного «проверить удобство интерфейса».
Card Sorting — не голосование за структуру
Еще одна ошибка, с которой приходится сталкиваться при анализе исследований, — желание превратить результаты сортировки в готовое дерево интерфейса.
Допустим, 70% участников объединили карточки A, B и C. Возникает соблазн просто создать для них один раздел в Figma.
Но прежде я бы посмотрел как минимум на три вещи.
Поэтому для меня результат хорошего Card Sorting — не готовая информационная архитектура, которую остается перенести в Figma. Это набор данных о пользовательской логике.
Дальше задача исследователя и дизайнера — понять эту логику, сопоставить ее с контекстом использования продукта и только после этого решить, какие изменения действительно стоит внести в структуру интерфейса.
Figma и Card Sorting решают разные задачи, поэтому их полезно рассматривать не как два альтернативных инструмента, а как последовательные этапы одного процесса. Figma помогает команде сформулировать и визуализировать предполагаемую структуру продукта, а карточная сортировка позволяет проверить, насколько эта структура совпадает с представлениями пользователей.
На практике я бы не начинал исследование с вопроса «Какие карточки нам сделать?». Сначала необходимо понять, какое решение команда собирается принять на основании результатов. Именно этот вопрос определяет весь дальнейший сценарий.
Например, дизайнер работает над личным кабинетом и сомневается, куда поместить функции управления сотрудниками, ролями и правами доступа. В этом случае исследовательская задача достаточно узкая. Если же команда полностью пересматривает навигацию большого сервиса, потребуется более масштабное исследование с другим набором карточек.
От макета к исследовательской гипотезе
Figma часто становится точкой, в которой проблема впервые становится заметной. При построении пользовательских потоков и экранов дизайнер обнаруживает, что некоторые функции можно логично разместить сразу в нескольких разделах.
Возьмем условный B2B-сервис. В его настройках есть функции «Добавить сотрудника», «Изменить роль», «Ограничить доступ», «История действий» и «Настроить уведомления».
Куда должна вести навигация к этим функциям?
«Изменить роль» можно разместить внутри профиля конкретного сотрудника. «Ограничить доступ» — в разделе безопасности. Обе функции можно объединить в «Управление командой». А можно создать отдельный раздел «Роли и права».
Все четыре решения способны выглядеть логично на макете. Именно поэтому обсуждение внутри команды иногда продолжается часами: у каждого варианта находятся убедительные аргументы.
Card Sorting позволяет изменить характер такого обсуждения. Вместо вопроса «Какой вариант кажется нам наиболее понятным?» появляется исследовательский вопрос: «Какие из этих функций сами пользователи воспринимают как связанные?»
Это важное различие. Мы не просим респондентов стать дизайнерами и придумать интерфейс. Мы исследуем их представления о структуре информации.
Как элементы Figma превращаются в карточки
Не каждый объект на макете нужно переносить в исследование. Если просто взять все подписи, кнопки и пункты меню из Figma, получится набор элементов разных уровней: рядом окажутся крупные разделы, отдельные функции и конкретные действия.
Такой набор будет сложно интерпретировать.
Представим карточки «Профиль», «Безопасность», «Изменить пароль», «Скачать отчет» и «Настройки». Здесь уже возникает проблема. «Настройки» могут быть верхним уровнем архитектуры, «Безопасность» — подразделом, а «Изменить пароль» — конкретным действием внутри него.
Участник вынужден сравнивать объекты, которые изначально находятся на разных уровнях абстракции. В итоге мы можем получить необычные группировки не потому, что так устроена ментальная модель пользователя, а потому, что само исследование было подготовлено некорректно.
Поэтому при переносе структуры из Figma я сначала определяю единицу анализа. Если исследуем функции — карточками должны быть функции. Если категории товаров — категории сопоставимого уровня. Если разделы базы знаний — темы примерно одинакового масштаба.
Это кажется небольшим методологическим требованием, но от него сильно зависит качество результатов.
Не показывать пользователю готовый ответ
Еще одна особенность связки с Figma заключается в том, что готовый макет может невольно влиять на результаты.
Допустим, дизайнер уже создал меню и разместил «Интеграции», «API» и «Импорт данных» внутри одного раздела. Если перед Card Sorting показать этот интерфейс участнику, а затем попросить сгруппировать те же элементы, мы уже не исследуем его первоначальное представление.
Человек видел предложенную классификацию и может воспроизвести ее в сортировке.
Поэтому, когда задача исследования заключается именно в поиске естественной структуры, я предпочитаю отделять карточки от готового дизайна. Участнику не обязательно знать, где элементы находятся в текущем макете.
Это особенно важно для открытой сортировки. Ее ценность как раз заключается в возможности увидеть структуру, которая возникает без заранее заданной архитектуры.
Если же мы проверяем уже существующую классификацию, ситуация другая. Тогда закрытый Card Sorting может быть построен вокруг конкретных категорий продукта. Но и здесь важно понимать, что именно мы измеряем: самостоятельную модель пользователя или его способность разобраться в предложенной нами модели.
Исследование как промежуточный этап, а не финальная проверка
Card Sorting часто хочется провести тогда, когда дизайн уже практически закончен. Макеты согласованы, компоненты собраны, прототип работает — осталось «проверить навигацию».
Для команды это удобный момент организационно, но не всегда удачный методологически.
Если исследование обнаружит серьезную проблему в архитектуре, стоимость изменений окажется высокой. Придется перестраивать навигацию, менять пользовательские потоки и переделывать связанные экраны. Поэтому карточную сортировку выгоднее проводить тогда, когда структура еще остается гипотезой.
Рабочий процесс может выглядеть следующим образом:
В этой последовательности Figma используется не только для создания финального интерфейса. Она становится рабочим пространством для гипотез, которые еще можно менять.
Что происходит после сбора ответов
Самая важная часть начинается после того, как участники закончили сортировку.
Предположим, команда проверяет 20 функций. После исследования мы видим, что 14 из них участники группируют достаточно последовательно, а вокруг остальных шести постоянно возникают расхождения.
На этом этапе неправильным решением было бы сосредоточиться только на 14 понятных функциях и сказать, что исследование подтвердило структуру. Для меня значительно интереснее именно спорные элементы.
Почему одна функция оказывается сразу в трех разных категориях? Почему часть участников связывает ее с настройками, а другая — с аналитикой? Почему пользователи одного сегмента группируют карточки иначе, чем другого?
Иногда проблема находится не в архитектуре, а в терминологии. Название функции может быть слишком техническим или допускать несколько интерпретаций. В других случаях расхождение действительно показывает, что пользовательские представления не совпадают с моделью команды.
Поэтому результаты стоит рассматривать не только как распределение карточек, но и как материал для поиска причин.
Как данные превращаются в изменения в Figma
После анализа мы возвращаемся к макету, но уже с другой отправной точкой.
Допустим, команда предполагала отдельные разделы «Команда» и «Доступы». В исследовании пользователи постоянно объединяли управление сотрудниками, роли и разрешения. Это аргумент для проверки более общей категории.
В другом случае может обнаружиться обратная ситуация. Команда собрала десять функций внутри «Настроек», тогда как участники стабильно делят их на три смысловых блока. Это повод пересмотреть слишком широкую категорию.
Важно, что результат не обязательно приводит к полной перестройке интерфейса. Иногда достаточно изменить название раздела. Иногда — перенести одну функцию. Иногда исследование подтверждает исходную гипотезу команды.
Хороший результат Card Sorting — это не обязательно большое количество изменений. Его ценность в снижении неопределенности.
В работе с исследованиями я стараюсь разделять наблюдение и дизайнерское решение. «Пользователи часто объединяют карточки A и B» — это наблюдение. «Нужно поместить A и B в один раздел» — уже решение команды.
Между этими двумя утверждениями должен существовать этап интерпретации.
Именно поэтому связка Figma и Card Sorting работает лучше всего не как механический процесс переноса результатов исследования в макет, а как цикл проверки гипотез. Мы создаем предполагаемую структуру, получаем данные о пользовательской логике, корректируем решение и только затем увеличиваем детализацию прототипа.
Следующий важный вопрос — как подготовить сами карточки так, чтобы исследование не создавало искусственных закономерностей. От формулировок, количества элементов и выбранного уровня детализации результаты зависят не меньше, чем от размера выборки.
Качество Card Sorting во многом определяется еще до того, как первый участник приступит к сортировке. Если карточки подобраны неудачно, смешивают разные уровни структуры или содержат подсказки, увеличение выборки проблему не исправит. Мы просто получим больше данных, основанных на некорректно поставленной задаче.
Поэтому при подготовке исследования я обычно двигаюсь от исследовательского вопроса к карточкам, а не наоборот. Figma в этом процессе становится источником материала: из проекта можно извлечь существующие разделы, функции и элементы будущей архитектуры. Но затем этот набор необходимо адаптировать под исследование.
Сначала определяем, какое решение нужно принять
Формулировка «Хотим проверить структуру приложения» слишком широкая. Непонятно, какую часть структуры мы проверяем и что будем делать с результатами.
Гораздо полезнее поставить конкретную задачу. Например: понять, как пользователи группируют функции управления аккаунтом; проверить распределение товаров по разделам каталога; определить, какие темы базы знаний воспринимаются как связанные; выяснить, соответствует ли существующая навигация ожиданиям новых пользователей.
Такой подход помогает сразу определить границы исследования.
Допустим, команда проектирует большой личный кабинет, состоящий из 80 функций. Это не означает, что все 80 функций необходимо включить в одну сортировку. Если нас интересует только организация настроек аккаунта, разумнее исследовать соответствующую часть продукта отдельно.
Здесь действует простой принцип: каждая карточка должна помогать ответить на исследовательский вопрос. Если мы не понимаем, зачем конкретный элемент присутствует в исследовании, возможно, его там быть не должно.
Выбираем единый уровень карточек
Одна из наиболее частых проблем появляется, когда команда напрямую копирует названия из Figma.
В макете одновременно существуют объекты разных уровней. Например, «Аккаунт» может быть крупным разделом, «Безопасность» — подразделом, «Пароль» — настройкой, а «Изменить пароль» — конкретным действием.
Если предложить пользователю сортировать все эти элементы одновременно, он получает неоднородную систему. Одни карточки включают другие по смыслу, поэтому результаты становятся сложными для интерпретации.
Перед исследованием я рекомендую определить, что именно является объектом сортировки.
Если мы изучаем организацию функций, карточка может обозначать действие: «Изменить пароль», «Добавить сотрудника», «Скачать отчет». Если исследуем структуру контента, объектами могут быть темы или типы материалов. Если работаем с каталогом, карточками становятся товары или товарные категории сопоставимого уровня.
Особенно внимательно стоит проверять пары, в которых одна карточка очевидно является родительской для другой. Например, сочетание «Способы оплаты» и «Добавить банковскую карту» уже содержит потенциальную подсказку относительно группировки.
Формулировка карточки влияет на результат
Название должно быть достаточно понятным, чтобы участник мог определить смысл элемента без дополнительных объяснений. Но оно не должно подсказывать, куда этот элемент следует поместить.
Представим, что в продукте есть функция управления уведомлениями.
Карточку можно назвать «Настройки уведомлений в профиле». Но слово «профиле» фактически сообщает участнику предполагаемое местоположение функции. Если затем большинство респондентов отнесет карточку к категории «Профиль», ценность такого результата будет небольшой.
Нейтральный вариант — «Управление уведомлениями».
Есть и противоположная проблема — слишком короткие названия. Карточка «Доступ» может означать права сотрудников, вход в аккаунт, доступность документа или тарифные ограничения. Если участники интерпретируют слово по-разному, мы будем анализировать не информационную архитектуру, а последствия неоднозначной формулировки.
В подобных случаях полезно добавить короткое нейтральное пояснение. Главное, чтобы оно объясняло функцию, но не ее предполагаемое место в интерфейсе.
Не переносим внутренний язык команды без проверки
За время разработки продукта команда привыкает к собственной терминологии. Слова вроде «пространство», «объект», «сущность», «коннектор» или «воркфлоу» могут использоваться каждый день и казаться совершенно естественными.
Для пользователя они не обязательно имеют такой же смысл.
Это особенно заметно в B2B-продуктах. Иногда участник неправильно группирует карточку не потому, что у него необычная ментальная модель, а потому, что он просто иначе понял внутренний термин.
Поэтому перед запуском я отдельно просматриваю названия карточек с точки зрения человека, который не участвовал в разработке. Если термин требует знания внутренней логики продукта, стоит проверить, действительно ли именно этот термин является предметом исследования.
Здесь важно не перестараться с упрощением. Если профессиональная аудитория регулярно использует конкретное понятие, заменять его искусственно простым выражением тоже не нужно. Язык исследования должен соответствовать языку той аудитории, для которой создается продукт.
Сколько карточек использовать
Универсального числа карточек, подходящего для любого проекта, нет. Количество зависит от сложности предметной области, сходства элементов и задач исследования.
Однако принцип «чем больше, тем лучше» здесь не работает.
При слишком маленьком наборе участнику может быть очевидна предполагаемая структура, и мы получим довольно поверхностный результат. При чрезмерно большом количестве карточек увеличивается когнитивная нагрузка. Человек устает, начинает группировать элементы менее внимательно или создает слишком общие категории просто для того, чтобы быстрее закончить задание.
Я предпочитаю оценивать набор не только количественно, но и содержательно. Если без нескольких карточек невозможно увидеть интересующую нас закономерность, их стоит оставить. Если элементы присутствуют исключительно для полноты копирования интерфейса, их можно исключить.
Иногда лучше провести два сфокусированных исследования, чем одно огромное.
Как подготовить категории для закрытой сортировки
При закрытом Card Sorting отдельного внимания требуют названия категорий. Здесь исследователь фактически задает верхний уровень архитектуры, а участники проверяют распределение элементов внутри него.
Категории должны быть достаточно различимыми по смыслу.
Например, если одновременно существуют «Аккаунт», «Профиль» и «Настройки», необходимо убедиться, что пользователь действительно понимает различия между ними. Для команды эти понятия могут обозначать три конкретные области продукта. Для нового пользователя они способны выглядеть почти взаимозаменяемыми.
Если карточки постоянно распределяются между двумя похожими категориями, это необязательно говорит о проблеме самих карточек. Возможно, пересекаются категории.
Полезно также предусмотреть ситуацию, когда участник не может уверенно определить место элемента. Принудительное распределение каждой карточки иногда создает ложную определенность: человек выбирает случайный вариант только потому, что исследование не позволяет поступить иначе.
Такие затруднения сами по себе могут быть ценными данными.
Проверяем исследование до запуска
Перед основной выборкой я всегда считаю полезным провести небольшой пилот. Его задача — не получить первые проценты для отчета, а проверить методику.
Наблюдая за тем, как несколько человек проходят сортировку, можно обнаружить проблемы, которые сложно заметить при подготовке внутри команды. Например, две карточки могут восприниматься как дубликаты. Термин, который казался понятным, вызывает вопросы. Одна категория оказывается слишком широкой и собирает почти все элементы.
Особенно полезно после прохождения попросить участника объяснить несколько решений: почему эти карточки оказались вместе, что для него означает конкретное название, между какими категориями он сомневался.
Такие комментарии помогают понять, измеряет ли исследование именно то, что мы планировали измерить.
Если после пилота приходится изменить несколько карточек, это нормальный результат. Значительно хуже обнаружить проблему после того, как исследование уже прошли десятки или сотни участников.
Перед полноценным запуском я проверяю четыре вещи: соответствует ли набор исследовательскому вопросу, находятся ли карточки примерно на одном уровне, понятны ли формулировки без контекста макета и не содержат ли они подсказок.
После этого можно переходить к выборке и организации самого исследования. И здесь появляется следующий риск: даже идеально подготовленные карточки не дадут надежного результата, если сортировку проходят люди, которые не соответствуют аудитории продукта, или если участники не понимают поставленную перед ними задачу.
После подготовки карточек возникает соблазн как можно быстрее запустить исследование и начать собирать ответы. Но количество пройденных сортировок само по себе ничего не говорит о качестве данных. Пятьдесят случайных участников могут дать менее полезный результат, чем двадцать человек, которые действительно соответствуют аудитории продукта и одинаково понимают поставленную задачу.
Поэтому перед запуском я обращаю внимание не только на количество респондентов, но и на то, кто именно будет сортировать карточки, в каком контексте и какую инструкцию получит.
Выборка должна соответствовать продукту
Представим, что мы проектируем интерфейс системы для бухгалтеров. Можно быстро собрать участников, которые регулярно пользуются цифровыми сервисами, и попросить их распределить карточки «Акт сверки», «Счет-фактура», «Контрагент», «Закрывающие документы» и другие элементы.
Технически исследование состоится. Мы получим группы, категории и проценты совпадений. Однако возникает вопрос: отражают ли эти данные представления будущих пользователей системы?
Если человек не работает с подобными задачами, он будет классифицировать незнакомые понятия исходя из общего значения слов. Бухгалтер же может опираться на профессиональный опыт и реальные рабочие сценарии. Это две разные ментальные модели.
Поэтому критерии отбора участников должны вытекать из аудитории продукта. Для массового интернет-магазина требования могут быть довольно широкими. Для специализированного B2B-сервиса профессиональный опыт способен стать критически важным условием.
При этом не всегда нужно приглашать только действующих пользователей конкретного продукта. Если мы хотим проверить, насколько структура понятна человеку при первом знакомстве, наоборот, полезно исследовать потенциальных пользователей, которые еще не привыкли к существующей навигации.
Новые и опытные пользователи могут сортировать по-разному
Стаж взаимодействия с продуктом — отдельный фактор, который я рекомендую учитывать при анализе.
Постоянный пользователь уже знает, где находятся функции. Если годами раздел «Документы» располагается внутри «Проектов», человек может воспроизводить знакомую структуру даже в том случае, если она изначально была не самой естественной.
Новый пользователь такой привычки не имеет.
Это не означает, что одна группа дает правильные ответы, а другая — неправильные. Они отвечают на разные исследовательские вопросы. Опытные пользователи показывают модель, сформировавшуюся при реальной работе с продуктом. Новые — первоначальные ожидания.
Если эти группы смешать и анализировать как единую выборку, важное различие может исчезнуть за средними показателями.
Поэтому при наличии соответствующей задачи я заранее собираю характеристики участников, которые позднее позволят сегментировать результаты.
Инструкция не должна обучать участника структуре
Хорошая инструкция объясняет задачу, но не объясняет, как именно нужно группировать элементы.
Например, в открытой сортировке можно попросить человека объединить карточки так, как ему кажется наиболее логичным, а затем дать названия получившимся группам. Этого часто достаточно.
Не стоит подробно рассказывать, что одна группа должна соответствовать будущему разделу меню, что категорий желательно сделать пять или что «обычно похожие функции располагают вместе». Такие пояснения создают дополнительные правила, которых в реальном восприятии пользователя могло не существовать.
Особенно осторожно я отношусь к примерам. Если перед исследованием показать пример группировки, участник может перенести предложенный принцип на основное задание.
Нам важно увидеть его собственную логику, а не способность повторить продемонстрированный подход.
Не заставляйте пользователя быть последовательным
Во время сортировки человек может сомневаться. Одна карточка кажется подходящей сразу для двух групп, другая — ни для одной. Для исследователя такие моменты особенно интересны.
Иногда команда воспринимает сомнение как проблему прохождения: хочется сделать инструкцию подробнее, переименовать категории прямо во время исследования или добиться от человека однозначного ответа.
Я бы не спешил устранять эту неопределенность.
Если карточка регулярно вызывает сомнения у разных участников, это уже результат. Возможно, функция действительно находится на пересечении нескольких пользовательских задач. Возможно, ее название неоднозначно. Возможно, существующая архитектура пытается провести границу там, где пользователи ее не видят.
Именно поэтому полезно дать участнику возможность отметить затруднение или прокомментировать решение.
Зачем нужны дополнительные вопросы
Количественное распределение показывает, что сделал пользователь, но не всегда объясняет, почему он это сделал.
Предположим, 45% участников отправили карточку «История входов» в «Безопасность», 35% — в «Аккаунт», остальные выбрали другие варианты.
Само распределение говорит о низком согласии. Но причина остается неизвестной.
Один пользователь может считать историю входов инструментом безопасности. Другой воспринимает ее как часть информации об аккаунте. Третий вообще не понимает, что означает название карточки.
Короткий дополнительный вопрос способен дать контекст, которого нет в таблице распределений: «Почему вы выбрали эту категорию?» или «Между какими вариантами вы сомневались?»
Необязательно задавать такой вопрос после каждой карточки. Исследование станет слишком длинным, а участники быстро устанут. Гораздо полезнее определить несколько наиболее важных или потенциально спорных элементов.
Контролируем качество прохождения
При самостоятельном онлайн-исследовании мы не сидим рядом с каждым участником, поэтому стоит обращать внимание на косвенные признаки качества ответов.
Например, подозрение может вызвать прохождение сложной сортировки за нереалистично короткое время. Другой сигнал — механическое распределение всех элементов в одну категорию без очевидного содержательного основания.
Но здесь важно не превращать контроль качества в автоматическое удаление всего необычного.
Если один участник создал совершенно другую структуру, это еще не означает, что он отвечал невнимательно. Возможно, перед нами представитель отдельного пользовательского сегмента или редкая, но логичная модель организации информации.
Поэтому нестандартный ответ сначала нужно изучить и только потом решать, является ли он шумом.
Сколько участников нужно
Это один из самых частых вопросов при планировании Card Sorting, но единственного числа, которое подходило бы для любого исследования, нет.
Необходимая выборка зависит от однородности аудитории, количества карточек, сложности предметной области, типа сортировки и того, насколько устойчивые выводы команда хочет получить.
Я бы не рекомендовал выбирать размер выборки по принципу «в интернете написано, что достаточно N человек». Гораздо полезнее смотреть на стабильность возникающих закономерностей.
Если после серии участников появляются одни и те же группы и новые ответы практически не меняют общую картину, мы получаем признак устойчивости результата. Если же с каждым новым респондентом структура заметно меняется, увеличение выборки само по себе может не решить проблему. Возможно, аудитория неоднородна и ее нужно анализировать по сегментам.
Для продуктового исследования особенно важно заранее определить, насколько точным должно быть решение. Одно дело — предварительно исследовать архитектуру перед созданием прототипа. Другое — принимать на основании результатов решение о перестройке крупного работающего продукта.
Не ищем подтверждение макету
Есть еще одна проблема, которую сложно обнаружить в таблице с результатами: исследователь может бессознательно искать подтверждение уже созданному дизайну.
Допустим, команда несколько недель работала над новой архитектурой в Figma. После Card Sorting часть результатов поддерживает выбранную структуру, а часть ей противоречит.
Очень легко назвать совпадающие результаты «закономерностью», а противоречащие — «шумом».
Поэтому до запуска полезно зафиксировать, какие результаты команда будет считать значимыми и какие альтернативные объяснения готова рассматривать. Это дисциплинирует интерпретацию.
В своей работе я стараюсь отделять исследовательский вопрос от желания доказать правильность конкретного решения. Card Sorting нужен не для того, чтобы подтвердить макет. Его задача — уменьшить неопределенность и показать, где представления команды совпадают с пользовательскими, а где между ними существует разрыв.
Когда данные собраны, начинается наиболее содержательная часть исследования — анализ. Здесь недостаточно посмотреть, какая категория получила больше всего карточек. Нужно увидеть устойчивые связи, конфликтующие группировки и различия между участниками, а затем понять, какие из этих наблюдений действительно должны повлиять на структуру интерфейса.
После завершения Card Sorting мы получаем набор решений отдельных участников. Но сами по себе эти решения еще не являются выводами исследования. Основная работа начинается именно сейчас: нужно определить, какие группировки повторяются, где возникает устойчивое несогласие и чем оно может быть вызвано.
При анализе я стараюсь не начинать с поиска «победившей структуры». Такой подход слишком быстро сводит исследование к голосованию. Гораздо полезнее сначала посмотреть на связи между отдельными карточками, затем на категории и только после этого переходить к возможным изменениям информационной архитектуры.
Ищем устойчивые связи между карточками
Один из самых полезных вопросов при анализе звучит так: какие элементы участники регулярно помещают вместе?
Предположим, мы исследуем функции личного кабинета. Карточки «Добавить сотрудника», «Изменить роль» и «Настроить права доступа» оказались в одной группе у большинства участников. При этом название самой группы могло различаться: «Команда», «Сотрудники», «Управление пользователями», «Права сотрудников».
Для анализа это важный момент. Пользователи не согласились относительно названия, но показали устойчивую смысловую связь между функциями.
Поэтому при открытой сортировке я сначала смотрю именно на совместное появление карточек. Названия категорий анализируются отдельно.
Обратная ситуация тоже информативна. Если две функции, которые команда планировала разместить рядом, практически никогда не объединяются участниками, исходную гипотезу стоит пересмотреть.
Это еще не означает, что элементы обязательно нужно разнести в Figma. Но теперь у нас есть конкретный участок архитектуры, который требует объяснения.
Высокое согласие — самый простой случай
Представим, что 85% участников закрытой сортировки относят «Двухфакторную аутентификацию» к категории «Безопасность». Такое распределение довольно легко интерпретировать: связь между функцией и категорией выглядит устойчивой.
Но даже высокий процент желательно рассматривать в контексте.
Если исследование проходили только опытные пользователи существующего продукта, они могли просто воспроизводить знакомое расположение функции. Если же аналогичный результат получен среди новых пользователей, аргумент в пользу естественности такой структуры становится сильнее.
Поэтому проценты без информации о выборке могут создавать ложное ощущение точности.
Расхождения часто полезнее совпадений
Наиболее интересными для меня обычно становятся карточки, по которым нет очевидного большинства.
Допустим, функция «Экспорт истории операций» распределилась следующим образом: часть участников отправила ее в «Отчеты», часть — в «Историю», часть — в «Настройки данных».
Первая реакция может быть такой: карточка плохая, пользователи не понимают, куда ее относить.
Но именно здесь начинается исследовательская работа.
Нужно посмотреть, что объединяет людей, выбравших каждый вариант. Возможно, пользователи, которые регулярно готовят отчетность, воспринимают экспорт прежде всего как аналитическую функцию. Те, кто использует историю операций для контроля, связывают ее с журналом событий. А администраторы воспринимают экспорт как управление данными.
В таком случае перед нами не шум, а несколько способов осмысления одной функции.
Для дизайнера это особенно важный результат. Возможно, проблема не решается поиском единственного «правильного» раздела. Иногда стоит предусмотреть альтернативные пути к функции или изменить архитектуру так, чтобы пользователь мог найти ее из разных сценариев.
Анализируем названия пользовательских категорий
При открытом Card Sorting участники не только объединяют карточки, но и называют созданные группы. Этот материал полезен для изучения пользовательского языка.
Однако анализировать названия буквально не стоит.
Предположим, один человек создал «Команду», другой — «Сотрудников», третий — «Управление людьми», а четвертый — «Пользователей». Если состав карточек внутри этих групп похож, перед нами, вероятно, одна смысловая категория с разными формулировками.
На этапе анализа такие варианты можно кодировать и объединять в более крупные смысловые темы.
При этом оригинальные формулировки желательно сохранять. Они могут пригодиться позднее при работе над названиями разделов и навигацией.
Особое внимание я обращаю на слишком широкие категории вроде «Другое», «Общее» или «Настройки». Если в них регулярно оказывается большое количество разнородных карточек, это может означать, что участникам трудно сформировать более конкретную модель.
Но причина может находиться и в самом наборе карточек. Поэтому такую категорию нельзя автоматически переносить в интерфейс.
Сегментация меняет интерпретацию
Общий процент способен скрывать закономерности внутри отдельных групп пользователей.
Представим, что половина участников относит определенную функцию к категории A, а половина — к категории B. На уровне всей выборки результат выглядит неопределенным.
После сегментации выясняется, что 80% администраторов выбирают A, а большинство обычных пользователей — B.
Теперь перед нами совершенно другой вывод. Вопрос уже не в том, какая категория получила больше голосов. Мы обнаружили различие между двумя пользовательскими моделями.
Именно поэтому полезно заранее собирать только те характеристики участников, которые связаны с исследовательской задачей: роль, опыт использования продукта, профессиональный уровень или другой действительно значимый признак.
Сегментировать результаты по десяткам параметров без предварительной гипотезы тоже не стоит. Чем больше разрезов мы создаем, тем легче найти случайную закономерность и принять ее за содержательный результат.
Отличаем сигнал от случайного совпадения
Одна из сложностей Card Sorting заключается в том, что визуально почти в любых данных можно найти интересные сочетания.
Например, три участника объединили две неожиданные карточки. Является ли это важным наблюдением?
Ответ зависит от контекста. Если исследование прошли пять человек, три совпадения выглядят существенно. Если участников было сто, картина уже совершенно другая.
Но одной частоты недостаточно. Я смотрю также на содержательную объяснимость связи, ее повторяемость внутри сегментов и комментарии участников.
Сильный исследовательский сигнал обычно складывается сразу из нескольких признаков. Пользователи повторяют определенную группировку, могут объяснить ее похожими причинами, а связь соответствует реальному сценарию взаимодействия с продуктом.
Случайное совпадение чаще остается изолированным наблюдением без понятного объяснения.
Не превращаем проценты в автоматические решения
Предположим, 65% участников относят функцию к разделу «Профиль», а 35% — к «Настройкам».
Можно решить, что «Профиль» победил.
Но для проектирования важнее другой вопрос: что произойдет с теми 35%, которые будут искать функцию в настройках?
Если речь идет о редко используемой возможности, такое расхождение может быть допустимым. Если функция критична для основного сценария, потеря трети пользователей становится гораздо более значимой.
Кроме того, функция может быть доступна из нескольких точек интерфейса. Информационная архитектура цифрового продукта не всегда требует единственного пути к каждому объекту.
Поэтому результат Card Sorting нужно сопоставлять с важностью сценария, частотой использования и последствиями ошибки.
Формулируем наблюдение отдельно от рекомендации
При подготовке результатов исследования я стараюсь явно разделять три уровня: данные, интерпретацию и рекомендацию.
Например:
Такое разделение полезно по двум причинам. Во-первых, команда понимает, где заканчивается непосредственно результат исследования и начинается наша интерпретация. Во-вторых, рекомендация остается гипотезой, которую можно проверить следующим методом.
Это защищает проект от слишком буквального отношения к данным.
Card Sorting не говорит нам: «Нарисуйте меню именно так». Он показывает закономерности в том, как пользователи организуют информацию. А уже на следующем этапе эти закономерности необходимо превратить в новую версию информационной архитектуры и посмотреть, как она работает внутри реального интерфейса.
Именно здесь мы возвращаемся в Figma: не для механического копирования пользовательских групп, а для проектирования структуры, которая учитывает полученные данные и одновременно остается жизнеспособной с точки зрения продукта.
После анализа Card Sorting у команды появляется достаточно много информации: устойчивые группы карточек, спорные элементы, пользовательские названия категорий, различия между сегментами. Следующий шаг кажется очевидным — открыть Figma и перестроить навигацию в соответствии с результатами.
Но именно здесь легко слишком буквально интерпретировать исследование.
Пользователи показывают нам свою логику организации информации, но не проектируют интерфейс. Они не учитывают ограничения экранного пространства, частоту использования функций, права доступа, бизнес-приоритеты и техническую архитектуру продукта. Поэтому результаты сортировки лучше воспринимать как основание для новой версии структуры, а не как готовую схему.
Начинаем не с экранов, а со структуры
Если исследование показало существенные проблемы в информационной архитектуре, я бы не начинал сразу передвигать компоненты в готовых макетах.
Сначала полезно собрать упрощенную структуру продукта: основные разделы, вложенные категории и функции. На этом уровне легче сравнить первоначальную гипотезу с тем, что обнаружилось во время исследования.
Представим, что в исходном варианте личного кабинета существовали разделы «Профиль», «Команда», «Безопасность», «Интеграции» и «Настройки». Card Sorting показал, что управление ролями и доступами пользователи устойчиво связывают с командой, а двухфакторную аутентификацию и историю входов — с безопасностью.
В таком случае сначала меняется сама карта разделов и функций. Только после этого имеет смысл обновлять конкретные экраны.
Так команда не тратит время на детальную переработку интерфейса до того, как согласована новая архитектурная гипотеза.
Что делать с устойчивыми группировками
Наиболее простая ситуация возникает, когда несколько карточек регулярно оказываются вместе у разных участников.
Такая закономерность становится аргументом в пользу того, что пользователи воспринимают функции как части одной задачи или одного смыслового блока.
Но даже здесь я не рекомендую автоматически создавать отдельный раздел.
Допустим, пользователи стабильно объединяют «Смена пароля», «Двухфакторная аутентификация» и «Активные сессии». Смысловая группа «Безопасность» выглядит вполне естественно.
Однако если продукт содержит всего пять настроек аккаунта, создание отдельного крупного раздела может излишне усложнить навигацию. Возможно, достаточно смыслового блока внутри общей страницы настроек.
Таким образом, Card Sorting отвечает на вопрос о связи элементов, а уровень этой связи в интерфейсе определяет уже дизайнер.
Спорные карточки требуют отдельного решения
Особенно внимательно стоит работать с функциями, которые участники постоянно помещали в разные категории.
Представим, что карточку «Уведомления» примерно одинаково часто относили к «Профилю», «Настройкам» и «Коммуникациям».
Можно выбрать наиболее популярный вариант и закончить обсуждение. Но такой подход игнорирует самую важную часть результата: у пользователей нет единого ожидания относительно расположения функции.
В Figma это можно учесть несколькими способами. Например, сделать основной путь через настройки, но предоставить быстрый переход из профиля. Другой вариант — изменить название категории, чтобы ее содержание стало очевиднее. Иногда проблему решает не перенос функции, а изменение контекста вокруг нее.
Для важных сценариев я бы рассматривал несколько вариантов прототипа, а затем проверял, какой из них действительно помогает пользователям быстрее находить нужную возможность.
Пользовательские категории не всегда становятся пунктами меню
В открытом Card Sorting участники могут создать очень удобную для себя классификацию. Например: «То, что использую каждый день», «Настраивается один раз», «Для администратора».
С исследовательской точки зрения это интересный результат. Он показывает принцип, по которому человек осмысляет продукт.
Но буквально переносить такие категории в навигацию не обязательно.
Пользовательская группировка может подсказать другой уровень решения. Если люди объединяют функции по частоте использования, возможно, стоит подумать о быстрых действиях или персонализированном главном экране. Если группировка строится вокруг ролей, возможно, важнее изменить доступность функций для разных типов пользователей.
То есть Card Sorting иногда влияет не на названия разделов, а на более общий принцип организации интерфейса.
Сохраняем связь между данными и изменениями
Когда после исследования в Figma появляется новая версия структуры, полезно фиксировать причину значимых изменений.
Например, команда переносит управление ролями из «Настроек» в «Команду». Через несколько месяцев новый дизайнер может посмотреть на макет и решить вернуть функцию обратно, потому что с его точки зрения так логичнее.
Если исследовательское основание решения нигде не зафиксировано, команда снова возвращается к обсуждению на уровне мнений.
Поэтому рядом с архитектурной схемой можно сохранять короткие пояснения: какая проблема была обнаружена, какие данные ее подтверждают и какое решение команда решила проверить.
Это особенно полезно для крупных продуктов, структура которых развивается годами.
Предположим, мы проектируем сервис для командной работы.
Первоначально команда создала раздел «Настройки», внутри которого разместила управление сотрудниками, роли, уведомления, безопасность, интеграции и параметры аккаунта. Для разработчиков такая структура удобна: все, что связано с конфигурацией продукта, находится в одном месте.
Во время Card Sorting появляется другая картина.
Пользователи устойчиво объединяют сотрудников, роли и права доступа. Интеграции воспринимаются как отдельная область. Пароль, активные сессии и двухфакторная аутентификация образуют еще одну понятную группу. При этом уведомления остаются спорным элементом.
Вместо одного перегруженного раздела команда может подготовить новую архитектурную гипотезу: «Команда и доступы», «Безопасность», «Интеграции» и более компактные общие настройки.
Уведомления пока не получают окончательного места. Для них создаются два варианта расположения, которые будут проверяться на следующем этапе.
Такой результат исследования значительно полезнее попытки заставить все данные сложиться в идеальное дерево.
После изменений исследование не заканчивается
Перенос результатов в Figma — промежуточный этап. Новая архитектура пока существует только как дизайнерская гипотеза, пусть и основанная на пользовательских данных.
Следующий вопрос звучит уже иначе: сможет ли человек найти нужный раздел и выполнить задачу в реальном интерфейсе?
На него Card Sorting не отвечает.
Поэтому после изменения структуры имеет смысл создать прототип и проверить несколько ключевых сценариев. Пользователю можно предложить найти определенную настройку, изменить права сотрудника или подключить интеграцию и посмотреть, какой путь он выберет.
Иногда структура, которая хорошо выглядит по результатам сортировки, сталкивается с проблемами уже на уровне навигации. Например, название категории оказывается недостаточно заметным или пользователь выбирает другой путь из-за контекста конкретной задачи.
Это нормальная часть процесса.
Для меня сильная связка Figma и Card Sorting выглядит не как перенос результатов исследования в дизайн, а как последовательное уменьшение неопределенности. Сначала мы выясняем, как пользователи связывают информацию. Затем превращаем наблюдения в новую архитектурную гипотезу. После этого проверяем уже не абстрактные карточки, а поведение человека внутри прототипа.
Так данные исследования становятся частью проектирования, не подменяя при этом работу дизайнера.
Card Sorting выглядит достаточно простым методом: подготовить карточки, дать пользователям возможность их распределить и посмотреть на результат. Из-за этой простоты исследование иногда запускают без полноценной методологической подготовки. Данные при этом выглядят убедительно — есть проценты, группы и повторяющиеся ответы, — но проблема может быть заложена еще на этапе постановки задачи.
В своей работе я бы выделил несколько ошибок, которые особенно сильно влияют на то, какие выводы команда затем переносит в Figma.
Исследование используется для подтверждения готового решения
Одна из самых неприятных ситуаций возникает, когда команда уже определилась со структурой и фактически хочет получить доказательство ее правильности.
Например, новая навигация полностью собрана в Figma, согласована с продуктом и разработкой. После этого проводится Card Sorting. Если результаты совпадают с макетом, исследование объявляется успешным. Если нет — появляются объяснения, почему участники «неправильно поняли» карточки.
Так исследование теряет смысл.
Полезнее заранее допустить возможность, что первоначальная структура действительно может измениться. Если команда не готова пересматривать решение независимо от результата, стоит сначала понять, зачем вообще проводится Card Sorting.
Карточки содержат правильный ответ
Подсказки часто появляются совершенно незаметно.
Предположим, команда хочет проверить, где пользователи ожидают найти функцию управления API. Карточка называется «API в настройках интеграций». После этого большинство участников отправляет ее в категорию «Интеграции».
Формально мы получили высокий уровень согласия. Фактически название карточки уже сообщило нужную связь.
Подобные подсказки встречаются и в менее очевидной форме. Термин может повторять название одной из категорий или содержать формулировку, которая используется только внутри определенного раздела продукта.
Поэтому перед запуском полезно отдельно перечитать карточки именно с этой позиции: сможет ли участник догадаться о предполагаемом расположении элемента не по его смыслу, а по формулировке?
В одном исследовании смешиваются разные уровни
Эту ошибку особенно легко допустить при переносе структуры непосредственно из Figma.
Например, в набор одновременно попадают «Настройки», «Безопасность», «Сменить пароль» и «Включить двухфакторную аутентификацию». Пользователь видит раздел, подраздел и отдельные действия как равнозначные карточки.
Полученная сортировка может выглядеть логичной, но интерпретировать ее будет сложно. Если участник объединил «Безопасность» со «Сменить пароль», подтвердил ли он предполагаемую архитектуру или просто заметил очевидную смысловую связь между общим и частным?
Чем однороднее уровень элементов, тем понятнее последующий анализ.
Выборка удобная, но нерелевантная
Еще одна распространенная ситуация — привлекать тех участников, которых проще найти.
Для внутреннего теста это могут быть коллеги из соседнего отдела. Для профессионального B2B-продукта — обычные пользователи цифровых сервисов. Для продукта, рассчитанного на новичков, — действующие клиенты, которые несколько лет знают существующую структуру.
Проблема не в том, что эти люди плохо проходят исследование. Они просто могут отвечать на другой вопрос.
Если мы проектируем инструмент для специалистов, профессиональный контекст способен существенно влиять на классификацию. Если проверяем первое знакомство с продуктом, опытные пользователи могут быть слишком хорошо обучены существующей архитектурой.
Поэтому при анализе важно помнить: результаты Card Sorting описывают не «пользователей вообще», а конкретную группу людей, которую мы пригласили в исследование.
Команда смотрит только на большинство
Процентные распределения создают ощущение простого выбора.
Если 68% участников выбрали категорию A, а 32% — категорию B, появляется желание перенести карточку в A и считать вопрос решенным.
Но треть пользователей — это не обязательно незначительное меньшинство. Особенно если функция важна или используется регулярно.
Кроме того, после сегментации может оказаться, что вариант B выбирает определенный тип пользователей. Например, администраторы продукта последовательно ожидают функцию в одном разделе, а обычные сотрудники — в другом.
Поэтому я стараюсь анализировать не только победивший вариант, но и структуру несогласия.
Слишком широкие категории принимаются за удачное решение
Категории вроде «Настройки», «Другое» или «Общее» способны собирать большое количество карточек. На первый взгляд это может выглядеть как сильная группировка.
На практике широкая категория иногда просто становится местом для всего, чему участник не нашел более точного определения.
Если почти половина функций оказывается в «Настройках», это еще не означает, что стоит создать огромный одноименный раздел в продукте. Возможно, наоборот, участники не видят достаточно ясного способа разделить эти функции.
В таких случаях я смотрю не только на название группы, но и на ее внутренний состав. Есть ли внутри несколько устойчивых подгрупп? Какие карточки чаще всего появляются рядом? Можно ли объяснить общий принцип группировки?
Результаты механически копируются в Figma
Даже хорошо проведенный Card Sorting не должен автоматически превращаться в меню.
Пользователь сортирует информацию в искусственно созданной исследовательской ситуации. В реальном интерфейсе он приходит с конкретной задачей, видит визуальную иерархию, использует поиск, переходит по ссылкам и опирается на предыдущий опыт.
Поэтому результат «пользователи объединили эти семь карточек» еще не означает «нужно сделать раздел из семи пунктов».
Иногда вывод будет другим: добавить быстрый переход, изменить терминологию, пересмотреть уровень вложенности или сделать одну функцию доступной из нескольких мест.
Card Sorting дает данные для проектирования, но не выполняет проектирование вместо команды.
Исследование проводится слишком поздно
Если детальные макеты уже готовы, прототип согласован, а разработка началась, архитектурные изменения становятся дорогими.
В такой ситуации команда невольно становится менее восприимчивой к результатам исследования. Даже обнаружив проблему, проще объяснить ее как незначительную, чем перестраивать десятки экранов.
Поэтому Card Sorting особенно полезен до глубокой детализации интерфейса. В Figma к этому моменту может существовать карта продукта, предварительная навигация и несколько ключевых экранов, но архитектура еще должна оставаться изменяемой.
Чем дешевле команде изменить гипотезу, тем больше практической ценности можно извлечь из исследования.
Один метод пытаются использовать вместо всей UX-проверки
Последняя ошибка связана с завышенными ожиданиями от Card Sorting.
Если участники логично распределили функции по категориям, это не доказывает, что интерфейс будет удобным. Пользователь может понимать смысловую структуру и одновременно не замечать нужный раздел в навигации.
Поэтому после Card Sorting работа не заканчивается.
Новая структура возвращается в Figma, превращается в прототип и проверяется уже в контексте конкретных пользовательских задач. На этом этапе команда может обнаружить проблемы, которых карточная сортировка в принципе не способна показать.
Я рассматриваю Card Sorting как специализированный инструмент. Он особенно хорошо отвечает на вопросы о группировке и восприятии информации. Чем точнее мы понимаем границы метода, тем меньше риск сделать из хороших данных слишком широкие выводы.
Именно поэтому финальный рабочий процесс должен объединять исследование структуры, анализ, проектирование в Figma и последующую проверку прототипа — вместо попытки найти один метод, который сразу даст команде окончательный вариант интерфейса.
Связка Figma и Card Sorting приносит наибольшую пользу не тогда, когда исследование проводится один раз ради подтверждения структуры, а когда становится частью последовательного проектирования. Команда сначала формулирует гипотезу, затем проверяет пользовательскую логику, корректирует информационную архитектуру и только после этого переходит к более дорогой детализации интерфейса.
Для меня ценность такого подхода заключается прежде всего в том, что он помогает разделить два вопроса: как команда представляет структуру продукта и как эту же информацию организуют пользователи. Чем раньше мы обнаружим различия между этими моделями, тем проще будет с ними работать.
От гипотезы к структуре
Работа начинается еще до полноценного прототипа.
У команды есть набор функций, контента или категорий, которые необходимо организовать. На этом этапе в Figma уже может существовать предварительная карта продукта, навигация или несколько вариантов информационной архитектуры.
Важно воспринимать эту структуру как гипотезу.
Если дизайнеру кажется очевидным, что управление сотрудниками должно находиться в «Настройках», это рабочее предположение, а не установленный факт. Card Sorting позволяет проверить, воспринимают ли пользователи эту функцию похожим образом и с какими другими элементами они ее связывают.
Так исследование проводится в момент, когда изменение структуры еще не требует переделки десятков готовых экранов.
От сортировки к данным
Следующий этап — само исследование. Здесь качество результата определяется тем, насколько корректно сформулирована задача, подобраны карточки и участники.
После сбора ответов мы ищем не идеальную структуру, а закономерности. Какие карточки стабильно оказываются вместе? Какие категории участники понимают одинаково? Где возникают устойчивые расхождения? Отличаются ли результаты разных сегментов?
Особенно полезными могут оказаться именно спорные области.
Если десять функций распределяются практически одинаково, а две постоянно перемещаются между разными группами, дальнейшего внимания требуют прежде всего эти две. Они указывают на участок архитектуры, где пользовательские ожидания наиболее неоднозначны.
От данных к новой архитектурной гипотезе
После анализа команда возвращается в Figma.
На этом этапе я считаю важным не переносить результаты буквально. Вместо этого для каждого значимого наблюдения стоит задать вопрос: какое изменение интерфейса может решить обнаруженную проблему?
Допустим, пользователи постоянно ищут определенную функцию в двух разных смысловых областях. Решением необязательно будет выбор одной из них. Можно изменить название раздела, предусмотреть дополнительный путь, вынести функцию на более высокий уровень или пересмотреть сам принцип группировки.
Если исследование показало несколько возможных решений, полезно сохранить несколько вариантов архитектуры и проверить их дальше.
Именно здесь особенно хорошо видно различие между исследованием и дизайном. Исследование показывает проблему и дает основания для гипотез. Дизайн превращает эти гипотезы в работающие варианты интерфейса.
От архитектуры к прототипу
После корректировки структуры можно переходить к интерактивному прототипу.
Теперь мы проверяем уже другой вопрос. Не «как человек сгруппировал бы эти функции?», а «сможет ли он найти нужную функцию, когда решает реальную задачу?»
Предположим, после Card Sorting управление правами доступа было перенесено в раздел «Команда». В прототипе участнику можно предложить добавить нового сотрудника и ограничить его возможности.
Если человек без затруднений находит нужный путь, архитектурная гипотеза получает дополнительное подтверждение. Если он начинает искать права доступа в безопасности или общих настройках, нам становится понятнее, где именно возникает проблема.
При этом не стоит ожидать, что Card Sorting и последующее тестирование всегда дадут одинаковую картину. В сортировке человек работает с абстрактными объектами, а в прототипе действует внутри конкретного сценария. Контекст способен менять его ожидания.
И это не противоречие между исследованиями, а дополнительная информация.
Когда Card Sorting особенно полезен
Я бы в первую очередь рассматривал этот метод для продуктов, где пользователю приходится ориентироваться среди большого количества информации или функций.
Это могут быть интернет-магазины с развитым каталогом, SaaS-сервисы, личные кабинеты, корпоративные системы, базы знаний, образовательные платформы и приложения с большим количеством настроек.
Чем больше существует правдоподобных способов организовать одни и те же элементы, тем полезнее проверить пользовательские представления до фиксации архитектуры.
Если структура продукта очень простая, проведение отдельного Card Sorting может быть избыточным. Метод стоит выбирать не потому, что он доступен, а потому, что он отвечает на конкретный исследовательский вопрос.
Card Sorting до или после создания макета
Наиболее удобный момент зависит от задачи.
Если продукт создается с нуля и команда еще не определилась с информационной архитектурой, открытый Card Sorting можно провести до детальной работы над интерфейсом. В Figma к этому моменту достаточно иметь общую модель продукта и набор объектов, которые необходимо организовать.
Если структура уже существует и нужно проверить конкретное распределение функций, исследование можно проводить позже. Тогда исходный макет помогает определить спорные участки и подготовить закрытую или гибридную сортировку.
Главное — оставить пространство для изменений. Исследование, результаты которого уже невозможно применить из-за стадии разработки, приносит значительно меньше практической пользы.
Данные не заменяют дизайнерское решение
После нескольких исследований у команды может появиться желание проектировать интерфейс исключительно на основании большинства ответов. Но пользовательские данные не снимают необходимость принимать продуктовые и дизайнерские решения.
Пользователь не знает всех ограничений системы. Он не обязан учитывать бизнес-модель, техническую реализацию, права доступа или будущие функции продукта.
Задача исследователя — показать, как люди воспринимают структуру и где возникают проблемы. Задача команды — использовать эту информацию вместе с другими ограничениями.
Поэтому я бы описал весь процесс одной последовательностью:
Эта последовательность не обязательно заканчивается после одного цикла. Иногда тестирование прототипа обнаруживает новую проблему, после чего часть структуры приходится пересматривать снова.
И в этом нет ничего неправильного. Цель исследования не в том, чтобы с первого раза получить идеальное меню, а в том, чтобы принимать каждое следующее решение с меньшей неопределенностью.
Работая с исследованиями и анализируя результаты опросов, я чаще всего вижу пользу Card Sorting именно в этом. Метод переводит обсуждение структуры из области исключительно внутренних мнений команды в область наблюдаемых пользовательских данных.
Figma после этого остается пространством, где команда принимает окончательные решения. Но теперь за расположением раздела, изменением категории или переносом функции может стоять не только аргумент «так выглядит логичнее», а понимание того, как эту информацию воспринимают реальные пользователи.
В итоге Figma и Card Sorting хорошо дополняют друг друга именно на разных уровнях работы. Первый инструмент помогает проектировать и быстро менять интерфейс, второй — проверять одну из его фундаментальных основ: соответствует ли организация информации ожиданиям аудитории. А последовательное использование обоих подходов позволяет обнаруживать архитектурные проблемы до того, как они становятся дорогими проблемами готового продукта.