Онбординг пользователей: путь к первому результату

Онбординг пользователей в SaaS и приложениях: первый результат, пустые экраны, роли и подсказки. Как проверить активацию и убрать лишние шаги.

Автор: Виктория Сидорова, Product Designer, 404gen.

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

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

Покажите результат, ради которого человек вообще пришёл

Начните с одного предложения: новый пользователь сможет сделать что? Для сервиса выездных сотрудников — увидеть назначение и отправить отчёт. Для системы подготовки предложений — собрать пригодный документ. Для клиентского кабинета — найти свой заказ и нужные сведения. Ответ «познакомиться с возможностями платформы» слишком удобен команде и слишком мало говорит о пользе для покупателя. Знакомство не является работой, за которую обычно готовы платить.

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

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

На этапе разработки SaaS и веб-приложения такой сценарий полезно зафиксировать до списка модулей. Он определяет зависимые поля, права и состояния, которые действительно нужны первой версии. Тогда онбординг становится частью продукта, а не набором стрелочек, нарисованным после завершения всего остального. И команда получает ясный критерий: можно ли новым пользователем выполнить обещанную работу.

Экскурсия по меню может отлично объяснять лишнее

Подсказка помогает, когда она относится к действию, которое человек собирается выполнить. В разборе Nielsen Norman Group сравниваются вводные экскурсии и помощь в контексте: обзор до начала работы может прервать задачу и потребовать запомнить объяснение заранее. Это не запрет на обучение. Это повод выбирать момент и формат исходя из реального действия, а не из желания показать все новинки сразу.

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

Есть продукты, где подготовка обязательна: сложное оборудование, необычные операции, высокие последствия ошибки. Там обучение нельзя просто выкинуть ради короткой воронки. Но и здесь стоит связать материал с действием: выполнить тренировочный шаг, получить обратную связь, увидеть ограничения. Нажатие «Я ознакомился» фиксирует нажатие. Проверяемое выполнение показывает хотя бы часть понимания. Эти доказательства отличаются независимо от красоты иллюстраций.

Посмотрите на свой тур глазами пользователя, который уже знает похожие инструменты. Нужно ли заставлять его читать, что шестерёнка означает настройки? Может ли он пропустить обучение и найти его позже? Не закрывает ли подсказка нужную кнопку? Экскурсия бывает полезной, когда снижает неопределённость. Если она становится платой за вход в продукт, человек вполне может отказаться от посещения этого музея.

У разных ролей разное первое утро

Разделяйте того, кто покупает систему, того, кто её настраивает, и того, кто выполняет ежедневную работу. Администратор подключает источники и сотрудников. Исполнитель принимает задачу. Руководитель смотрит состояние команды. Одна приветственная форма для этих людей либо просит ненужные сведения, либо не даёт нужного маршрута. Выбор роли должен менять порядок действий, а не только аватар в углу.

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

У руководителя может не быть данных для настройки, а у оператора — полномочий. В таком случае первая полезная операция связана с передачей запроса нужному человеку. Например, запросить подключение справочника у администратора и сохранить статус ожидания. Экран «Нет доступа» с единственной кнопкой назад не даёт продолжения. Ответственность за следующий шаг должна быть понятна без устного знакомства со всей организационной структурой.

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

Просите сведения тогда, когда они меняют действие

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

Отделите обязательное от рекомендуемого и объясните последствия пропуска. «Добавьте телефон, чтобы получать сообщения о статусе» яснее, чем красная звёздочка возле неизвестного поля. При этом нельзя обещать канал, который в конкретной реализации не подключён. Поле должно иметь реального потребителя в системе и понятный сценарий использования. Собранное «на будущее» превращается в лишнюю ответственность за хранение и актуальность.

Не заставляйте сотрудника восстанавливать данные компании из памяти, если они уже есть в приглашении или подготовленном справочнике. Предзаполнение полезно, когда можно проверить источник и исправить значение. Автоматически угаданная должность или отрасль не должна выглядеть как подтверждённый факт. Онбординг выигрывает от помощи, но проигрывает от тихой подмены пользовательского решения предположением системы.

Проверяйте сохранение частично введённых данных. Если человек вышел уточнить реквизиты, его возвращение не должно начинаться с пустой формы. Покажите, что осталось незавершённым, и восстановите нужный шаг. Большой прогресс-бар без сохранённого результата изображает заботу примерно так же, как табличка «Мы ценим ваше время» возле третьей одинаковой анкеты.

Пустой экран должен предлагать начало работы

Когда данных ещё нет, это нормальное состояние, а не повод показать техническое отсутствие списка. В рекомендациях NN/G о пустых состояниях рассматривается помощь в понимании состояния и переходе к действию. Для вашего продукта это означает: объяснить, почему здесь пусто, что появится после первого шага и какое действие доступно текущей роли.

Сравним условные варианты. «Записей не найдено» просто сообщает факт. «Здесь будут заявки клиентов. Добавьте первую вручную или подключите согласованный источник» связывает пустоту с будущей работой. Если импорт доступен только администратору, обычному пользователю следует предложить запросить подключение. Пустой экран должен читать контекст, а не отправлять всех на одну кнопку без проверки полномочий.

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

