タスク指向UIの失敗から学ぶ：Microsoft Inductive User Interface Guidelines

『Microsoft Inductive User Interface Guidelines』（日本語版）というものがあります。このガイドラインの方針に従って作った場合、出来上がるのは典型的なタスク指向UIです。タスク指向UIを作るケースの多くは、それを良いものだと思って作るはずなので、このガイドラインの失敗を知ることは非常に重要です。（特にガイドラインの前半だけ読むと、何かもっともらしいコンセプトのように感じてしまうかもしれませんが、要注意です。実際のデザインと照らし合わせて、しっかりと内容を読み込む必要があります。）

この資料で悪いものとして最初に挙げられるのは次のような画面です。

ガイドラインの書き手はこの画面に対して、「どうすれば良いのか？」「いつ終わったのかどうやって知るのか？」という課題があると認知しているようです。

まずこの画面はどういった画面かを見ていきます。

ウィンドウタイトルが「Properties」なので、なんらかの画面のPropertiesを選択して表示された画面のようです。保存とキャンセルがあるので何らかのモードが発生しています。ウィンドウの中には、Thingsの空のリストが表示されているようです。RemoveやPropertiesボタンがディスエーブルになっています。

おそらくAddによってThingを追加すると、RemoveやPropertiesというボタンがイネーブルになるのだと思います。Propertiesボタンは、選択したThingの詳細情報が見れるのだと思われます。

このウィンドウのタイトル自体も同様にPropertiesなので、このウィンドウ自体も何らかの詳細情報を表示するためのウィンドウなのかもしれません。

本来的には、ウィンドウ内にThingsしかないのであれば、このウィンドウ自体のタイトルはThingsである方がわかりやすいと思います。

見る目とアイデアの不足

さて、「どうすれば良いのか？」という疑問はどこから来るのでしょうか。前提として、ユーザーは自分でこの画面を開いているので「Things」には興味があると考えるのが自然です。どうする以前にこの画面に興味があって確認したいから開いているわけです。

ガイドラインではこのダイアログの操作方法について「カジュアルなユーザーは推測する必要がある」と問題視していますが、そもそもユーザーはGUIをイディオムとして学習して使っています。また、リスト表現は多用されているため、既にその振る舞いを学習していることも多いでしょう。

また、推測する必要があると指摘する一方で、このガイドラインで改善したとされる画面でも、学習することで使えるようになるGUIコンポーネントを数多く使っているので、論点自体に一貫性がありません。仮にこの主張を徹底したらどのような形になるのかが全く記載されておらず、不明瞭です。

保存、キャンセルはこのウィンドウ自体のモードに関するボタンです。リストとは直接的な関係がないので省略してみます。そうすると、現在、同じようなリストの画面を作るとしたら以下のようになりそうです。

データが0件なので、イメージがしにくいという課題なのでしょうか。そういった課題に対しては、ステータスとガイドを表示する方法もあります。例えばSwift UI では、ContentUnavailableViewを用いることで以下のように作ることができます。他にも可能であれば、テンプレートとしてデータを用意しておく方法もあるでしょう。

また、ガイドラインには「Thingsはヒントとして曖昧」、「一部のユーザーは、リストボックスが編集可能なテキストボックスに見えるので入力しようとする」といった指摘もありました。

1つ目の「Thingsはヒントとして曖昧」は、ヒントが足りないというよりも、そのものを表す名称に変えれば良いのです。例えば、本来「生徒」であるべき名称を「Things」にしていればわからなくなるのは当然です。ヒントではなく、Thingsを「生徒」という名称に変更することが重要です。

Thingsそのものへの説明をつけるのであれば、1つ前の画面にあるのが自然です。なぜならば、本当にその言葉の意味がわからないのであれば、この画面を開くはずがないからです。項目内に捕捉的なキャプションをつける方法や、iOSの設定アプリのようにセクションフッターなどでガイドを表示する方法があります。

また、「リストボックスが編集可能なテキストボックスに見える」といった指摘も、Microsoftのコンポーネントの問題、もしくは適切なコンポーネントが選択されていないため、イディオムとして学習しにくい、といった問題です。

出発点となるデザインに対する見る目とアイデアがなければ、最初からあらぬ方向へ向かってしまうことがあります。

ガイドラインでは「Inductive User Interface」は「根本的な変更を加えてソフトウェアを簡素化することは、既存顧客をより完全に満足させ、新規ユーザーを引き付ける強力な方法」と説明されていますが、そういったデザインができたのかを、画面案を丁寧に見ながら確認していきます。

クリック数を減らすことだけを指標にしても意味がない

示される方針の中に「各画面を単一のタスクに」というものがあります。機能を複数の単一のタスクへと分解し、それぞれに各画面を用意する、OOUI的な知識を持つ人からすると真逆の方向性です。

では、これは一体どんな画面になるのでしょうか。

ガイドラインでは非常に興味深い例が示されています。Money99というアプリと、それを「Inductive User Interface」にしたとされるMoney2000です。

