ユーザーの要望を、どう業務の仕様へ変えるか

GOV.UKの記述方法は、利用者・必要なこと・目的を明らかにします。これに加え、共有システムでは「その事実を誰が確定するか」を調べる必要があります。別の画面が同じ情報を使うなら、同じ意味で読めなければなりません。

例えば「確認済み」は、内容を見たのか、取引条件を承認したのか、次工程へ渡せるのかで意味が違います。利用者の言葉を否定せず、その言葉が指す事実と責任を分けて定義します。

PBGの方針は、すべての仕事を一つの汎用画面へ押し込むものではありません。短い受付、確認待ちの解決、次の操作など、作業に特化したsurfaceには価値があります。共通化するのは業務の意味であり、必ずしも画面の形ではありません。

画面の統一を優先しすぎると、利用者が毎回不要な項目を通ることになります。反対に画面ごとにルールを持たせると、不整合が増えます。同じ能力を、異なる仕事の順序へ接続する設計が必要です。

文言や並び順の改善で業務の意味が変わらないなら、重い設計手続きを増やす必要はありません。状態、権限、共有データ、他画面の判定へ影響するときに、翻訳の工程を厚くします。

PBGの現在の判断は、要望の数ではなく、その変更がどの事実と責任を動かすかを見ることです。受入条件も「欄がある」ではなく、元の困りごとが解消したかで確認します。