スクリーンデザインに先立つ要求事項の明文化が、どれだけシステムをモーダルなものにしてしまうかということを、僕はSEを対象にしたUI研修の講師の仕事を通じて思い知らされました。
例えば、UIデザインの実習として、よく次のような課題を出します。
■次の要件を満たすUIを考えて下さい：
- 通貨換算を行う画面です。例えば、「128USドルを円に換算するといくらか」、といったことを調べるのに使います。
- 扱える通貨の種類は「USドル、円、ユーロ … 」など特定の10種類です。
- 続けて色々な通貨の組み合わせで換算しやすいようにしてください。
このような課題に対して、まず、それなりに論理的で無駄の無い画面をスケッチできるのがだいたい受講者の半数です。半数は、操作の順序とレイアウトが合っていなかったり、明らかに重複する入力を強いていたりしていて、論外です。
半数の妥当なデザイン案のうち最も典型的なのは次のようなものです。
一番左に数字を入力するテキストボックスがあり、その右に通貨選択のドロップダウンがあります。その右にまた通貨選択のドロップダウンがあり、その右にボタンがあります。
最初のテキストボックスとドロップダウンで換算前の金額と通過を指定し、その右のドロップダウンで換算後の通貨を選択し、そしてボタンを押すと、換算結果がその右もしくは下に表示されるという感じです。ひとつ目のドロップダウンの右に「を」というラベル、ふたつ目のドロップダウンの右に「に」というラベル、ボタンには「換算」というラベルをつけて、
［ ］［ドル▼］を［円▼］に【換算】＿＿＿
という風に、いわゆる「穴埋め式」にします。
このデザイン案は、特に大きな問題も無くそれなりに妥当だとは思いますが、一度換算をした後に続けて次の換算をしやすくするための工夫に欠けています。またそれ以前に、「複雑性の移動」が試みられていません。
ラリーテスラーの「複雑性保存の法則」が言う複雑性とは、要するに目的を達成するために入力しなければならない情報量のことです。この課題の場合、任意の金額と通貨で換算を行うためには、「換算前の金額」「換算前の通貨種類」「換算後の通貨種類」「換算実行の合図」という入力情報が必要です。上記のデザイン案は、これらを行うコントロールをただ並べたにすぎません。
複雑性は減らすことができないわけですから、操作性を高めるためには、複雑性の一部をユーザーサイドからシステムサイドに移動してやる必要があります。
ひとつの模範回答は、Mac の Dashboard にある単位換算ウィジェットのUIです。
ふたつのテキストボックスが左右に並んで配置されていて、それぞれのすぐ上にひとつずつ通貨選択のドロップダウンがあります。左右のテキストボックスの間には「=」というラベルがあります。
［ドル▼］ ［円▼］
［ ］＝［ ］
例えば左側のコントロールで換算前の通貨選択と金額入力を行い、右側のドロップダウンで換算後の通貨を選択すると、右側のテキストボックスに換算結果の金額が入ります。四つのコントロールのいずれかを変更すると、反対側に結果が反映されます。実行ボタンは無く、選択やタイプに応じてインクリメンタルに計算され、UIに反映されます。
このデザインが秀逸なのは、まず、手間が少ないことです。入力コントロールが出力コントロールを兼ねているため、換算結果をそのまま次の換算の入力とすることができます。それから、決められた操作の手順というものが無く、モードレスであることです。どのように操作しても、左右のオブジェクトが常にイコールになるようになっており、「入力内容をメモリにバッファしてサブミットする」というシーケンシャルなフローを排除することに成功しています。もはやそこでは、「通貨を換算する」というタスクはデザインに対して拘束力を持たず、「左右のオブジェクトが互いにイコールになろうとする」というオブジェクト同士の静的な性質があるだけです。ユーザーはその性質を利用しながら自由な方法で目的を達成できるのです。
こういうモードレスなデザインをスケッチできる人は、全体の1割ぐらいです。
更なる模範回答があります。こういうものです。
通貨の種類の数だけ、つまり10個テキストボックスが縦に並んでいて、それぞれの左には通貨名のラベルがあります。それだけです。いずれかのテキストボックスに金額を入力をすると、上記の単位換算ウィジェットと同様にインクリメンタルに計算が実行され、残りの9個のテキストボックスに一斉に換算結果が入ります。
ドル［ ］
円［ ］
ユーロ［ ］
・
・
・
このデザイン案では、入力コントロールが出力コントロールを兼ねると同時に、換算後の通貨選択という操作すらも無くしてしまっています。一度に見せる通貨は換算前後の一対だけでなくてもいいわけなので、常に全部見せてしまうのです。目的を達成するのに必要な「換算前の金額」「換算前の通貨種類」「換算後の通貨種類」「換算実行の合図」という入力情報のうち、「換算後の通貨種類」と「換算実行の合図」の入力は不要になりました。複雑性の約半分がユーザーサイドからシステムサイドに移動したのです。そして「換算前の通貨」を選ぶための操作は、入力するテキストボックスの選択という操作に同化されているので「モードレスモード」であり、課税的な手続きを発生させません。
このデザイン案の欠点は、扱う通貨の数だけ面積を多く必要とすることです。通貨が50種類もあれば使いにくくなるでしょう。ただしあらかじめ通貨の数が10と決められているならば、またそれだけの面積を使えるならば、ベストなデザインだと思います。
ここまでのデザイン案に到達できるのは、全体の1%ぐらいです。ほとんどの設計者は、明文化された要件の中から「必要な入出力情報」を抽出し、それを「操作の手順」としてリニアライズしようとしてしまいます。その結果出来上がるのは「穴埋め式」のようなミニウィザードです。しかしUIをモードレスにするためには、「必要な入出力情報」を抽出した後は、「複雑性」の一部をシステムサイドに移動するような「オブジェクトの性質」を検討しなければならないのです。
もうひとつ、別な課題の例を挙げてみます。次のような課題です。
■次の要件を満たすUIを考えて下さい：
- 営業支援のための業務アプリケーションです。営業マンが自分の販売実績を照会するのに使います。
- この会社では20種類の商品を販売しています。商品は5つの商品カテゴリーに分類できます。
- このアプリケーションを使って、営業マンは次のことを行います：
- 過去の特定年月における、自分の売上金額を知る。（例：2009年3月の自分の売上額合計はいくら？）
- 過去の特定年月における、自分が売った商品の売上順ランキングを見る。（例：2007年11月に自分が一番売った商品は何？ ニ番目は？）
- 過去の特定の年月において自分が売った、特定カテゴリーに属する商品の種類を知る。（例：2005年1月に売った商品の中で、カテゴリーAに属する商品は何と何？）
- 営業マンは事前にログインするので、システムはそのユーザーが誰かを知っていることとします。
このような課題に対しては、ほとんどの受講者がモーダルなデザインを考えます。課題の出し方も若干誘導的ではあるのですが、上記の 1, 2, 3 を互いに独立した「タスク」と捉えてしまうのです。
最悪の（そして最も典型的な）デザイン案は次のようなものです。
まず初期画面にメニューらしきものがあり、「売上金額照会」「商品ランキング照会」「カテゴリー別販売商品照会」といった上記 1, 2, 3 に対応する項目が並んでいます。「売上金額照会」を選択すると画面遷移し、年月を指定するコントロールが表示されます。年月を指定すると画面遷移し、その月の売上金額が表示されます。
初期画面で「商品ランキング照会」を選択すると、画面遷移し、年月を指定するコントロールが表示されます。年月を指定すると画面遷移し、その月のランキングとして20個の商品名が売上額順にリスト表示されます。
初期画面で「カテゴリー別販売商品照会」を選択すると、画面遷移し、年月を指定するコントロールとカテゴリーを選択するコントロールが表示されます。年月とカテゴリーを指定すると画面遷移し、条件にマッチした商品名がリスト表示されます。
— このようなタスク指向のデザインでは、大抵、作業が複数のウィザードに分かれていて、同じ機能を持つコントロールや「似ているけど少しずつ違う」ビューがウィザード間に散在しています。1, 2, 3 のタスクにぴったり沿ったUIではあるのですが、全体のまとまりや合理性が欠如していて、不自然な感じがあります。また画面数も多くなり（7画面）、作業の繰り返しや他の作業への移動がしにくくなっています。
この課題に対して僕が示す模範回答は次のようなものです。
画面中央には、一覧表示のためのテーブルを配置します。その上には、年月を指定するドロップダウンとカテゴリーを指定するドロップダウンを並べて配置します。カテゴリー選択ドロップダウンのデフォルト値は「全てのカテゴリー」です。指定した年月とカテゴリーにマッチする商品が、売上額順にテーブルにリスト表示されます。テーブルの下には、リスト表示された項目の合計売上金額が表示されます。
［2009▼］年［3▼］月 ［全てのカテゴリー▼］
━━━━━━━━━
1：商品G – 347,200円
2：商品O – 328,600円
3：商品D – 287,500円
4：商品A – 239,700円
5：商品M – 164,600円
・
・
・
━━━━━━━━━
合計 21,650,000円
この模範回答では、1, 2, 3 を個別のタスクとしては捉えず、「あるオブジェクトの性質を利用してユーザーが行えること」として捉えています。この場合オブジェクトとは「商品の一覧」であり、その性質として、「年月で検索される」「カテゴリーでフィルタリングされる」「売上額順にソートされる」「合計売上金額を表示する」ということを想定しています。「商品一覧」というオブジェクトにこれらの性質を与えることによって、明文化された全ての要求を満たすことができます。
こういうモードレスなデザインができる人は、全体の1%未満です。
このデザイン案では、要件として明文化されたこと以上のことができます。例えば特定カテゴリー内でのランキングを見たり、その売上合計金額を知ることができます。要求全体をひとつのシンプルな世界観にまとめるためには、このような「要件として明文化はされていないけど出来てしまう事」を出来なくする方が難しいのです。これはむしろ、要件が持っていた「いびつさ」をデザインが矯正したと言えます。要件に対して過不足の全く無いデザインを無理に作っても、シンプルな世界観に落とし込めないのなら、それはユーザーにとっても理解しづらいものである可能性が高いのです。多少要件を拡大解釈することになっても、この模範回答のように、それによってデザインをシンプルかつ合理的にできるのであれば、そうするべきなのです。結果的に、画面数は1になっているのです。
複雑性をシステムサイドに移動させるには、UIをモードレスにして、「タスク選択」という課税的な操作を「オブジェクト選択」の操作に同化させてしまうのが有効です。そのためには、明文化された要求事項から「タスクの手順」を探るのではなく、「オブジェクトの性質」を探らなければならないのです。そして、出来上がったデザインが事前に定義した要件と異なるスコープを持っていたとしても、結果的にそれが役立つなら、それを受容するべきなのです。何かをデザインとは、そういうことではないでしょうか。