複雑な設計案件に着手する際、私は特定のフレームワークを用いて複雑なワークフローを整理し、問題点を特定します。私はそれを「コンテキスト・トゥ・アーキテクチャ・フレームワーク」と呼んでいます。このフレームワークによって、設計が憶測ではなく現実に基づいていることが保証されます。

i. 文脈的探究

私たちは要件収集から始めるのではなく、観察から始めます。ユーザーの実際の作業環境に同席し、タスクの実行を最初から最後まで観察します。公式ソフトウェアから離れるたびに記録し、使用するすべての物理的な成果物も記録します。中断や回避策も含め、作業の実態をマッピングします。その結果として得られる成果物は、ユーザーが実際に使用するツールと手順の全体像を示す成果物マップです。

ii. アーティファクト分析

私たちは、ユーザーが作成したスプレッドシート、メモ、記録したマクロなど、非公式なワークフローを収集します。これらの成果物は、摩擦の物理的な現れです。公式ソフトウェアが提供できない機能を正確に示してくれます。ユーザーが利益率を計算するために複雑なスプレッドシートを作成した場合、公式ツールには柔軟な計算ロジックが欠けていることが分かります。スプレッドシートは設計要件となるのです。

iii. フローの抽象化

私たちは、複雑な状況調査の現実を抽象化し、論理的な流れへと落とし込みます。しかし、それを直線的な流れに無理やり押し込めるわけではありません。状態機械としてマッピングします。主要な正常動作経路を特定するだけでなく、代替経路、例外経路、一時停止状態もマッピングします。状態を保持する必要がある箇所と、一括処理が必要な箇所を特定します。この状態機械が、インタラクションアーキテクチャの設計図となります。

iv. インタラクションアーキテクチャ

空間レイアウトを設計します。関連するタスクをグループ化します。密度を決定します。常に表示する必要のある情報と非表示にできる情報を決定します。一括操作パターンを設計します。権限の透明性を設計します。ここで、ステートマシンを具体的なインターフェース構造に変換します。クリックよりもスキャンを優先します。視覚的なスタイルを適用する前に、インターフェースの骨組みを構築します。

v. フィードバックと反復ループ

私たちは、実際の使用環境下でデザインをテストします。ユーザーを無機質なユーザビリティラボに連れて行くことはしません。プロトタイプをユーザーのデスク上で、既存のツールと並べて提示します。そして、日々のタスクの中から実際のタスクを実行してもらいます。所要時間を計測し、ユーザーが無意識のうちにシャドウスプレッドシートに手を伸ばすかどうかを観察します。新しいデザインによってシャドウワークフローの必要性がなくなる場合は、なくなるまで繰り返し改善します。

このフレームワークは、複雑な設計における最もよくある間違い、つまり間違ったワークフローのために美しいインターフェースを構築してしまうことを防ぎます。設計を現実の状況に根ざし、状態、密度、一括操作に焦点を当てることで、最終製品がユーザーの日々のストレスを実際に軽減することを保証します。