Образец может ускорить понимание, если его можно безопасно открыть, изучить и удалить. Важно обозначить демонстрационные данные и не смешивать их с боевыми отчётами. После перехода к реальной работе система должна помочь убрать учебные записи. Иначе через месяц кто-то будет обсуждать, почему в управленческой сводке всё ещё значится загадочный клиент «Пример компании» с идеальной конверсией.

Первый результат иногда зависит от другого человека

Сложный SaaS редко работает в вакууме. Может понадобиться справочник, проверка договора, подключение сервиса или решение администратора. Это не повод скрывать задержку под вечным «Подготовка пространства». Покажите конкретное условие, ответственного и доступный следующий шаг. Пользователь должен отличать ожидание согласования от ошибки системы и от собственного незавершённого действия.

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

Передача между людьми нуждается в уведомлении и состоянии. Кто получил запрос, где его обработать, что произойдёт после выполнения? Нажатие «Запросить доступ» без записи в очереди ничего не передаёт. Для приёмки найдите запрос в системе ответственного, выполните его и проверьте, что стартовый экран пользователя изменился. Такой тест полезнее визуального ревью конверта, который красиво улетает в анимации.

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

Контекстная помощь отвечает на текущий вопрос

Помощь должна возникать там, где появляется неопределённость. Возле выбора формата, объяснения роли, первой сложной операции. В материале NN/G о progressive disclosure описывается постепенное раскрытие деталей: основные возможности доступны сразу, дополнительная сложность открывается по потребности. Принцип полезен для проектирования, но не отменяет проверку обязательных сведений и доступности управления.

Разведите короткую подсказку, пример и подробную документацию. Короткая фраза объясняет смысл поля. Пример показывает пригодный ввод. Инструкция раскрывает исключения и ограничения. Если все уровни открыть одновременно, экран превратится в техническое руководство с кнопкой где-то в конце. Если оставить только короткий текст, сложный пользователь может не найти ответа. Возможность углубиться помогает обеим группам.

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

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

Импорт данных — отдельная рабочая сцена

Если продукт получает ценность после загрузки данных, импорт становится центральной частью старта. Человек должен знать допустимый формат, объём и обязательные поля до выбора файла. После отправки полезен предварительный просмотр: что распознано, сколько строк подходит, какие значения требуют исправления. Большая кнопка «Импортировать» не снимает ответственности за содержимое, которое она собирается внести.

Разделите чтение файла и применение изменений. Сначала можно проверить соответствие, затем показать последствия и получить подтверждение. Особенно если записи заменяют существующие данные. При повторной попытке система должна понимать, создаются ли дубли или обновляется тот же набор. Стартовый сценарий выигрывает, когда он позволяет учиться на небольшом объёме и исправлять ошибки без уборки всего пространства вручную.

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

На приёмке возьмите неправильный заголовок столбца, пустое обязательное значение, повторную строку и прерванную отправку. Проверьте, остаётся ли у пользователя результат разбора и понятный путь исправления. Если первая ценность зависит от идеального файла, который умеет делать только ваш аналитик, массовый онбординг пока называется «внедрение при личном присутствии аналитика». Это тоже модель, но её нужно честно учитывать.

Запрос разрешения нуждается в объяснении

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

Объяснение должно совпадать с действием. «Для фотографии результата откройте камеру» отличается от «Разрешите доступ для лучшего опыта». Покажите, что возможно без разрешения и как вернуться к настройке. Конкретные системные окна и права зависят от платформы; в веб-продукте и мобильном приложении маршрут может различаться. Их необходимо проверять в поддерживаемых средах, а не изображать одним универсальным макетом.

Отказ — нормальное состояние. Если он делает основную задачу невозможной, объясните это и предложите допустимое продолжение. Если функция второстепенная, продукт не должен блокировать всю работу. Запрос, который повторяется после каждого отказа, становится давлением вместо помощи. А фраза «Осталось включить уведомления» ошибочна, если человек уже достиг результата и сознательно выбрал другой канал связи.

Сначала определите политику продукта, затем тексты. Что обязательно, что добровольно, где лежат настройки, кто может менять доступ для организации? Онбординг не должен своими обещаниями расширять полномочия системы. Согласованная модель поведения уменьшает вопросы и облегчает поддержку, потому что объяснения в документации, интерфейсе и ответе сотрудника перестают противоречить друг другу.

Считайте выполненную работу, а не просмотренные карточки

Метрика активации должна быть связана с первым результатом. Регистрация показывает возможность войти. Окончание тура показывает действие с обучением. Заполнение профиля показывает ввод данных. Ни одно из этих событий автоматически не подтверждает пользу. Для каждой роли сформулируйте наблюдаемую операцию и условия корректности: что создано, кому доступно и какой следующий этап стал возможен.

В условном примере из 100 новых пользователей 80 закрыли вводные подсказки, 30 создали черновик, а 12 подготовили пригодный результат. Если активацией назвать просмотр тура, показатель будет прекрасным. Если целью была подготовка документа, реальность заметно скромнее. Эти числа иллюстрируют различие определений и не являются данными проекта 404gen или обещанием типичной конверсии.

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

