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

Продукт: личный кабинет для utility-сценариев.

Роль: структура разделов, сценарии оплаты и передачи показаний, desktop/mobile responsibility split.

Фокус: частые действия, справочный слой, предупреждения в вводе показаний, разные задачи desktop и mobile.

Публичное доказательство: redacted source shots, task layer map, meter reading flow, desktop/mobile split.

Граница результата: не писать про снижение нагрузки на поддержку, рост оплат, сокращение ошибок или client name без approval.

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

Кто-то заходит на desktop, чтобы посмотреть историю и документы. Кто-то на mobile, чтобы быстро отправить показания или проверить статус. Если интерфейс не различает эти режимы, простое действие превращается в поиск.

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

Я разложил кабинет на два режима:

1. Быстро закрыть задачу: оплатить, передать показания, проверить важный статус.
2. Разобраться в информации: история, документы, настройки, обращения.

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

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

Кейс должен показывать не "редизайн кабинета", а task-first логику.

Минимальный набор:

1. Redacted desktop/mobile screenshots.
2. JTBD-карта частых задач.
3. Схема быстрых действий и справочного слоя.
4. Flow передачи показаний с warning state.
5. Desktop/mobile split.
6. Source/result boundary.

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

Я проверял это через несколько решений:

• оплата должна быть действием первого уровня;
• передача показаний должна быть коротким flow с понятной проверкой;
• важный статус должен быть виден без поиска;
• справочные разделы не должны мешать быстрым задачам;
• desktop и mobile могут решать разные части одной системы.

Публичный путь лучше показывать через короткое завершение задачи:

1. Пользователь входит с конкретной задачей.
2. Видит быстрые действия.
3. Выполняет оплату или передачу показаний.
4. Получает предупреждение, если значение выглядит необычно.
5. Уходит в историю или документы только если это нужно.

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

Я разделил кабинет на два слоя: первый отвечает за частые действия и актуальное состояние, второй - за историю, документы, настройки и дополнительные сведения.

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

Здесь важна не сложность формы, а ясность состояния: что вводится, почему появилось предупреждение, что произойдет после подтверждения.

Desktop лучше держит обзор: историю, документы, настройки, несколько счетов и более плотные данные. Mobile должен быстрее закрывать короткие повторяющиеся действия.

Такое разделение помогает не пытаться уместить весь кабинет одинаково в каждом формате.

Финальный артефакт должен показывать, что пользователь не изучает кабинет, а идет по короткому пути к задаче.

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

Публично это supporting case. Его сила - в аккуратной задаче и реальных redacted screenshots, а не в неподтвержденных метриках.

Я не называю клиента без отдельного approval и не заявляю снижение нагрузки на поддержку, рост оплат или сокращение ошибок. Все реальные screenshots должны быть redacted; generated artifacts - только как объясняющие схемы.

Получился более понятный кабинет для повторяющихся utility-сценариев: быстрые действия вынесены ближе к первому уровню, а справочные разделы не мешают оплате, передаче показаний и проверке начислений.

Количественные эффекты не раскрываются публично, пока нет подтвержденного источника.

• Можно ли назвать клиента или оставить категорию энергетическая компания.
• Какие роли точно входили в scope: физлица, юрлица, операторы.
• Какие task-flow artifacts должны быть source shots, а какие generated explanations.
• Есть ли подтвержденный эффект по оплате, показаниям или обращениям.
• Какие SOURCE/REDACTED shots можно переносить в runtime.

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