Microsoftのコアコンピタンス
開発のコアコンピタンスとしてのユーザビリティ
−実用的で使いやすく、魅力的にー
認知点視点：
デザインの重要性を説くために、時として "エレベータ スピーチ" が必要になることがあります。この言葉を聞いたことがない方のために説明すると、エレベータ
スピーチとは、オフィス ビルのロビー フロアから 10 階に上るまでの間に行うことのできる簡潔な説明のことです。私は普段、「ユーザー エクスペリエンス
デザイナとしての私の仕事は、実用的で、使いやすく、魅力的な対話型製品をデザインすることです」と言うようにしています。"実用的で、使いやすく、魅力的な"
というフレーズは、私にとって非常に思い入れのある表現です。私たちがあらゆる開発プロジェクトで求めている成果をよく表しているためです。
私たちが開発するほとんどすべての対話型製品は、アプリケーション、ゲーム、Web サイト、モバイル デバイスなどの種類を問わず、何らかの形のツールです。
実用的でなければ、適切なツールとは言えません。実用的な製品を作成することは、開発コミュニティの当初からの基本的な目標であり、要件を把握および文書化するための最適な方法を明らかにするために、数々の妙案が考え出されてきました。ただし、ツールを正しく動作させることは、その実用性を高める取り組みの一部にすぎません。（Dr. Charles B. Kreitzberg）
ユーザビリティは単なる表層の要素ではない：
開発者は、ユーザビリティを製品のスキンの問題としてとらえがちです。確かにユーザビリティのいくつかの側面はビジュアル デザインと関係がありますが、その大部分は表面に現れるものではありません。
Alan Cooper 氏は、14 年前に著した自著『About Face』の中で、2 つのソフトウェア モデルを区別しています。それはテクニカル
モデルとマニフェスト モデルで、これらのモデルを通じて "ソフトウェアの機能がユーザーに示される" というわけです。私はマニフェスト
モデルよりも UI モデルという用語の方が好きですが、どう呼ぼうとも、テクニカル モデルとは重要な違いがあります。
テクニカル モデルは、オブジェクト、メソッド、アルゴリズム、データ構造体などのアイテムから構築されますが、UI モデルはタスク、ユーザー、およびビジネス オブジェクトに基づいて構築されます。テクニカル モデルと UI モデルのバランスが重要なのは明白です。しかし、当然のことながら、開発者はテクニカル モデルを好み、これに偏りがちです。結果として、ほとんどの開発環境で正式な UI モデルが確立されません。代わりに開発者は基本的なフレームワークを使用することにし、UI は画面のコーディング時にその場しのぎの方法で構築されています。
ユーザーの立場に立ったデザインを開発プロセスに取り入れた場合、開発者 (とチームの他のメンバ) はユーザーに関する情報を集め、製品の UI モデルを構築することになります。
ワイヤーフレーム：
通常、概要デザインは、ワイヤーフレームとスタイル ガイドを使用して提示されます。ワイヤーフレームは、画面の外観とユーザーによる画面の操作方法を示す図です。スタイル
ガイドは画面の構成に関する規則を記載したドキュメントで、コントロールの配置、ラベルの基準、色、フォントなどの問題が扱われます。また、データ表示に関する規則もまとめられます。スタイル
ガイドは、すべての画面で要素の一貫性を確保するために利用されます。
マスタ ページを使用すると、一貫性のあるフレームワークを作成し、操作の方法を示すための限定的な機能を組み込むことができます。本物のような外観と機能を持つ
UI プロトタイプを作成可能です。プロトタイプに多くを求めないことが重要です。UX デザインでのほとんどの要素と同様に、ワイヤーフレームにも繰り返し手が加えられます。初期段階のワイヤーフレームは骨組みです。ユーザーの情報や要件をつかんだ後で、詳細を追加してください。多くの開発者の傾向として、プロトタイプの作成段階でワイヤーフレームに手を加えすぎです。初期段階で構築するのは概要デザインであることを忘れないでください。おそらく、データベースやデータ検証は必要ないでしょう。UI
プロトタイプの目的は、動作する製品のダミーを作成することにあります。実際のコードの初期イテレーションではありません。
この段階で作成する UI プロトタイプのことを主要画面プロトタイプと呼んでいます。このプロトタイプは、主要な (つまり基本の) 画面、ナビゲーション
フロー、および情報アーキテクチャを示す目的で使用されるためです。
主要画面プロトタイプの使い道は 3 つあります。
第 1 の用途は、プロジェクトに関与するすべてのメンバが同じページ上で作業していることを確認するための、コミュニケーション ツールとしての用途です。ソフトウェア
プロジェクトの足かせとなる多くの問題は、開発チームとビジネス クライアント間のコミュニケーション不足や見解の相違に端を発しています。開発者は、了解事項に対する顧客の理解力を過大評価しがちです。その結果、プロジェクトの遅い段階になるまで問題が見過ごされ、対処に必要な手間とコストが増えることになります。開発サイクルの初期に製品のモデルを提示できれば、製品の外観と振る舞いを関係者に明確に示すことができます。
レビュー セッションで関係者にワイヤーフレームについて説明する際には、タスク フローの観点から示すのが最適です。画面を提示して参加者に意見を述べてもらうと、生産的ではない、場当たり的な意見が多数出される傾向にあります。そこで、私はユーザーが主要なタスクをどのような流れで実行するかを説明するようにしています。その後で、信頼の置けるパートナーと一対一で詳細について話し合います。
ビジュアル デザインの扱いを決めることは重要です。ビジュアル デザインが気に入らないとデザインの他の側面にも批判的な評価をしてしまう、そういった関係者がいると困るという理由で、ワイヤーフレームを骨格のままにして関係者に提示するデザイナもいます。私はというと、初期段階では、骨格だけのワイヤーフレームを使用します。そしてビジュアル デザインを示すために、別の画面を作成するようにしています。ただし、ビジュアル デザインについて了解が得られたら、それをワイヤーフレームに組み込み、できるだけリアルな UI プロトタイプを作成しています。
１・２