Пользователь уже оставил заявку. Через несколько дней он возвращается на сайт: хочет понять, что происходит, ответить на вопрос специалиста и найти документ. Если ради этого приходится снова звонить и пересказывать ситуацию, страница с именем и кнопкой выхода ещё не решает его задачу.
Функции личного кабинета на сайте стоит выбирать по таким возвращениям. Нужны сведения, доступные действия и понятный результат — вместе с правилами доступа, восстановления и работы с личными данными. Начать удобнее с одного полного сценария, а затем проверить, что происходит при ошибках и прекращении доступа.
Какую задачу человек продолжит после входа
Разберём учебный пример: мастерская ремонта бытовой техники принимает обращения на сайте. Клиент описывает неисправность, позже получает результат диагностики и отвечает на предложение ремонта. Это вымышленный процесс для проектирования, а не описание проекта Студии Вебирус или правил конкретной мастерской.
Для этого сценария полезно заранее пройти путь клиента:
- Первое обращение. Человек отправляет сведения и понимает, принята ли заявка. Если кабинет создаётся позже, отдельно предусмотрите безопасную привязку прежнего обращения к учётной записи.
- Возвращение. После входа он сразу видит текущую заявку, последнее изменение и вопрос, на который должен ответить.
- Действие. Открывает предложение, принимает решение или пишет уточнение. Понимает, какой именно вариант подтвердил и сохранился ли ответ.
- Завершение. Находит историю и доступные документы без нового обращения к менеджеру.
Из этого получается структура личного кабинета: текущие обращения, карточка обращения с историей и действиями, документы, контактные данные и настройки доступа. В небольшом кабинете часть сведений можно объединить на одной странице. Количество пунктов меню само по себе не определяет пользу.
Главный экран лучше посвятить незавершённой задаче: «Нужно ваше решение» полезнее, чем приветствие рядом с пустым графиком. Изменение аватара, бонусы, чат и рекомендации добавляйте, когда они помогают известному процессу. Переписка внутри кабинета, например, оправданна, если её действительно ведут сотрудники; иначе покажите действующий канал связи и сведения, которые помогут найти заявку.
Обычный кабинет обслуживает действия человека от своего имени. В B2B-кабинете появляется отдельный контекст компании: её сотрудники, полномочия, условия закупки и согласования. Не переносите эту сложность в кабинет частного клиента только потому, что она встречается у крупных магазинов. И наоборот, личный профиль сотрудника не заменяет модель доступа от имени организации.
Кто и что вправе делать
Фраза «будут клиент и администратор» оставляет слишком много неизвестного. Для каждой роли зафиксируйте действие, доступные данные и условия. Вход подтверждает учётную запись; он не даёт права читать все обращения системы.
Для учебной мастерской можно обсудить такую матрицу. Это предложение для разбора, которое владелец должен сверить со своим процессом.
| Участник | Возможные действия | Граница доступа, которую нужно определить |
|---|---|---|
| Клиент | Смотреть обращение, отвечать, получать доступные ему документы | Только связанные с ним обращения и файлы; не внутренние заметки сотрудников |
| Специалист | Обрабатывать назначенное обращение, добавлять результат работы | Назначенные обращения либо другая явно согласованная область |
| Администратор | Назначать полномочия, блокировать доступ, разбирать исключения | Отдельные управленческие права; не автоматический доступ ко всем данным |
Отдельно решите, кто меняет владельца обращения, может ли клиент отменить его и на каком этапе, что разрешено после завершения. Ограничение «ответить только на актуальное предложение» — тоже правило доступа к действию, хотя оно зависит от состояния заявки, а не от названия роли.
Права проверяются на сервере для конкретного объекта
Скрыть чужую заявку или кнопку в интерфейсе недостаточно. При запросе карточки, отправке ответа и скачивании файла сервер должен проверить и разрешённое действие, и принадлежность объекта пользователю либо другую согласованную связь с ним.
Например, клиент открыл свою заявку и заменил её идентификатор в запросе на идентификатор другого обращения. Сервер должен отказать в доступе. То же относится к вложению, результатам поиска и выгрузке. Длинный случайный идентификатор усложняет угадывание, но не заменяет проверку прав.
Файл с персональными сведениями нельзя защищать лишь отсутствием ссылки в меню: отдельно проверяется возможность получить его напрямую. Эти случаи стоит включить в приёмку с двумя тестовыми клиентами, а не ограничиться демонстрацией кабинета одного пользователя.
Как человек получит и восстановит доступ
Регистрацию нужно связать с моментом, когда кабинет приносит пользу. Для первого обращения обсудите, нужен ли обязательный аккаунт или достаточно отправить заявку и предложить вход для дальнейшей работы. Решение зависит от того, какие сведения и действия защищает кабинет.
Если в системе уже есть обращения без учётной записи, определите способ подтверждения связи с ними. Не показывайте историю только потому, что посетитель ввёл совпадающий адрес почты или телефон. Подтверждение владения контактом и право на конкретное обращение должны соответствовать заранее выбранному процессу.
Выберите подходящий способ входа, затем опишите его неудачные состояния: неверные данные, непришедшее сообщение, истёкшее подтверждение, слишком частые попытки. Форма должна позволять пользоваться менеджером паролей и вставлять данные. Для сотрудников с чувствительными полномочиями отдельно оцените дополнительное подтверждение входа и его восстановление.
Забытый пароль и потерянная почта — разные ситуации
Если выбран вход с паролем, предусмотрите самостоятельный сброс через подтверждённый канал. Ссылка или код должны быть одноразовыми, иметь ограниченный срок действия и защиту от массовых запросов. Ответ формы не должен раскрывать постороннему, зарегистрирован ли введённый адрес.
После сброса пользователь получает уведомление об изменении, а не сам пароль. Заранее решите, как завершаются прежние сеансы — входы, уже открытые на других устройствах. Простая смена пароля может оставить такой вход действующим, если это не учтено в реализации.
Если почта или телефон недоступны, обычная отправка кода проблему не решит. Нужен отдельный порядок восстановления: куда обращаться, кто рассматривает запрос, какие независимые подтверждения допустимы и что делать, когда их недостаточно. Не поручайте сотруднику менять контакт по одному сообщению «это мой аккаунт» и не превращайте сбор копий документов в правило по умолчанию.
Такой порядок лучше определить до запуска. При подозрении на захват аккаунта дополнительно проверяют изменённые способы восстановления и прекращают прежние сеансы; одного нового пароля недостаточно для подтверждения, что доступ возвращён владельцу.
Что показать в карточке и при сбоях
Согласуйте с сотрудниками словарь пользовательских статусов. «В обработке» не объясняет, кому сейчас нужно действовать. В учебной мастерской состояния могут выглядеть так; реальные этапы и условия переходов определяет бизнес.
| Ситуация | Что видит клиент | Что можно сделать |
|---|---|---|
| Обращений ещё нет | Понятное пустое состояние | Создать первое обращение |
| Заявка принята | Подтверждение приёма и её содержание | Открыть подробности, выбрать доступный канал связи |
| Нужны сведения | Конкретный вопрос сотрудника | Отправить ответ |
| Готово предложение | Содержание и актуальная версия предложения | Выбрать разрешённое решение |
| Работа завершена | Результат, история и доступные документы | Посмотреть или скачать свои материалы |
| Данные временно не загрузились | Сообщение о технической проблеме | Повторить загрузку либо связаться с поддержкой |
Последняя строка — состояние интерфейса, а не этап ремонта. Сбой загрузки нельзя выдавать за отсутствие заявок или завершённую работу. Если показываете ранее полученные сведения, обозначьте, что они могут быть неактуальны, и время их обновления.
Для изменения данных нужен отдельный результат: «Ответ сохранён» или сообщение о неудаче. Если связь оборвалась после отправки, кабинет должен помочь проверить результат, а повторное нажатие не должно создавать второй ответ или обращение. Зафиксируйте это требование для разработчика, а не полагайтесь только на отключение кнопки.
Проверьте и ситуацию с двумя открытыми вкладками. Пока клиент читает предложение, сотрудник может изменить его. Обсудите правило: например, показать новую версию и запросить повторное подтверждение. Не принимайте решение по устаревшим условиям молча.
Когда статусы или документы приходят из другой системы, определите источник каждого значения и поведение при задержке обмена. Механизм такого взаимодействия разобран в статье о том, как сайт обменивается данными через API.
Какие личные данные действительно нужны
Для каждого поля ответьте: для какой задачи его собирают, кто видит, кто меняет и где хранится актуальное значение. В учебном сценарии может понадобиться контакт для связи и описание техники. Дата рождения или домашний адрес не становятся необходимыми только из-за наличия страницы «Профиль».
Разделите данные профиля и данные уже отправленного обращения. Исправление телефона для будущей связи не должно незаметно переписывать исторические сведения в документе. Если контакты поступают из CRM, решите, куда сохраняется изменение и как пользователь узнает, что оно принято.
Смена адреса для входа или восстановления — чувствительная операция. Нужны повторное подтверждение личности подходящим способом, проверка нового контакта и уведомление по согласованной процедуре. Изменение нельзя считать завершённым, пока требуемые подтверждения не получены. Случай потери прежнего контакта относится к отдельному восстановлению, а не к обходу этой проверки.
Настройки уведомлений должны отражать реальные каналы и события. Разделите сообщения по заявке и маркетинговые рассылки; объясните, что именно отключает переключатель. Не обещайте отказаться от всех сообщений, если после этого система продолжит отправлять часть из них.
Содержание документов о персональных данных, основания обработки, сроки хранения и порядок обращений согласуйте для конкретного бизнеса с ответственным специалистом. У интерфейса должны быть действующие правила, которые можно выполнить. Кнопка «Удалить» сама по себе не определяет юридический порядок и не позволяет обещать немедленное исчезновение всех связанных записей.
Что происходит при закрытии доступа
Различайте выход на текущем устройстве, завершение всех входов, блокировку аккаунта и запрос на удаление данных. Они дают разные результаты. Выход не отменяет заявку; блокировка ограничивает доступ; обработка запроса на удаление требует своего подтверждённого порядка.
До запуска определите:
- Кто может заблокировать или закрыть аккаунт и как подтверждается такое действие.
- Что произойдёт с активным обращением и как клиент сможет продолжить общение без входа.
- Какой результат и какие последствия показываются перед подтверждением и после него.
- Как выполняется обработка данных в связанных системах, если они участвуют в процессе.
Отозванные полномочия должны перестать работать на сервере, в том числе из ранее открытой вкладки. Кнопка выхода тоже должна прекращать сеанс, а не просто переводить человека на главную страницу. Проверять нужно новый запрос после выхода или блокировки; уже увиденную и сохранённую пользователем информацию этим действием вернуть невозможно.
Для разбора проблем предусмотрите журнал существенных действий: назначение прав, восстановление, блокировка, результат чувствительной операции. Обсудите доступ к журналу и не сохраняйте в нём пароли, коды подтверждения или содержимое личной переписки без необходимости.
Что зафиксировать перед разработкой и приёмкой
Для обсуждения разработки личного кабинета подготовьте описание сценария, матрицу полномочий, поля с источниками данных, статусы с переходами и порядок восстановления и закрытия доступа. Это позволяет определить первый рабочий объём без перечня функций «на всякий случай».
На приёмке полезно пройти весь учебный путь и несколько исключений:
- Новый клиент создаёт обращение, возвращается к нему и находит следующее действие.
- Два разных клиента не получают карточки, файлы и результаты поиска друг друга, в том числе при прямых запросах.
- Просроченное или повторно использованное подтверждение не восстанавливает доступ; потеря почты ведёт к отдельной процедуре.
- Ошибка загрузки отличается от пустого списка; повторная отправка и две вкладки не дают противоречивого результата.
- Изменение контакта, выход и отзыв прав выполняют именно те последствия, которые описаны пользователю.
- На телефоне и при управлении клавиатурой доступны вход, ответ и документы; ошибки понятны, а введённые данные не теряются без объяснения.
Если кабинет превращается в самостоятельный рабочий продукт с несколькими процессами, сложными ролями и обменом данными, обсуждайте его в рамках разработки веб-приложения. В обоих случаях исходная единица планирования одна: конкретное действие конкретного пользователя с конкретными данными и проверяемым результатом.
