ТЗ на личный кабинет: роли, данные и проверяемые сценарии

Личный кабинет — сервис, а не набор вкладок

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

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

Что часто забывают в задании

Обычно проект ломается не на внешнем виде профиля, а на границах данных и прав.

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

Проверьте потребность и карту ролей

Самая дорогая ошибка — проектировать один экран для пользователей с разными правами и ожиданиями.

• Соберите обращения в поддержку, письма и операции, которые клиент повторяет. Разделите их на чтение статуса, изменение данных, запрос документа и действие с финансовыми последствиями. Для каждого сценария запишите частоту, цену ошибки и текущий обходной путь; не добавляйте экран только потому, что он привычен в чужом кабинете.
• Опишите роли: частный клиент, представитель компании, администратор организации, сотрудник поддержки и системный интегратор. Для каждой сущности — заказ, договор, документ, обращение — укажите, кто может видеть, менять, удалять и выгружать. Проверьте ситуацию, когда один человек состоит в нескольких организациях или меняет роль.
• Назначьте источник истины для профиля, статуса, задолженности, документов и уведомлений. Покажите, как быстро изменение из CRM или учётной системы появляется клиенту. Если статус требует ручного подтверждения, не показывайте его как гарантированно окончательный. Разделите системную задержку и ошибку синхронизации.
• Опишите вход и восстановление доступа с учётом реального риска: email, телефон, одноразовая ссылка, корпоративный SSO или иной механизм. Укажите, как пользователь теряет доступ, закрывает сессию, меняет контакт и сообщает о чужом доступе. Решение по аутентификации принимайте вместе с ответственным за безопасность, а не по удобству макета.
• Определите юридические и операционные границы: срок хранения данных, выгрузка документов, согласие на уведомления, право представителя компании, действия после увольнения сотрудника. Персональные данные и договорные формулировки должны согласовать уполномоченные специалисты; не переносите их из случайного шаблона.

Пример матрицы доступа и тестового сценария

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

• Строка матрицы: «Документ по заказу A организации X». Частный клиент, не связанный с X, не видит документ; представитель X видит его только после подтверждения полномочия; сотрудник поддержки получает доступ по рабочей роли и оставляет запись аудита. Укажите, что происходит при смене организации и отзыве приглашения.
• Приёмочный тест: создайте две организации и двух представителей; выложите документ в первую организацию и попытайтесь открыть его под второй, в том числе по скопированному URL. Затем отзовите право первого представителя и повторите попытку без обновления вкладки. Проверяйте ответ сервера, а не только исчезновение кнопки.
• Для каждого события опишите источник, время обновления, идентификатор, состояния ошибки и владельца инцидента. Если CRM недоступна, кабинет должен либо показать последнее подтверждённое состояние с отметкой времени, либо явно сказать, что данные сейчас не получены. Выбор зависит от риска, но он должен быть зафиксирован заранее.
• Отдельно принимайте доступность: клавиатурное управление, корректные подписи форм, фокус после диалога, понятные ошибки и работу на мобильном экране. WCAG 2.2 даёт проверяемые критерии, но итог проверяйте реальным путём пользователя: вход — поиск операции — действие — подтверждение.

Как описывать функции кабинета в ТЗ

Для каждого раздела укажите роль, исходное состояние, действие, ожидаемый результат и исключения.

• Вход и первое использование. Опишите приглашение, подтверждение владения контактом, смену организации и завершение сессии. Проверьте неверную и просроченную ссылку, повторное приглашение и попытку войти после отзыва прав. Сообщения не должны раскрывать существование чужого аккаунта сверх необходимого.
• Главная кабинета. Показывайте ближайшее полезное действие, подтверждённый статус и дату обновления данных. Если по заказу ещё нет ответа внешней системы, обозначьте ожидание и способ связи. Не маскируйте неизвестный статус декоративной «зелёной галочкой»; пользователь примет её за обещание исполнения.
• История операций. Опишите состав списка, фильтр, пагинацию и карточку одной операции. Названия и даты должны совпадать с теми, которые использует поддержка, иначе клиент не сможет назвать конкретный случай. При отмене, возврате или споре сохраняйте историю состояния, а не только последнюю строку.
• Документы и файлы. Укажите, кто создаёт документ, когда он становится доступен, может ли истечь ссылка и кто видит старую версию. Для файлов с персональными или коммерческими данными проверьте прямой URL после выхода и после смены прав. Наличие кнопки «скачать» не означает, что доступ ограничен корректно.
• Обращения и изменения. Если клиент редактирует реквизиты, адрес или время записи, опишите момент вступления изменения в силу и подтверждение ответственного. В обращении сохраняйте контекст объекта и ответ, чтобы поддержка не просила заново назвать номер заказа. Дайте понятный маршрут, если операция недоступна онлайн.
• Уведомления. Разделите сервисные сообщения, маркетинг и критические предупреждения. Для каждого события запишите канал, отправителя, условия повтора и текст следующего действия. Пользователь должен понимать, какие уведомления может отключить и где проверить статус без ожидания письма.
• Админские функции и аудит. Сотрудник поддержки должен видеть достаточный контекст, но не получать автоматически все данные клиента. Зафиксируйте принцип минимально необходимого доступа, журнал просмотра и изменения важной информации, процесс выдачи временной роли и её отзыв после задачи.

Как оценивать требования и пользу

Цель — не число зарегистрированных аккаунтов, а сокращение повторных вопросов при сохранении контроля и безопасности.

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

Что передать команде реализации

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

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

Проверка доступа после смены роли

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

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

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

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

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