Кабинет для оплаты и передачи данных

Source-backed формулировка узкая: личный кабинет по оплате электроэнергии и сбору данных. В публичном кейсе это достаточно для compact supporting story: repeated utility tasks, где главные действия должны быть видны без погружения в большой кабинет. Все более широкие формулировки — gov-tech scale, конкретные роли, support workflow, документы, статусы и hard metrics — остаются source-gated до raw answers.

• 01Source-backed: electricity payment
• 02Source-backed: data collection / meter-reading direction
• 03Source-gated: roles, support/reference workflow, docs, statuses, metrics

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

• 01Десктоп показывает структуру кабинета и платежный контекст
• 02Мобильные экраны показывают короткий сценарий в повторяющейся задаче
• 03Warning-state показывает, как ошибка объясняется рядом с действием

• ▸ artifact · Десктопный кабинет

  Десктопный интерфейс личного кабинета в энергетике

• ▸ artifact · Мобильные состояния

  Мобильные состояния личного кабинета в энергетике

• ▸ artifact · Проверка показаний

  Состояние проверки показаний счетчика в мобильном интерфейсе

Для такого кабинета payment and data collection — repeated actions. Они должны быть отделены от всего, что пользователь читает позже: справка, история, документы, обращения, статусные детали. Это не source-backed before/after старого интерфейса. В публичной версии это формулируется как IA risk and design move: primary action layer против reference/support layer.

• 01Payment and data tasks are the primary layer
• 02Support/reference sections are secondary and source-gated
• 03Before/after evidence remains inferred, not measured

Current runtime framing: подключился через внешнюю продуктовую команду, делал ревизию текущих решений, предлагал новую IA, рисовал ключевые сценарии оплаты и передачи данных/показаний, работал в связке с лидом и аналитиком. Так как raw answers по этому кейсу еще не закрыты, роль остается conservative: IA and scenario design, not ownership of the whole cabinet, launch or measured utility outcomes.

• 01Внешняя продуктовая команда
• 02Review + IA proposal + payment/data scenarios
• 03No launch, ownership or hard outcome claim

Главный видимый артефакт 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.

• 01Source-backed: payment and data collection
• 02Reconstructed: two-layer IA
• 03Unknown: support/documents/status flow and hard metrics

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.

• 01Payment: source-backed primary action
• 02Data/meter readings: source-backed data-collection scenario
• 03Support/reference/docs/status: secondary source-gated layer

• ▸ artifact · Artifact · task source checklist + IA delta

  Energy cabinet task source checklist and IA delta

Оплата электроэнергии — 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.

• 01Source-backed: electricity payment
• 02Design move: primary action layer
• 03Unknown: completion time, errors, conversion, support impact

Source говорит о сборе данных; в utility-контексте это публично можно связывать с передачей показаний только как conservative data/meter-reading framing. Что нельзя усиливать без raw answers: точные статусы, validation rules, edge cases, role differences and error reduction.

• 01Source-backed: data collection
• 02Reconstructed: meter-reading as utility task framing
• 03Unknown: validation, statuses, errors, role differences

Справка, документы, история, обращения и account status полезны для IA, но в текущем source layer они не подтверждены как готовые публичные flows. Поэтому они остаются secondary layer in the artifact: видны как будущая структура, но не как доказательство support workflow or operational maturity.

• 01Secondary layer: reference/support/documents/status
• 02No source-backed support workflow yet
• 03No operational maturity or support-load claim

В публичном слое этот 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.

• 01Source-backed: payment and data collection
• 02Reconstructed: two-layer IA
• 03Unknown: support/reference flow, statuses, metrics, adoption