Следите за знаменателем. Кто действительно мог пройти сценарий: приглашённый исполнитель, администратор без источника данных, посетитель демонстрации? Смешанная аудитория легко создаёт ложные сравнения. Сопоставляйте одинаковые роли, каналы и версии продукта, учитывайте окно наблюдения. И не объявляйте причинный эффект после небольшого изменения, если одновременно поменялись реклама, условия доступа и состав пользователей.

Первый успех и привычка пользоваться — разные задачи

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

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

Напоминание стоит связывать с конкретным незавершённым этапом. «Администратор подключил источник, теперь можно проверить данные» несёт смысл. «Мы скучаем» выражает настроение приложения, но не объясняет задачу. Каналы и частота согласуются с правилами продукта и выбором человека. Проверьте остановку сообщений после завершения: иначе успешный пользователь продолжит получать призывы начать заново.

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

Тест без экскурсовода: что делать с молчанием пользователя

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

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

Записывайте препятствия по этапам. Цель не понята, обязательные сведения недоступны, действие недоступно роли, результат не узнаваем, помощь не найдена. Такой разбор превращается в план исправлений. «Пользователь тупит» ни в какой план не превращается, кроме плана не приглашать пользователей больше. Особенно полезны повторяющиеся затруднения, которые возникают в разных ролях по одной системной причине.

После изменения проверяйте именно исправленный сценарий и соседние переходы. Удалили поле — не потерялся ли необходимый контекст? Перенесли запрос доступа — может ли человек вернуться к нему? Упростили пустой экран — понятен ли результат импорта? Новая версия не обязана становиться короче любой ценой. Она должна делать путь яснее и сохранять корректность работы.

Поддержка может съесть всю лёгкость регистрации

Считайте нагрузку на сопровождение вместе с самостоятельным результатом. Представим условные 40 новых организаций. Для каждой требуется 20 минут объяснения, куда загрузить данные: это 800 минут работы. Если инструкция в контексте сокращает помощь до 10 минут у тех же 40 организаций, расход становится 400 минут. Это расчёт времени, а не оценка зарплаты или обещание экономии — фактическое распределение обращений нужно измерить.

Добавьте исправление ошибочных данных, повторные обращения и ручную настройку. Лёгкая регистрация, после которой сотрудники несколько дней собирают нужную информацию в чатах, не является дешёвым стартом. Работа просто переехала с экрана в операционный отдел. Иногда такой подход оправдан для сложных внедрений, но его стоимость и ответственность должны быть видимы в модели продукта.

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

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

Что положить в бриф первого сценария

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

Отдельно составьте набор состояний. Первый вход, возвращение к черновику, ожидание администратора, отсутствие данных, ошибка подключения, завершение и отказ. Не все нужно показывать последовательно, но каждое должно иметь понятное продолжение. Условия переходов важнее номера шага на прогресс-баре. Продукт может ожидать внешнего события, и интерфейс обязан объяснять это, а не изображать вечный недостаток усердия пользователя.

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

Критерии приёмки напишите до разработки: человек понимает цель, может получить необходимые данные, выполняет разрешённое действие, видит пригодный результат, возвращается к нему и знает дальнейший шаг. Укажите поддерживаемые устройства и события измерения. Тогда дизайн, разработка и продажи будут обсуждать одну договорённость. Вместо ситуации, где каждый показывает свой успешный экран, а клиент по-прежнему не начал работу.

Завтра утром: попробуйте стать незнакомым пользователем

Создайте чистую учётную запись с обычной ролью. Пройдите реальную задачу, не пользуясь административными правами и знаниями разработчика. Сохраните места, где приходится догадываться или ждать помощи. Затем попросите коллегу из другой функции пройти тот же сценарий. Это не заменит исследование аудитории, но быстро покажет разницу между вашим знанием системы и тем, что система действительно объясняет.

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

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

Хороший онбординг не обязан развлекать человека каждым переходом. Он помогает быстро понять пользу, выполнить задачу и вернуться к результату. Можно добавить характер, движение и приятные детали — если они поддерживают этот путь. Но главный комплимент вашему первому экрану звучит довольно буднично: «Я понял, что делать, и у меня получилось». Для коммерческого продукта это обычно дороже восторга от приветственного слайда.

Частые вопросы

Что считается результатом онбординга?

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

Нужно ли убирать вводный тур из приложения?

Решение зависит от сложности задачи. Тур может быть уместен для непривычной операции или безопасной тренировки. Для обычного действия часто полезнее помощь рядом с текущим шагом. Важно дать возможность закрыть объяснение, найти его позже и проверить, действительно ли формат помогает выполнить работу.

Как измерить улучшение онбординга?

Сравнивать достижение первого результата, время, исправления и объём помощи на сопоставимых ролях и аудиториях. Учитывать зависимости от администраторов и источников данных. Завершение тура не заменяет активацию, а активация не доказывает последующее удержание. Эффект версии проверяется по реальному сценарию, а не по условным числам статьи.

Почему пользователь не активируется после регистрации?

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