デザインシステムの価値: 複雑なシステムに対するデザインと使いやすさの影響

従来のソフトウェア設計方法には問題があります。有用でも直感的でもないが、ユーザビリティ ガイドラインを満たしているシステムを作成することは十分に可能です。通常、新機能のリスト、機能アップデート、およびコンポーネントの要望リストが主要な関係者や代表的なユーザーから収集され、有能な開発チームに渡され、要件を調整し、ユーザーにとって意味のある統一システムを作成するために最善を尽くします。

このようにして、ひどいユーザー エクスペリエンスを備えたソフトウェアが作成されます。

このホワイトペーパーでは、別のアプローチについて説明します。これは、(ウィッシュリストではなく) ユーザーのニーズに根ざした一連の要件から開始し、ユーザビリティ アナリストとデザインの専門家が早い段階から協力して、迅速で安価なモデルを作成するものです。最終的なシステム。このラピッド「紙」プロトタイピングのプロセスにはコードが必要ないため、線を消すのと同じくらい簡単に変更できます。また、プロトタイプをユーザーの前に置いて、要件収集中に生成された概念的なアイデアと画面レベルの使いやすさの両方をテストして、実装された最終製品が使いやすく有用であることを確認する機会も提供します。

車、家、ソフトウェア

車は 1800 年代後半から存在しています。それらは原始的な内燃機関を動力とする機械化された馬車として始まりました。どう考えても、初期の車は乗り心地が悪く、信頼性が低く、危険でした。しかし、当時の成熟した交通手段では不可能なことを実現しました。彼らはより遠くへ、より速く進むことができました。また、オーナー/オペレーターは自分自身の整備士や部品製造者としての役割を果たす必要もありましたが、それだけで十分でした。

住宅は車よりもはるかに古くから存在しています。初期の頃、風雨から身を守ることが、価値のある家を選ぶ決め手でした。雨を防ぎ、風をさえぎってくれれば十分でした。

ソフトウェア、特にエンタープライズ ソフトウェアは、3 つのうちの最新のものです。ソフトウェアは、車や家のような物理的な物体ではないため、特定の形式やサイズに縛られないという点で興味深いものです。ただし、自動車や住宅と同様に、原始的なソフトウェア (人間の対話を必要とする今日のほとんどすべてのソフトウェアは原始的なソフトウェアであると私は主張します) に優れた機能のリストが含まれている場合は、許容されると見なされます。誰でも使えるかどうかは関係なく、そのソフトウェアが以前のバージョン (または競合他社のソフトウェア) よりも多くの機能を備えていれば十分です。

これら 3 つの進化を追跡すると明らかになるのは、複雑なシステムは最初はエンジニアリング イベントとして存在し始めるということです。彼らが機能するだけで十分です。時間が経つにつれて、複雑なシステムはエンジニアリングから個人的なものへと進化します。これはもちろん車や住宅にも当てはまります。しかし、ソフトウェアはまだ十分ではありません。図 1 に示すように、ドン ノーマンは 1999 年の著書『The Invisible Computer』でこのアイデアに言及しましたが、彼はソフトウェアではなくハードウェアについて話していました (Norman, D.、1999: The Invisible Computer を参照)。

製品の進化という観点から見ると、ソフトウェアはまだ若い製品です。これは、依然として使いにくい理由の多くを説明するには十分かもしれませんが、それを受け入れる理由にはなりません。すべてのソフトウェアは、無数の善意の決定の結果です。まさにその通りになるように設計されました。それが問題なのです。すべての製品が適切に設計されているわけではありません。

使いやすさが十分ではありませんか?

企業は、問題のある画面をユーザビリティの専門家に引き渡すことで、貧弱なデザインの問題に対処しようとします。厳格なテストと長年のガイドラインの順守を通じて、全体的な使いやすさは確実に向上します。ただし、複雑なシステムを扱う場合、システムの設計後にユーザビリティを向上させることは、病気ではなく症状を治療することに似ています。それを念頭に置いて、次のセクションでは、このセクションの冒頭の質問に対する答えを提供します。

使いやすさだけでは不十分

新しいシステムの設計にアプローチするには、いくつかの方法があります。最初に、新機能のリスト、機能アップデート、コンポーネントの要望リストが主要な関係者と代表的なユーザーから収集されます。このリストはその後、要件を調整し、ユーザーにとって意味のある統一システムを作成するために全力を尽くす有能な開発チームに渡されます。こうやって恐ろしいソフトウェアが作られていくのです。なぜ？なぜなら、開発者はユーザビリティアナリストやデザイナーではなく、両方の仕事をするよう求められているからです。

2 つ目では、ユーザー調査リーダーが主要な関係者および代表的なユーザーと協力して、両方のグループのニーズと要件を決定します。これにより、より適切な一連の要件が得られます。

