戻ってきた瞬間のためのデザイン

ほとんどのソフトウェアは、情報がどこにあるかは記憶している。 しかし、作業がどのような状況にあるかまでは記憶していない。

AIエージェントの使用を考えてみてください。 タスクを与え、 別の作業に切り替え、 90秒後に戻ってくる。 すると、エージェントは「完了しました」と言う。

ここで問題が発生します。 それは単にドラフトを作成しただけなのか？ 実際のデータを書き換えたのか？ それを裏付ける証拠はあるのか？ 人間の判断が必要なのか？

これらに答えるためには、チャットログや通知、タブを漁らなければなりません。 システムは「活動」は記録していても、「コンテキスト（文脈）」を失っているのです。 このギャップこそが、Workstream Continuity Design (WCD) が必要な理由です。

WCDは、作業を切り替えるたびに、インターフェースが作業の状態を記憶していることを保証します。

従来の設計は、ユーザーが唯一の作業者であることを前提としています。 現代の設計は、ユーザーが離れている間にソフトウェアが稼働していることを考慮しなければなりません。 あなたは同時に複数の事柄を監督しているかもしれません：

  • あるトピックを調査しているエージェント
  • コードを書いているエージェント
  • 顧客への返信
  • ブロックされたデプロイメント

主要なタスクは「スイッチイン（作業への復帰）」になります。 ワークストリームに入り、状態を把握し、意思決定を行い、去る。 毎回コンテキストを再構築しなければならないなら、時間と集中力を失うことになります。

WCDは、素早く状況を把握するために特定の文法（グラマー）を使用します： • GOAL: 望む結果。 • ATTN: なぜ今確認する必要があるのか。 • STATE: 現在の状況。 • DELTA: 実際に何が変わったのか。 • ACTORS: 誰が担当し、次に誰が動くのか。 • AUTH: 何が許可されているか。 • EVIDENCE: 状態を裏付ける根拠。 • EFFECT: 影響範囲とリスク。 • NEXT: 最も安全な次の一手。

これは単なるステータスランプよりも有用です。 長いチャット履歴を読むよりも迅速です。

WCDの成功は、ユーザーがどれだけ速くクリックするかではなく、どれだけ速く理解できるかにかかっています。 私たちはこれを以下の指標で測定します：

  • Time to Orientation（状況把握時間）: 行動が必要かどうかを判断するまでの速さ。
  • Time to Decision Readiness（意思決定準備時間）: 変化を理解するまでの速さ。
  • False-ready rate（誤認完了率）: 作業が終わっていないのに、完了したと誤認してしまう頻度。

目標は、ソフトウェアが人間の監視をサポートする、一貫性のあるモデルを構築することです。

Zenodoで研究の全文を読んでください。

Source: https://dev.to/conalh/designing-for-the-moment-you-switch-back-introducing-workstream-continuity-design-3kbb

Optional learning community: https://t.me/GyaanSetuAi