Энергокабинет

В кабинете могут сосуществовать оплата, передача данных, история, документы, настройки и обращения. Но в момент входа эти задачи не равнозначны.

Основной вопрос был в приоритетах: как сохранить глубину сервиса, не заставляя пользователя искать повторяющееся действие среди вторичных разделов.

Я разделил пользовательские намерения на два слоя:

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

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

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

Точные правила проверки и снижение числа ошибок не заявляются, поскольку отдельного источника для них нет.

Desktop подходит для обзора и более плотной информации. Mobile важнее для короткого повторяющегося действия.

Это не две независимые версии продукта, а разные точки входа в одну систему: на большом экране пользователь разбирается в контексте, на мобильном получает короткий task-first сценарий.

Кабинет получил task-first структуру: оплата и сбор данных стали основным слоем, а дополнительная информация не конкурирует с ними за внимание.

Это архитектурное решение, не измеренный результат. Снижение нагрузки на поддержку, рост оплат, экономия времени и сокращение ошибок не заявляются.

Я работал над приоритетами структуры и ключевыми self-service сценариями. Конкретный состав команды, запуск и количественный эффект в публичной версии не заявляются.

В массовом кабинете хороший UX часто заключается не в добавлении возможностей, а в правильном порядке уже существующих. Чем привычнее задача, тем меньше интерфейс должен требовать изучения.