> cat cases/energy-cabinet/*.md
╔══════════════════════════════════════════════════════════════════╗ ║ ● SUPPORTIN… · 202… · поддерживающий ║ ╠══════════════════════════════════════════════════════════════════╣ ║ ║ ║ КАБИНЕТ ДЛЯ ОПЛАТЫ И ПЕРЕДАЧИ ДАННЫХ ║ ║ ║ ╚══════════════════════════════════════════════════════════════════╝
Личный кабинет должен был помогать людям быстро делать повторяющиеся вещи: оплатить, передать данные, проверить важное. Я пересобирал структуру так, чтобы основные действия не тонули в справке и второстепенных разделах.
role : Продуктовый дизайнер на стороне внешней команды
что изменилос… : Главные действия стали первым слоем
tags : Gov-tech, Utility, Массовый продукт, IA> cat sections/01-context.md
# § 01 · КОНТЕКСТ
Self-service кабинет для оплаты и сбора данных
Source-backed формулировка узкая: личный кабинет по оплате электроэнергии и сбору данных. В публичном кейсе это достаточно для compact supporting story: repeated utility tasks, где главные действия должны быть видны без погружения в большой кабинет.
Все более широкие формулировки — gov-tech scale, конкретные роли, support workflow, документы, статусы и hard metrics — остаются source-gated до raw answers.
[01] Source-backed: electricity payment [02] Source-backed: data collection / meter-reading direction [03] Source-gated: roles, support/reference workflow, docs, statuses, metrics
> cat sections/02-interface-screens.md
# § 02 · ИНТЕРФЕЙС
Десктоп и мобильные состояния вместо одной IA-схемы
Главный визуальный слой теперь строится на реальных экранах: десктопный кабинет, мобильный сценарий и состояние проверки показаний. IA-схема ниже остается как рабочий материал, а не как обложка кейса.
[01] Десктоп показывает структуру кабинета и платежный контекст [02] Мобильные экраны показывают короткий сценарий в повторяющейся задаче [03] Warning-state показывает, как ошибка объясняется рядом с действием
> cat sections/03-problem.md
# § 03 · ПРОБЛЕМА
Главный риск: primary actions тонут в reference/support слое
Для такого кабинета payment and data collection — repeated actions. Они должны быть отделены от всего, что пользователь читает позже: справка, история, документы, обращения, статусные детали.
Это не source-backed before/after старого интерфейса. В публичной версии это формулируется как IA risk and design move: primary action layer против reference/support layer.
[01] Payment and data tasks are the primary layer [02] Support/reference sections are secondary and source-gated [03] Before/after evidence remains inferred, not measured
> cat sections/04-role.md
# § 04 · РОЛЬ
Продуктовый дизайнер на стороне внешней команды
Current runtime framing: подключился через внешнюю продуктовую команду, делал ревизию текущих решений, предлагал новую IA, рисовал ключевые сценарии оплаты и передачи данных/показаний, работал в связке с лидом и аналитиком.
Так как raw answers по этому кейсу еще не закрыты, роль остается conservative: IA and scenario design, not ownership of the whole cabinet, launch or measured utility outcomes.
[01] Внешняя продуктовая команда [02] Review + IA proposal + payment/data scenarios [03] No launch, ownership or hard outcome claim
> cat sections/05-artifact-inspection.md
# § 05 · КАК ЧИТАТЬ PROOF
Артефакт — это checklist, не полноценный task-flow proof
Главный видимый артефакт intentionally compact: он не притворяется production flow. Он разделяет confirmed / inferred / unknown tasks before any stronger claim.
Payment and data/meter-reading tasks можно читать как source-backed core. Account status, support/reference and documents — как source-gated future layer. Two-layer IA — reconstructed design move, not support-load, speed or error-reduction proof.
[01] Source-backed: payment and data collection [02] Reconstructed: two-layer IA [03] Unknown: support/documents/status flow and hard metrics
> cat sections/06-architecture.md
# § 06 · АРХИТЕКТУРА И СЦЕНАРИИ
Before/after logic: payment and data first, reference/support second
Before layer в публичной реконструкции: payment, data/meter readings, support/reference and documents compete inside one account surface. After layer: payment and data collection become primary actions; support/reference stays a secondary layer until its source is confirmed.
Так case поддерживает utility UX expertise: repeated action first, reference later. Но он не притворяется большим gov-tech transformation case и не заявляет measured task-time or support reduction.
[01] Payment: source-backed primary action [02] Data/meter readings: source-backed data-collection scenario [03] Support/reference/docs/status: secondary source-gated layer
> cat sections/07-scenario-payment.md
# § 07 · СЦЕНАРИЙ · ОПЛАТА
Payment: source-backed primary action
Оплата электроэнергии — source-backed task. В final copy ее нужно держать как главный repeated action, а не как часть широкого energy/gov-tech claim.
Что можно показывать: payment belongs to primary action layer. Что нельзя без source: conversion, payment completion time, fewer errors or support-load reduction.
[01] Source-backed: electricity payment [02] Design move: primary action layer [03] Unknown: completion time, errors, conversion, support impact
> cat sections/08-scenario-meters.md
# § 08 · СЦЕНАРИЙ · ПОКАЗАНИЯ
Data / meter readings: repeated action with source-gated details
Source говорит о сборе данных; в utility-контексте это публично можно связывать с передачей показаний только как conservative data/meter-reading framing.
Что нельзя усиливать без raw answers: точные статусы, validation rules, edge cases, role differences and error reduction.
[01] Source-backed: data collection [02] Reconstructed: meter-reading as utility task framing [03] Unknown: validation, statuses, errors, role differences
> cat sections/09-scenario-reference-support.md
# § 09 · СЦЕНАРИЙ · REFERENCE/SUPPORT
Support and reference sections stay secondary until sourced
Справка, документы, история, обращения и account status полезны для IA, но в текущем source layer они не подтверждены как готовые публичные flows.
Поэтому они остаются secondary layer in the artifact: видны как будущая структура, но не как доказательство support workflow or operational maturity.
[01] Secondary layer: reference/support/documents/status [02] No source-backed support workflow yet [03] No operational maturity or support-load claim
> cat sections/10-result.md
# § 10 · ЧТО ПОДТВЕРЖДАЕТ
Compact proof: priority layers for utility self-service
В публичном слое этот case доказывает только compact IA judgment: payment and data collection should sit above secondary support/reference sections.
Он не доказывает масштаб gov-tech продукта, task-time reduction, support-load reduction, error reduction or adoption. Это supporting case for priority layers and utility UX, not a flagship transformation.
[01] Source-backed: payment and data collection [02] Reconstructed: two-layer IA [03] Unknown: support/reference flow, statuses, metrics, adoption
> ls ../