Загружаю страницу…
supporting · 2022 · поддерживающий
Личный кабинет должен был помогать людям быстро делать повторяющиеся вещи: оплатить, передать данные, проверить важное. Я пересобирал структуру так, чтобы основные действия не тонули в справке и второстепенных разделах.
role
Продуктовый дизайнер на стороне внешней команды
что изменилось
Главные действия стали первым слоем
year
2022
tags
Gov-tech · Utility · Массовый продукт
§ 01 · Контекст
Source-backed формулировка узкая: личный кабинет по оплате электроэнергии и сбору данных. В публичном кейсе это достаточно для compact supporting story: repeated utility tasks, где главные действия должны быть видны без погружения в большой кабинет.
Все более широкие формулировки — gov-tech scale, конкретные роли, support workflow, документы, статусы и hard metrics — остаются source-gated до raw answers.
§ 02 · Интерфейс
Главный визуальный слой теперь строится на реальных экранах: десктопный кабинет, мобильный сценарий и состояние проверки показаний. IA-схема ниже остается как рабочий материал, а не как обложка кейса.
§ 03 · Проблема
Для такого кабинета payment and data collection — repeated actions. Они должны быть отделены от всего, что пользователь читает позже: справка, история, документы, обращения, статусные детали.
Это не source-backed before/after старого интерфейса. В публичной версии это формулируется как IA risk and design move: primary action layer против reference/support layer.
§ 04 · Роль
Current runtime framing: подключился через внешнюю продуктовую команду, делал ревизию текущих решений, предлагал новую IA, рисовал ключевые сценарии оплаты и передачи данных/показаний, работал в связке с лидом и аналитиком.
Так как raw answers по этому кейсу еще не закрыты, роль остается conservative: IA and scenario design, not ownership of the whole cabinet, launch or measured utility outcomes.
§ 05 · Как читать 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.
§ 06 · Архитектура и сценарии
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.
§ 07 · Сценарий · оплата
Оплата электроэнергии — 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.
§ 08 · Сценарий · показания
Source говорит о сборе данных; в utility-контексте это публично можно связывать с передачей показаний только как conservative data/meter-reading framing.
Что нельзя усиливать без raw answers: точные статусы, validation rules, edge cases, role differences and error reduction.
§ 09 · Сценарий · reference/support
Справка, документы, история, обращения и account status полезны для IA, но в текущем source layer они не подтверждены как готовые публичные flows.
Поэтому они остаются secondary layer in the artifact: видны как будущая структура, но не как доказательство support workflow or operational maturity.
§ 10 · Что подтверждает
В публичном слое этот 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.