Аудит портала на основе реальных задач сотрудников начинается не с перечня страниц. Важнее понять, может ли человек оформить доступ, найти действующее правило, согласовать расход, сообщить об инциденте или изменить свои данные. Даже аккуратная страница бесполезна, если после неё требуется неизвестная форма, ручное письмо или звонок нужному человеку.
Единицей проверки становится законченная рабочая задача. У неё есть причина, исполнитель, ожидаемый итог, ограничения доступа, передача между системами и признак завершения. Такой подход показывает проблемы, которые не видны в проверке меню, цветов и количества кликов.
Соберите карту задач из фактического спроса
Источниками служат обращения в поддержку, поисковые запросы, заявки, журналы сервисов, интервью и наблюдение за работой. Для каждого сценария укажите роль сотрудника, срочность, частоту, последствия ошибки, необходимые документы и систему, где должен появиться результат. Отдельно отметьте неофициальный путь, если люди обходят портал.
Не ранжируйте задачи только по частоте. Редкое сообщение об утечке или производственном риске может быть важнее ежедневного просмотра новости. Приоритет зависит от ущерба, времени реакции, числа участников и невозможности безопасно продолжить работу.
Кейс редизайна медицинского информационного портала показывает один конкретный контекст проектирования. Его нельзя использовать как доказательство проблем или результата другой организации без отдельного исследования.
Наблюдайте весь путь сотрудника
Дайте участнику правдоподобную задачу без подсказки правильного раздела. Зафиксируйте, где он начинает, какими словами ищет, что переносит вручную, у кого просит помощь и по какому признаку считает работу законченной. Если после отправки формы человек пишет коллеге для проверки, официальный процесс не дал достаточной уверенности.
Разделяйте наблюдение и вывод. Сначала запишите действие, сообщение системы, остановку, обход и итог. Затем определяйте возможную причину: непонятный термин, устаревший источник, отсутствие права, недоступная интеграция, лишнее согласование или потерянный статус.
Сохраняйте контекст задачи, а не запись всего рабочего дня. Достаточно времени, роли, устройства, исходных материалов и тех шагов, которые относятся к сценарию. Персональные данные и содержимое внутренних документов не должны попадать в отчёт без необходимости и согласованного режима доступа.
В исследовании нужны разные роли, опыт, устройства и особенности доступа. Сотрудник, который много лет знает внутренние сокращения, не заменяет нового пользователя. Руководитель с расширенными правами не показывает путь специалиста, которому сначала нужно получить разрешение.
Проверяйте также задачи, которые начинаются вне портала. Ссылка из письма может вести на закрытую страницу, чат-бот давать устаревший адрес, а поисковая система открывать старую копию инструкции. Аудит должен учитывать реальную точку входа, даже если владельцу портала удобнее начинать с главной страницы.
Разбор о том, почему корпоративные порталы не взлетают, помогает сформулировать организационные гипотезы. В аудите их всё равно следует проверять на текущих сотрудниках и источниках.
Превратите наблюдения в очередь решений
Объедините находки по причинам, а не по экранам. Один отсутствующий владелец способен породить несколько дублирующих страниц, неактуальную инструкцию и бесконечное согласование. Исправление структуры меню не решит этот узел.
Для приоритетных задач задайте тест приёмки. Названная группа сотрудников должна получить правильный результат в целевой системе, без запрещённого обхода и с понятным подтверждением. Время, ошибки, помощь, восстановление и успешность передачи измеряйте отдельно, чтобы средняя оценка не скрывала проблему.
Добавьте отрицательные сценарии: документ отсутствует, право отозвано, заявка отклонена, интеграция недоступна или срок истёк. Хороший портал не только проводит по счастливому пути, но и объясняет причину, сохраняет допустимую работу и показывает, кто способен решить исключение.
Назначьте владельца каждого изменения. Контент-команда исправляет формулировку и источник. Команда доступа меняет права. Владелец процесса сокращает согласования. Интеграционная команда обеспечивает передачу данных. Портал не должен становиться местом, куда складывают чужие нерешённые обязанности.
Статья об архитектурном хребте портала полезна для обсуждения общего состояния и системных границ. Конкретный проект требует собственной карты задач и технической проверки.
После изменений повторите те же задания с сопоставимой группой. Новая навигация не считается улучшением, пока сотрудники не завершают работу устойчивее и не создают новые обходы в соседних каналах.
Частые вопросы
Проверяйте сквозные задачи сотрудников от причины обращения до правильной записи, передачи или подтверждённого результата.
Используйте обращения, поисковые запросы, заявки, журналы сервисов, интервью и наблюдение за фактической работой.
Сначала фиксируйте действие и результат сотрудника, а возможную причину препятствия формулируйте отдельным полем.
Нужны карта задач, реестр корневых причин, владельцы изменений и тесты приёмки для приоритетных сценариев.
Если организации нужны сценарии исследования, карта препятствий и проверяемый план изменений, UI/UX-дизайн может связать наблюдения сотрудников с решениями интерфейса и сервиса. Эффект редизайна подтверждают только повторные измерения после внедрения.
