Личный кабинет для клиентов: семь решений до начала разработки

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

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

1. Назовите повторяющуюся задачу клиента

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

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

2. Разделите пользователей и их права

«Клиент» редко означает одного человека. Заказчик может приглашать коллегу, руководитель — только смотреть итог, а сотрудник вашей компании — отвечать на запросы. Составьте матрицу: роль → какие записи видит → что может создать, изменить, скачать и подтвердить. Отдельно решите, что произойдёт, когда сотрудник сменит компанию или представитель клиента потеряет доступ.

Это не косметическая настройка меню. Скрытая кнопка сама по себе не защищает данные: ограничение должно действовать для каждого запроса к записи и файлу. OWASP рекомендует принцип минимально необходимых прав, запрет доступа по умолчанию и проверку разрешений на каждом запросе. В брифе поэтому нужны и положительные, и отрицательные сценарии: «менеджер компании А видит свою заявку» и «не может открыть заявку компании Б по прямой ссылке».

3. Опишите состояния заявки и источник правды

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

Решите, где находится исходная запись: в существующей CRM, внутренней системе или самом кабинете. Кто меняет статус и как он попадает на экран клиента? Если обмен с CRM ещё не согласован, не пишите в требованиях «двусторонняя синхронизация» как будто она уже существует. Опишите минимальный ручной маршрут и отдельно оцените интеграцию. Это сохранит честную границу первой версии.

4. Определите правила для документов и данных

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

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

5. Продумайте вход и восстановление доступа

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

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

6. Покажите результат каждого действия

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

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

7. Зафиксируйте границу первой версии и приёмку

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

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

Короткий бриф, с которого можно начать

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

House of Jarvis разрабатывает корпоративные платформы и личные кабинеты под согласованную задачу. Если планируешь такой проект, напиши Сергею Смирнову, какое действие клиент сегодня выполняет через почту или мессенджер и кто отвечает за его результат. Состав, сроки и стоимость разработки обсуждаются отдельно. MetaJarvis CRM — отдельный продукт: бесплатно только базовое внедрение; подписка, интеграции и дальнейшее сопровождение обсуждаются отдельно. CRM можно открыть в Telegram.