これは信じられないほど強力です。ユーザーも利害関係者も、通常、当面の要望リスト以外のことは理解できず、ユーザーが望むものを提供する段階的な改善と、ユーザーが必要とするものを提供するイノベーションの違いは、熟練した要件の引き出しにあります。この新しいシステムは優れた一連の要件に基づいていますが、画面レイアウト、インタラクション モデル、データの視覚化などの問題 (つまり、デザインの問題) は依然として、コア コンピテンシーがデザインではない役割によって決定されています。

3 つ目では、ユーザー調査リーダーとデザインの専門家が協力して要件を収集し、ユーザーが夢にも思わなかった方法で作業を完了するのをサポートする革新的な方法を作成します。ちょっとユートピックすぎるように聞こえますか？それは真実であり、利害関係者、ユーザー、チームメンバーとしてそのような「設計プロセス」に参加できるのは素晴らしいことです。Indigo.Designなどの新しいデザインからコードまでのシステムも、真の UX デザインと開発のコラボレーションを促進するのに役立ちます。

ユーザー調査のリードが、エンド ユーザー自身ですら自分が何を必要としているかを必ずしも知っているわけではないことに気づくことは珍しいことではありません。

ここにその好例があります。多くの金融会社のトレーディングフロアでは、トレーダーのワークステーションに 4 台のモニターが 2 台ずつ、1 つの台座に基本的にトレーダーの頭を包み込むような角度で取り付けられているのを見るのは珍しいことではありません。通常、モニターには、スプレッドシート、折れ線グラフ、スクロール、点滅、色付きのデータ ポイントが複雑に組み合わされて表示されます。トレーダーはデータの表示方法をあまり制御できず、単に他のソースからデータをストリーミングしているだけだと考えるかもしれません。しかし、ある金融会社のトレーダーが「画面上でのデータの表示方法を誰が管理しているのか」と尋ねられたとき、そのトレーダーの答えは驚くべきものでした。私たちはデータとその表示方法を完全に制御しています。」

彼は、重要な情報を強調表示してほしい、あるいは「これらの情報を一日中点滅させないでください」というような単純なことでも言いたいと思うかもしれません。しかし、このトレーダーは、何が仕事を楽にするのに役立つかと尋ねられたとき、彼が持っていたプロセッサは 4 つのモニターしか実行できないため、より高速なプロセッサが欲しいと答えました。もっと高速なプロセッサがあれば、6 個搭載できるでしょう。」

その答えを考えると、ユーザーの視点の限界に気づきます。そうすれば彼らのパフォーマンスは向上しただろうか？経験豊富なトレーダーにとっては、おそらくある程度の段階的な改善が得られたでしょう。しかし、それは彼らが必要としていたものではありません。

ユーザー調査: ユーザーが何を必要としているかを理解する

ユーザーの動作を観察すると、ユーザーが何を必要としているかが明らかになります。なぜ特定の行動をとったのか、なぜ特定の順序で行動をとったのか説明してもらうと明らかになります。ユーザーが何を達成しようとしているのかを理解すると、イノベーションが可能になります。あるタスク中に、トレーダーは特定の金融商品を買うか売るかを決定しようとしていました。これを行うために、彼は、特定の通貨が相互にどのように取引されているか、通貨間の変化率が時間の経過とともに望ましい方向に傾向を示しているか、これを過去の通貨間の変化率とどのように比較するかを知ることに興味がありました。変化率、変化率の変化率、および変化率の過去の比較として。この情報を表現するにはさまざまな方法があります。 1 つの方法には、モニター 6 台分のスプレッドシートと折れ線グラフが含まれます。あるいは、デザイナーは、変化率データを一目で視覚化する 3 つの新しい方法を作成することもできます (それが彼らの得意分野だからです)。ユーザーはこれらの観点から考えることはできません。率直に言って、ほとんどのユーザビリティ アナリストも同様です。

私は、ユーザビリティとデザインの専門家の協力に依存するデザインプロセスの実装を通じて、より進化したソフトウェアの作成が可能であると主張してきました。ソフトウェア開発に伴うリスクも軽減できるとしたらどうでしょうか?また、リスクには通常コストがかかるため、ユーザー エクスペリエンスとデザインによってソフトウェア開発コストを削減できるとしたらどうなるでしょうか?ソフトウェア開発の 2 つの最も著名なモデルを検討する前に、別の逸話を検討することが役立つでしょう。

二人のハリーの物語、あるいは最終結果が期待をどのように満たさないのか

ソフトウェア開発の課題をよりよく説明するために、ハリー・ポッターの本に夢中になった少年たちの経験と、それを大きなスクリーンで見たときの反応を考えてみましょう。ハリー・ポッター映画の最初の作品が公開されるまでに、これらの少年たちはすでに最初の 3 冊の本を読み、映画を見たがっていました。しかし、列に並んでチケット 1 枚あたり 10 ドルを支払い、ソーダ、キャンディー、ポップコーンを購入し、ハリー ポッターの冒険を 90 分間見た後に、興味深いことが起こります。彼らはそれが気に入らなかったのです。

なぜこの動きが気に入らないのかと尋ねると、本と同じではないと彼らは答えた。どうやら、脚本を書いた人も、監督も、俳優も、少年たちが頭の中で組み立てた「映画」と一致しなかったようです。したがって、この映画は残念でした。

