[🛠] Operations Automation #5: 失敗したプロトタイプをUI監査基準に変えた
✨ GPT-5.6 Solの要約
余白だらけの巨大カードと崩れたtableを画面ごとに直すのではなく、検索・filter・複数行の行・現在のviewのdownload・編集リスク分類を共通UI監査基準にした記録。
大きなcardと広い余白が画面を壊した
50代以上の会社員と管理者が使う休暇管理画面を設計し直していた。大きな文字、大きな操作領域、十分な余白が要件だった。ところがプロトタイプは、その言葉を最も単純で最悪な形に解釈した。
一行で済む数値を項目名 → 大きな数字 → 補足説明の三行に分け、巨大なcardへ入れた。三つのcardが最初の画面をすべて占め、ユーザーが今処理すべき仕事は下へ押し出された。申請画面はcalendar、要約、入力を大きな白い箱として別々に積み、履歴tableは重要な値が空欄なのに状態badgeだけが残った。横scrollまで生じた。
以前、実機のmobile端末でつぶれたtableとfilterを直したときは、overflowと折り返しをなくせば画面は改善すると考えていた。今回のプロトタイプは、それより根本的な問題を見せた。壊れない画面と使える画面はまったく別物だった。
UI監査基準は画面より先に壊れていた
さらに大きな問題は、別の監査手順を通したのに、この画面が生き残ったことだった。
監査はrouteが開くか、文字が切れないか、controlを押せるか、色や間隔が大きくずれていないかを見た。しかし、次の質問は強制していなかった。
- 最初の画面で、ユーザーが今処理すべき仕事を見つけられるか
- 同じ判断に必要な値が一つの視界にまとまっているか
- 空白が情報の関係を説明しているか、それともcomponentの大きさを埋めているだけか
- tableの検索・filter・sort・全件数・結果が一つの流れになっているか
- 表示した結果をそのままdownloadして再利用できるか
- 修正できる値と上書きしてはいけない履歴が区別されているか
監査項目になければ、Agentは問題を見ても通過させる。そこで画面ごとにpaddingを減らすのではなく、この失敗を二度と通せないように共通監査基準から直した。
Collectionは検索・結果・downloadを一つにまとめた
最も詳しく見た参考画面は、他社の休暇管理appにある申請管理tableだった。公式helpでも、Web管理者modeの日付検索、申請filter、承認・却下の流れを一つの業務として説明している。1 参考画像でより目に留まったのは、機能の数ではなく機能間の距離だった。
期間と申請種別は結果のすぐ上にあった。検索欄は各列に対応し、全申請数とdownloadが同じ視界に入った。一つの申請の日付、変更前後、勤務時間差のように一緒に読む値は、列を増やし続けず一つのcell内に複数行でまとめていた。状態と実行可能なactionも同じ行で続いた。
この構造を特定の休暇画面だけに写さず、collectionの共通contractとして一般化した。
- table、grid、密度の高いlist、calendarのlist viewでは、結果のすぐ上にsearch/filter blockを置く。
- 期間・scope、検索、quick filter、詳細filter、適用条件、全件/現在件数、reset、downloadを同じ視界に置く。
- 同じ判断に使う値は
主情報 → 補助情報 → 条件付き警告の順で複数行cellにまとめる。 - 行の高さは内容が決める。複数行だからといって固定高のmini cardにしない。
- downloadは現在のpageに見える数行ではなく、現在の条件に合う全結果を出力する。
- exportは現在のscope、期間、検索、filter、sort、基準時刻、ユーザーに見える業務列をそのまま保持する。
- 個人情報や監査資料もdownload自体をなくさず、同じ権限・masking・auditを適用する。
「download buttonがある」だけの検査では、また失敗する。実際の画面の件数、代表行、適用済みfilter、sort、maskingが出力ファイルと一致するかまで比較しなければならない。
編集方式はデータのリスクで分けた
table上で値を直接直せれば便利だ。しかし全cellをExcelのようにすると、承認、台帳、法的証拠まで普通の入力欄として上書きできてしまう。
そこで編集controlを選ぶ前に、変更の性質を分類した。
| 変更の性質 | 基本interaction |
|---|---|
| 元に戻せる単一の低リスク値 | 見える編集affordanceを持つinline edit |
| 複数行の安全な反復修正 | 明示的なeditable-grid mode |
| 周辺の文脈も見る必要がある複数field | list位置を維持するside panel |
| 短く独立した入力・確認 | 目的が一つのmodal |
| 高リスク・適用日・権限・version・append-only変更 | 別のpreview-and-applyまたはcorrection workflow |
double-click、Enter、F2は熟練者向けの加速手段に限る。編集への入口をそれだけに隠さない。gridにはkeyboard移動、変更cell表示、validation、undo、全取消、stale競合、適用前preview、適用後readbackが必要だ。承認・却下やappend-only台帳のeventはcell editの対象ではない。
共通監査ルールと製品contractを分離した
参考画面から学んだことをすべてLeave Operations専用ルールにすると、次のprojectで同じ失敗を繰り返す。逆に休暇の承認段階、促進文書、台帳補正といった業務ルールまで共通Skillへ入れると、共通基準が特定製品の設計書になる。
そこで境界を分けた。
共通ルールとUI監査Skillには、次の失敗類型を入れた。
- 短いscalarを巨大な独立cardにする構造
- label・値・分母を機械的に三行へ分ける構造
- 結果から離れた検索・filter
- 全件数・reset・現在viewのdownloadがないcollection
- 関連値を過剰な列に展開したり、複数行を固定高にしたりするtable
- 権限や現在viewの条件が画面と異なるexport
- hoverやdouble-clickだけに隠れた編集
- 高リスク・versioned・append-onlyデータを通常のcellやpopupで上書きする動作
Leave Operations文書には、その原則をどのpageのどのviewに使うかを別に配置した。承認箱、従業員、促進、台帳、出勤簿の衝突、SMS結果、業務用携帯の各tableに検索・filter・sort・download contractを置き、従業員・所属のように反復修正が必要な領域と、承認・台帳のように直接修正してはいけない領域を分けた。
画面はまだ直していない
この作業で実際の製品UIが改善したわけではない。共通ルール、UI専用監査Skill、製品別画面contractを修正し、参考画像を元のhashとともに保存した。Leave Operationsのdesktop画面はまだそのcontractどおりに実装されておらず、50代の会社員・管理者が通常の入口から自分で業務を終える検証もしていない。
それでも次のプロトタイプは、少なくとも同じ理由で通過してはならない。大きな文字と十分な操作領域は守りつつ、画面を肥大化させる言い訳にはしない。目標は低い情報密度ではなく、高い情報密度と低い認知負荷だ。
コメントする