Продукт
Личный кабинет покупателя: ТЗ на заказы, возвраты и доступ
Требования к кабинету интернет-магазина: гостевые заказы, статусы оплат и доставок, возвраты, права на данные, поддержка и мобильная приёмка.
Начните с задач покупателя после оформления заказа
Личный кабинет покупателя нужен, чтобы человек мог разобраться со своей покупкой без повторного объяснения всей истории сотруднику. Это не универсальный портал для любых ролей и не дополнительная витрина рекламы. В ТЗ перечислите конкретные задачи: увидеть состав заказа, проверить доставку, получить документ, изменить допустимые данные, обратиться по проблеме или повторить покупку. Для каждой укажите, какая информация доступна магазину и какой результат можно достоверно показать пользователю. Не обещайте самостоятельное действие, если за ним пока нет рабочего процесса.
Соберите обращения в поддержку за выбранный период и распределите их по причинам. Частый вопрос «где заказ» может означать отсутствие статуса, непонятное название этапа или противоречие между сайтом и службой доставки. Эти ситуации требуют разных решений. Укажите долю обращений только при наличии проверенных данных; если измерения нет, сохраните список наблюдений без выдуманного рейтинга. Для первой версии выбирайте задачи, где самообслуживание действительно помогает покупателю и не создаёт для него дополнительный риск ошибки.
Зафиксируйте границы кабинета: розничные покупатели, представители компаний, несколько получателей, семейные покупки или другие модели. Один адрес электронной почты не всегда означает одного получателя и один набор прав. Определите, может ли пользователь видеть заказы, оформленные без регистрации, и каким способом подтверждается связь. Такой вопрос влияет на безопасность и доверие сильнее, чем выбор внешнего вида карточек. Его необходимо решить до переноса истории и массового приглашения существующих клиентов в новую систему.
Спроектируйте вход и привязку прошлых заказов
Выберите способы входа с учётом доступных каналов и сценариев восстановления. Для кода по телефону или почте нужны срок действия, ограничение попыток, повторная отправка и понятное сообщение при задержке. Не заставляйте человека постоянно начинать путь заново из-за временной ошибки доставки. При этом интерфейс не должен раскрывать лишнюю информацию о существовании чужого аккаунта. В ТЗ опишите ожидаемое поведение на обычном устройстве, после выхода и при попытке продолжить действие из старой ссылки.
Привязка гостевого заказа требует отдельного подтверждения. Нельзя автоматически показывать историю только по совпадению введённого имени или доступному номеру заказа. Определите, какие сведения подтверждают владение и что делать при неоднозначности. Учебный пример: человек изменил телефон, а старые покупки оформлял на рабочую почту. Система должна предложить согласованный путь восстановления через поддержку, сохраняя ограничения доступа. Отсутствие автоматического совпадения не означает, что заказ не существовал или что клиент сообщает неверную информацию.
Смена контакта должна учитывать последствия для уже оформленных заказов и уведомлений. Укажите, меняется ли только профиль или также адрес связи по активной покупке. Если заказ передан в доставку, возможность изменения может быть ограничена внешним процессом. Не скрывайте это за общей кнопкой сохранения. Пользователь должен видеть, какие данные обновлены и где требуется отдельное обращение. На приёмке проверьте старую сессию, новое устройство и восстановление доступа после подтверждённой смены контактных данных.
Покажите понятную историю и достоверные статусы
В карточке заказа нужны состав, дата, стоимость, способ получения и текущее состояние с понятным объяснением. Не переносите внутренние технические названия напрямую в интерфейс. «Обработан» может означать проверку менеджером, резервирование товара или завершённую доставку. Создайте словарь клиентских статусов и сопоставьте их с источниками. Для каждого перехода укажите событие, время и допустимую задержку обновления. Если сведения временно недоступны, покажите последнее подтверждённое состояние с пояснением вместо выдуманного нового этапа.
Заказ, оплата и доставка должны иметь отдельные состояния. Частичная оплата не равна полной, а передача одной посылки не означает завершение заказа из нескольких отправлений. Приложите примеры с частичной отгрузкой, заменой позиции и отменой части покупки. Человек должен понимать, какие товары уже получены, какие ожидаются и какие действия доступны для каждой части. Это особенно важно для повторного заказа: нельзя автоматически переносить старый состав без проверки текущего наличия, цены и применимости условий.
Определите порядок сортировки и поиска истории. По умолчанию полезно выделять активные покупки и незавершённые обращения, сохраняя доступ к архиву. Фильтры должны опираться на понятные пользователю признаки, а не на внутреннюю структуру базы. Проверьте длинные названия, похожие товары, несколько заказов за один день и отсутствие фотографии. На мобильном экране ключевой статус и основное действие должны оставаться видимыми без горизонтальной прокрутки широкой служебной таблицы, созданной для сотрудников магазина.
Опишите допустимые изменения и финансовые вопросы
Для каждой операции задайте условия доступности: изменение получателя, отмена, повтор оплаты, запрос возврата или замена товара. Не ограничивайтесь перечнем кнопок. Укажите исходное состояние, необходимые сведения, последствия и способ подтверждения результата. Если решение принимает сотрудник, интерфейс должен создавать обращение и показывать его статус, а не сообщать, что операция уже выполнена. Это помогает избежать конфликтов между ожиданием клиента и фактическими полномочиями кабинета, особенно после передачи заказа внешнему исполнителю.
Финансовые действия требуют достоверного источника статуса. Сам факт нажатия «оплатить» или возвращения из платёжной формы не следует считать подтверждённым поступлением. В ТЗ опишите ожидание, отказ, неизвестный результат и повторную проверку через предусмотренный провайдером механизм. При спорной операции пользователь должен получить понятный следующий шаг и номер обращения. Не предлагайте повторное списание до выяснения результата предыдущей попытки, если это может создать лишний платёж. Конкретный контракт платёжного сервиса проверяется отдельно.
Запрос возврата отделите от принятого решения и завершённого движения денег. Укажите, какие данные собираются, кто рассматривает запрос и как покупатель видит ход обработки. Правила возврата и сроки предоставляет уполномоченная сторона магазина; интерфейс не должен придумывать их самостоятельно. Сохраняйте историю решения и связь с конкретными позициями заказа. Если документы или фотографии необходимы, объясните зачем и проверьте удобство загрузки с телефона. Нельзя требовать повторно сведения, которые уже доступны в выбранной покупке.
Защитите данные и документы каждого покупателя
Доступ проверяется для каждой операции и каждого объекта. Скрыть чужой заказ из списка недостаточно, если его можно получить по прямой ссылке или через файл. В рекомендациях OWASP по авторизации подчёркиваются минимальные полномочия и проверка разрешений при обращениях. Для кабинета практическая проверка проста: создайте двух тестовых покупателей и убедитесь, что один не получает сведения другого через карточку, поиск, документ, обращение и повторный заказ. Используйте безопасные данные и согласованную тестовую среду.
Для документов определите владельца, версию и срок доступности ссылки. Счёт, чек, акт или инструкция могут иметь разные источники и правила обновления. Не заменяйте старый документ новым без объяснения, если пользователю важно сохранить историю покупки. Проверьте, что скачивание работает после обновления страницы и не раскрывает сведения через общую публичную папку. Если внешний сервис временно недоступен, кабинет должен показать понятное состояние документа, а не пустой экран или сообщение, которое ошибочно отрицает его существование.
Согласуйте, какие сведения сохраняются на устройстве и что происходит после выхода. Общий семейный компьютер и рабочий телефон создают разные условия, но пользователь должен иметь понятный контроль сессии. Не помещайте чувствительные данные в адрес страницы и диагностические сообщения без необходимости. Для сотрудников поддержки определите отдельный способ просмотра контекста с журналом действий. Возможность помочь клиенту не должна превращаться в бесконтрольное использование его аккаунта или изменение истории без следа и объяснения.
Сделайте помощь продолжением выбранного заказа
Обращение из карточки должно сохранять связь с покупкой и выбранной проблемой. Покупателю не нужно заново вводить номер, состав и контакт, если система уже знает эти сведения. Дайте возможность уточнить вопрос, приложить файл и увидеть дальнейший статус. Отдельно определите, что происходит при нескольких обращениях по одному заказу: они могут относиться к разным вопросам и не всегда являются дублями. Автоматическое объединение должно сохранять контекст, а спорные случаи следует передавать сотруднику.
Уведомления должны соответствовать фактическому состоянию и выбранным каналам. Для каждого события задайте текст, время, получателя и защиту от повторов. Если доставка события повторилась, клиент не должен получать одинаковое сообщение несколько раз. При этом новое существенное изменение нельзя потерять из-за слишком широкого правила подавления дублей. Согласуйте предпочтения пользователя и способы прекращения необязательных уведомлений. Сервисная информация о действующем заказе и рекламное предложение требуют разных правил, которые владелец бизнеса определяет отдельно.
Проверьте поведение после ответа поддержки. Должен ли клиент подтвердить решение, может ли открыть вопрос снова и как виден новый ответ? Закрытие обращения сотрудником не всегда означает, что проблема исчезла. В ТЗ задайте понятную историю, автора действия и возможность продолжить обсуждение в допустимых границах. Если вопрос передан другой команде, пользователь должен видеть, что работа продолжается, без необходимости разбираться во внутренней структуре подразделений и самостоятельно искать следующего ответственного человека.
Проверьте мобильный путь и доступность
Составьте короткий набор мобильных задач: войти по коду, открыть активный заказ, скачать документ, приложить фотографию и вернуться к списку. Проверяйте их на реальных размерах экрана и с открытой клавиатурой. Модальные окна должны закрываться понятным способом, а возврат не должен терять введённый текст. Если фотография открывается поверх кабинета, пользователь должен легко вернуться к обращению. Такие детали непосредственно влияют на возможность завершить задачу, хотя часто отсутствуют в первоначальном списке функций.
WCAG 2.2 содержит проверяемые критерии доступности, включая требования к управлению, фокусу и понятности взаимодействия. Выберите применимый набор для проекта и включите его в приёмку. Не объявляйте полное соответствие только после автоматического сканирования. Для кабинета полезно отдельно проверить клавиатурную навигацию, видимость фокуса, подписи полей, ошибки ввода и масштабирование текста. Условия и результаты ручных проверок должны быть сохранены, чтобы после изменения компонента можно было повторить затронутые сценарии.
Для скорости задайте операции и объём истории, а не общее пожелание. У покупателя с большим архивом кабинет должен открываться без загрузки всех вложений сразу. Уточните поведение при медленной связи: последнее известное состояние, индикатор обновления и безопасный повтор. Не показывайте завершение операции до её подтверждения. На приёмке прервите сеть после отправки обращения, обновите страницу и восстановите соединение; система должна объяснить результат и не создать несколько одинаковых запросов из повторных действий пользователя.
Примите кабинет по сквозным сценариям
Подготовьте тестовые истории: новая покупка, гостевой заказ, частичная доставка, неуспешная оплата, несколько документов, возврат и обращение в поддержку. Для каждой укажите ожидаемые данные и действия. Сверяйте кабинет с источником заказов, а не только с собственной базой интерфейса. Если интеграция отстаёт, это должно быть отражено в поведении и наблюдении. Отдельно проверьте повторные события и изменение заказа сотрудником, пока покупатель держит открытую страницу со старой версией данных.
Комплект передачи включает модель статусов, матрицу доступа, описание интеграций, тексты уведомлений и инструкции поддержки. Назначьте владельцев ошибок обмена и спорных финансовых состояний. В аналитике разделяйте открытие кабинета, завершение задачи и обращение к сотруднику. Снижение числа обращений не всегда означает улучшение: человек мог не найти помощь. Поэтому количественные показатели следует дополнять проверкой успешности задач и обратной связью покупателей, сохраняя ограничения интерпретации и не выдавая посещения за продажи.
Заполняемый бриф в источниках поможет собрать правила до оценки разработки. Начните с активного заказа и наиболее частого вопроса после покупки, затем добавьте необходимые исключения. Хороший кабинет даёт человеку достоверный ответ и понятное действие в конкретной ситуации. Он не обязан сразу включать все возможные функции магазина, но должен сохранять историю, защищать чужие данные и честно показывать границу между выполненным действием, отправленным запросом и решением, которое ещё принимает сотрудник.
Источники
- Authorization Cheat Sheet
OWASP Cheat Sheet Series / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Web Content Accessibility Guidelines 2.2
W3C / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Можно ли привязать гостевой заказ к кабинету только по имени?
Нет. Совпадение имени не подтверждает владение заказом. Нужен согласованный способ подтверждения и безопасный разбор неоднозначности без раскрытия чужих сведений.
Как показать заказ, отправленный несколькими посылками?
Сохранить отдельные отправления с их составом и состояниями, а общую сводку объяснять через эти данные. Не следует отмечать весь заказ доставленным по первой полученной части.
Почему возврату нужны отдельные состояния?
Запрос покупателя, согласование, получение товара и подтверждённый возврат денег являются разными событиями. Их разделение позволяет давать точный ответ и не обещать завершение операции раньше подтверждения.