残念ながら画像の細部が確認しにくいのですが、UIデザインの話なので可能な限り観察する必要があります。画像がない箇所については、Money2000の日本語版のガイドブック『ひと目でわかる MONEY2000 (マイクロソフト公式解説書)』を参考にしました。

Money99では、1つの画面でできる口座の作成、閲覧、削除を、Money2000では、わざわざ3つの画面に分けています。「閲覧画面は口座選択に特化しているので、1クリックで済む」ことをメリットとして挙げていますが、「新規作成」と「削除」はクリック数が増加しています。以下は簡略化し比較したものです。

実は、Money99の画面を大きく変えなくても、複数のクリック可能なエリアを設ければ、閲覧アクションも1クリックで実行することは可能です。選択アクション用エリアと閲覧アクション用エリアを分ければいいのです。その場合は以下のようになります。

同じように、削除ボタンを設ければ、削除も1クリックで実行できます。

ただし、クリック数を減らすことだけを指標にしても意味がありません。理由はシンプルで、全てのアクション用にボタンを用意すれば、最も少ないクリック数で実行できるようになりますが、大量のボタンが必要になってしまうからです。レイアウトスペースや認知負荷を考慮しながら進めることが必要なのです。

迷走する「1タスク1画面」

ガイドラインでは画面タイトルの観点でMoney99とMoney2000を比較しています。Money99では「Upcoming Bills & Deposits」だったタイトルを、Money2000では「Click the bill you’d like to pay」へ変更したとしています。

この変更によって、「Deposits」に関する表記が無くなり、そこに何が表示されているのかが、わかりにくくなってしまいました。作り手はそこでやって欲しいことを指示したつもりかもしれませんが、ユーザーからすれば、目の前に表示されたものが何なのかを認知する前に、指示をされているのです。

ほかには「口座マネージャー」という画面のタイトルを「口座を選ぶ」と「口座を設定する」に変更したとあります。口座マネージャーの機能を分割したことでかえって複雑になっています。分割せずにタイトルを「口座」に変更すれば十分なはずです。

不思議なことに、本来「1タスク1画面」にする場合、「口座を新規作成する」「口座を削除する」「口座の名称を変更する」「口座の金融機関を変更する」「口座の番号を変更する」「口座の残高を変更する」など非常に多くの画面タイトルが必要になるはずですが、表には記載されていません。

「口座の詳細」を「口座の設定を変更する」というタイトルに変えた点は記されていますが、ユーザーは口座を変更するかどうかの前に、普通は口座の詳細を確認します。つまり、ここでも「口座の詳細を確認する」というタスクが不足しています。

また、どのタスクを主に表示するのかに関しては恣意的で、ユーザーにとっては機能を探しにくくなってしまっています。例えば、Money2000の口座機能においては、「閲覧」とは全く別の「口座の設定」の中に「削除」があるので、閲覧中の口座を削除することが困難になっています。

さらに、画面上部にはナビゲーションが配置されているようにも見えます。1タスク1画面であれば最上位のナビゲーションからタスクを並べる必要があるはずです。しかし、画面を見る限りでは「Accounts」や「Bills」「Investing」になっています。

このようにコンセプトでは「1タスク1画面」によるメリットを強調し説明していますが、実際には行き当たりばったりで、徹底されていないので、結局どういったデザインになるのか考え抜いてないようにも見えます。

ガイドラインの後半に紹介されている、テストのために作られたという画面でも「Add and remove column」や「Change alignment and formatting」だと思われるタイトルがあり、1タスク1画面にできていません。

ユーザーが構造を学習することすら困難

また、Money2000のガイドブックを読んでみると、実は「使う口座を選択する」画面では、右クリックメニューによって口座をその場で削除できることが書いてあります。「使う口座を選択する」タスクだけに絞ったはずの画面なのに、実際には削除ができるということです。

このやり方だと、例えば「〇〇を売る」という画面の中に「〇〇を買う」「〇〇を削除」など画面名と無関係の機能が存在する可能性が出てくるので、ユーザーが構造を学習することすら困難になってしまっています。

なぜこのような構造になってしまうのかというと、結局は目の前にあるオブジェクトに対して、その都度アクションを取りたくなるからです。

デザインと整合しないコンセプト

コンセプトを製品版に完全に反映できなかった可能性はあるものの、例として挙げているデザインや、テストに用いている画面例を見ても、掲げていた「根本的な変更を加えてソフトウェアを簡素化すること」にはつながらず、「1タスク1画面」のコンセプトと照らしても、定義されるべきタスクが大量に不足しています。

さらに、タスクとは無関係なアクションを行えるような製品になっており、自らコンセプトを否定しているようにも見えます。実際のデザインの方が先で、後付けでこのコンセプトを掲げたとしても、デザインとの整合性がありません。形に関するコンセプトである以上、形とのつながりがあるどうかは非常に重要です。