はじめに
古代都市の交通システム構築を任された都市計画担当者を想像してみてください。その都市は整然とした格子状ではなく、長い年月をかけて自然発生的に広がってきた街です。そこには、隠れたトンネルや最適とは言えない入り組んだ道路が数多く存在しています。直感的な交通システムを新しく構築するには、住民にどこに行きたいか尋ねるだけでは不十分です。まずは都市の既存のレイアウトを理解する必要があります。これが、エンタープライズ製品設計における課題です。フードデリバリーアプリのような消費者向け製品は、誰もが理解している概念の上に構築されています。一方、エンタープライズ向けのシステムにおけるユーザー環境は、レガシーソフトウェア、隠れた依存関係、明文化されていない慣習によって形づくられた、抽象的で直感的とは言いにくい「都市」のようなものです。
ダブルダイヤモンド設計フレームワークは、それ自体ではこの複雑さを十分に捉えきれません。ユーザーを理解するように正しく導いてくれる一方で、そのユーザーを取り巻く環境の理解は暗黙の前提として扱われています。これは、よりシンプルな環境においては有効な手法です。しかし、その焦点を明確に打ち出していないため、複雑なシステムがユーザーの環境を定義するエンタープライズ領域では、盲点が生じてしまいます。エンタープライズの問題を根本から解決するには、デザイナーは地図製作者となり、抽象的なシステムを明確で理解しやすい地図に変える必要があります。以下は、構想段階でさまざまな製品コンポーネントを可視化するために作成された、初期の概略的なマップの例です。
システムマップの作成 - デザイナーにとっての強力な武器
デザイナーにとって、システム全体をマップに描き出すことは、回り道ではなく、むしろ近道です。デザイナーが提供できる独自の価値とは何か、そして設計プロセスの早い段階でシステムをマッピングすることで、いかにソリューション全体の精度と有効性を高められるかを見ていきましょう。
無秩序から明確な構造へ
エンタープライズにおけるディスカバリーフェーズでは、通常、構造化されていない膨大な量の情報に囲まれることになります。これは、APIトークンの使用フローにIP制限を追加したプロジェクトの例です。私たちのディスカバリーフェーズは、次のような無秩序な状態からスタートしました。
従来の成果物は、ユーザーデータを整理・統合するうえでは有効です。しかし、エンタープライズシステムの複雑さを克服するには、システムマップでユーザー環境を表現する必要があります。それによって、抽象的なシステムが、目に見え、理解できるものへと変わります。システムマップを作成することは、たとえそれが自分のためだけに描き出した大まかなものであっても、ユーザーが実際に向き合っている複雑な状況をより深いレベルで捉えることにつながります。先ほど触れたプロジェクトでは、トークンの発行元に基づくライフサイクルという形でマップを作成しました。その結果、「トークン」「ディレクトリエージェント」「API」といった抽象的な概念が、具体的で視覚的な対象として扱えるようになりました。
問題を「ユーザー」と「システム」のコンポーネントに分解し、それぞれに対して異なるアプローチを取ることで、設計プロセス全体を加速させる二層的な理解が生まれ、より焦点の定まった設計ソリューションへとつながります。
エンジニアではなく、システムを可視化する地図製作者としてのデザイナー
これはエンジニアリングチームやPMがやるべきことではないか、と思うかもしれません。確かにエンジニアリングチームやPMも図を作成しますが、その目的は本質的に異なります。エンジニアリング図は、正確性を最優先に、可能な限り詳細を捉えることを目的としています。例えば、都市の基盤となる公共設備や信号機、構造設計図を正確に記録し、設計どおりに建設するために作成するわけです。それは、市民が目にする標識や、利用できる道路・近道を可視化することとは大きく異なります。ここでの主眼は、ユーザーが活動する環境としてシステムを可視化することにあります。ここに、デザイナーとしてのユニークな役割があります。システムの概念を、それを販売する上での説明やバックエンドでの構築方法としてではなく、ユーザーがどのように体験し、意味づけるかという観点から可視化することです。
システムマップの活用
システムマップを作成したら、それをどのように活用し、抽象的な理解から具体的な設計上の判断へと結び付けていけばよいのでしょうか。重要なのは、一歩下がって全体像を捉え、そこにユーザーのインサイトと共感というレイヤーを追加することです。システムマップは、ユーザーからのフィードバックを実行可能な設計変更に変換するために必要な、構造的なインテリジェンスを提供します。これは、2つの重要なディスカバリーの流れを統合することで、インサイトのプロセスを形式化します。
I) エンタープライズの実態を簡素化し、問題を定義する
システムマップは、システムに関するインサイトの基礎となります。システムとユーザーについての理解を組み合わせ、価値あるインサイトに結び付けるために、さまざまな設計段階で自問できる実践的な質問をいくつか紹介します。
A. ユーザーにとって中核となるメンタルモデルの定義：
- ユーザーが理解しておくべき、システムの「中核的な概念」にはどのようなものがあるか。都市に例えるなら、何が建物で、何が道路にあたるか。
- 本来重要な概念が隠れてしまっていないか。
- 本来は異なる2つの概念が1つのものとして表れていないか。あるいは逆に、統合できる概念はないか。
B. ワークフローと情報アーキテクチャの最適化
- ユーザーのワークフローとタスクを考慮したうえで、システムの基盤となる概念がインターフェース全体に分散しすぎていないか。新しい道路は必要か。
- 現在のワークフローは直感的か。それともよりシームレスなワークフロー（例えば、現在ドキュメントを通じてのみ接続されている概念を結び付けたり、表面化したりするなど）に再構成できるか。
- システムマップで接続されている概念は、同じ製品内の別の領域と類似しているか。それとも、まったく別の製品に近いものか。成功したパターンやフローを応用できるか。
C. インタラクション、コピー、コントロールの微調整
- システムの基盤となる概念は、ユーザーにとってわかりやすい階層構造でUI上に提示されているか。見落とされている道路標識はないか。
- 現在ユーザーに提示されているコントロールは、その目立ち方に比べて重要度が低すぎないか。逆に、高度なコントロールが過度に強調されていないか（複雑さを隠すことで簡素化できる余地はないか）。
- ユーザーに提示されているコントロールは、隠れたシステム依存関係と結びついていないか。その依存関係について、ユーザーが理解できるだけの背景情報は提供されているか。
このように、システムマップは、設計のスケール全体を明確に把握するための強力なツールです。不確実性が高い段階でシステムの大枠を定義することから、ワークフローを簡素化し、設定が多すぎてわかりにくいといった細かなUIの課題を解消することまで、幅広い設計判断を可能にします。
II) インパクトとビジョンを生み出すためのコラボレーション
システムマップは、組織全体にとって有力な資産となります。その最大の価値は、複雑な問題に対して共通かつ一貫した視点を生み出し、それによって製品全体の意思決定をより良いものへと導く点にあります。これを活用し、以下のような方法で、リーダーとして組織を牽引することができます。
A. 連携を強化し、負債を防止する
プロダクトマネージャー、デザイナー、エンジニア、品質保証、テクニカルライターからなる部門を超えたチームにとって、マップは、共通理解への近道となります。設計と連携における唯一の信頼できる情報源として機能することで、社内の調整ミーティングを効率化し、コストのかかるやり取りを減らします。
- ビルドに伴うリスクの軽減：このマップは、技術的負債や設計上の負債に対する有力な防御策となります。ユーザーにとって重要なシステム上の接続や依存関係を早い段階で明らかにすることで、リリース後に多大なコストを伴う作り直しが必要となるような、整合性に欠けるユーザー体験をリリースする前に、設計段階でそれらに対処できます。
- 引き継ぎの円滑化：UIでの具体化に向けてコンセプトを引き継ぐ際に、システムの実態に対する共通理解がチーム全体で確立されているため、土壇場で想定外の問題が発生する可能性を最小限に抑えることができます。
B. ビジョンを共有する
このマップを活用することで、システムの今後の発展や戦略を方向づけるうえで必要な見通しが得られます。
- 作業範囲の定義：マップを活用して、すでに適切に設計されている領域と、最低限しか機能しておらず、UXの重点的な見直しが求められる領域とを見極め、共通認識を形成します。
- 進化の管理：将来的に進化する可能性が最も高い、または進化させるべきシステムコンポーネントを特定します。この共通理解によって、チームは小規模で局所的なUI改善と、フレームワークレベルでの戦略的対応が求められる施策とを適切に区別できます。
- 組織全体への情報提供：このマップは、今後の方向性やビジョンをより広く共有するうえで、説得力のある補助資料となります。これにより、直属のチームだけでなく関連チームも含めて、ユーザー中心で一貫性のあるエンドツーエンドの体験の構築に注力できます。
例えば、IP制限プロジェクトでは、チームとのコミュニケーションを効果的に行うためにこのマップを活用しました。管理者ユーザーに関する私の理解とシステムマップを組み合わせ、PMとともにコンセプトをブレインストーミングし、ソリューションを視覚化し、その影響をチームに伝えました。以下の図は、マップが初期の調査段階から認識のすりあわせを経て最終的なソリューションに至るまで、どのように発展していったかを示しています。
おわりに
エンタープライズシステムは規模が大きく複雑で、技術的負債や設計負債が生じやすい環境でもあります。ダブルダイヤモンドは重要な指針ではあるものの、それだけでは、特に経験の浅いデザイナーの場合、エンタープライズの抽象的な構造の中で、方向性を見失ってしまう可能性があります。
解決策は、地図製作者になることです。
システムマップの作成は、混沌とした情報を実用的な資産に変えるために、欠かすことのできない重要なステップです。このマップは、個人のプロセスを改善するだけでなく、共通認識の確立、ビルドに伴うリスクの低減、そして明確な製品ビジョンの共有に必要な唯一の信頼できる情報源として、チームの成果創出までの道のりを大きく短縮することができます。
ソリューションがUIの無秩序な肥大化を招くことにならないように、根底にある複雑さに振り回されるのではなく、これを的確に捉えることで、現実に根ざした設計プロジェクトを推進していきましょう。
システムマップの活用が、より良い設計への第一歩となることを願っています。
システムマップ作成を実践に広げたい方へ
ここで説明した原則を実践に移したいという方は、システムマップにはどのような具体的な形式や構造があるのか、それを実践でどのように活用できるかについて、さらに理解を深めていただくことができます。詳しくは、OktaのチームメンバーであるShiweiのブログ記事をぜひご覧ください。