これはまさに従来のソフトウェア開発方法の問題です。コーディングは、プロジェクトに関係する全員が、全員の要望、ニーズ、欲望の合計を含む散文ベースの要件文書が、前述の要望、ニーズ、要望を正しく捉えていることに同意したときに始まります。これは、ソフトウェアを作成する 3 つの方法のうちの 1 つ目です (前述)。利害関係者 (およびユーザー) は、使用可能なシステムを作成するために開発者に依存しているだけでなく、すでに頭の中で作成したシステムと一致するシステムを作成することも開発者に依存しています。必然的に、何ヶ月も経ってカーテンが引き戻され、アルファ リリースが公開されると、チームは思い描いていたシステムを見つけるのに苦労します。これに「それは私が期待していたものではありません」というバリエーションが続きます。私の映画の例とこのソフトウェア開発の例の唯一の違いは、少年たちの父親が費やしたのは 40 ドルだけだということです。ソフトウェア プロジェクトはコーヒーにそれ以上の費用を費やしました。

現在の主なソフトウェア設計プロセスは、ウォーターフォールとアジャイルの 2 つです。各モデルは、ソフトウェアが何をすべきかを説明する要件の散文ベースの説明から始まります。それぞれは「リスクの可能性」（私の用語）ゼロから始まります。これは、開発段階の開始時には、誰もが自信を持って満足していることを意味します。何も悪いことは起こっておらず、誰もが最終製品に対する共通のビジョンを共有していると信じています。その後開発が始まり、リスクが増大し始めます。なぜ？なぜなら、製品の最終形態がチームの各メンバーが抱くビジョンから逸脱するような決定が下されているからです。開発チームのせいでしょうか？絶対違う。彼らは、やりたいこと、つまりコードを実行しようとしながら、デザインに関する決定を下す必要があるという不快な立場に置かれています。そして時間が経てば経つほど、リスクはどんどん上がっていきます。

図 2 と 3 に示されているように、これはプロジェクトがウォーターフォール方法論に従っているか、アジャイル方法論に従っているかに関係なく発生します。ウォーターフォールは、ビルドが完了するまで結果が得られないため、2 つのうちのより問題が大きくなります。アジャイルは、ビルドを短いスプリントに分割することで、この問題に対処しようとします。ただし、これでは機能の個別の部分のみを表示できるため、チームはより大きな全体の中でどのように機能するかを想像する必要があります。

どちらのプロセスでも、開発プロセスが完了するまで、チームは最終的なシステムがどのように見えるか、システムがどのように動作するか、他のシステムや他の機能とどのように相互作用するかを確認することはできません。どちらも初期開発コストが高くつきます。すでにコードに実装されている設計上の決定を変更すると、さらにコストがかかります。ユーザーがそのようなシステムを受け入れる可能性は低いです。

一方、図 4 に示す設計プロセスでは、ユーザビリティ アナリストと設計専門家のスキルを調整して、この問題に対処します。

より優れた要件セットの作成 (明らかに、ウォーターフォールまたはアジャイル手法への入力となる可能性があります) に加えて、ユーザビリティと設計の専門家は、最終システムの迅速かつ安価なモデルも作成します。迅速な一連のスケッチ、ワイヤーフレーム、画面モックアップを通じて、チームはシステム全体のビューを提供し、全員が集まり、質問し、合意に達することができます。このラピッド プロトタイピングのプロセスにはコードが必要ないため、線を消すのと同じくらい簡単に変更できます。また、プロトタイプをユーザーの前に置き、要件収集中に生成された概念的なアイデアと画面レベルの使いやすさの両方をテストする機会も提供します。バグが解決され、最終製品について全員が共通の理解を共有したら、開発チームは作業を開始できます。そして、要件に加えて、それらの要件の最終的な視覚的形式を具体的に示すデザインもあります。したがって、開発リスクはコーディングを開始する前に最小限に抑えられ、開発プロセス全体を通じて比較的一定に保たれます。

優れた設計とは、要件を発見して定義するリサーチベースの反復的なプロセスです。ユーザーが何を望んでいるのかだけでなく、何を達成する必要があるのか を理解することができます。これにより、早期の合意形成、変更、ユーザーテストが可能になります。速いですね。安価です。使いやすく、直感的で、美しく、インスピレーションを与えます。リスクが軽減されます。それは漸進的な改善ではなく革新をもたらします。これは既存のソフトウェア開発手法に適合します。スケーラブルでサポート可能です。

ソフトウェアは無限に柔軟な製品です。まったく何にでも成形できます。原材料の入手可能性、輸送物流、工場サポートについて心配する必要はありません。それは意図されたものになります。必要なのは、それを素晴らしいものにしたいという願望とプロセスだけです。

リソース

ノーマン D. (1999)。目に見えないコンピューター: 優れた製品が失敗する理由、パーソナル コンピューターは非常に複雑であり、情報家電がその解決策です。 MITプレス。