優れたユーザーインターフェースやインタラクション、ひいてはプロダクト／サービスをデザインするためのメソッドとして、UCD や HCD と呼ばれるものがあります。いずれもおおよその考え方を示すもので、プロセスの詳細やアウトプットが厳密に標準化されているわけではなく、作業レベルでは色々な方法論が提案されています。
プロセス上の一般論としては、まずユーザーの要求を如何に発見するか、ということが課題になります。ユーザーは自身の要求をデザイン要件として明文化できないので、それをユーザビリティエンジニアが観察なりインタビューなりを通じて明文化しようというものです。
次に、抽出された要求事項をシナリオなりにして、タスクとして構造化します。そのタスクを手がかりにしてユーザーインターフェースを作ります。
ただし、普通ユーザーインターフェースは一度で良いものが作れないので、プロトタイプによるテストを繰り返してブラッシュアップしましょう、という流れになります。
このように、テストによって問題点を潰し、求められる機能を付け足していったデザインは、使っていて何となく分かるものです。つまり、少し分かりにくいような場面では説明調のラベルが用いられていたり、「ここであの機能が使えたらいいな」という場面で確かにそのためのボタンが現れたりするのです。しかし、それらがとって付けたように唐突に現れるのです。システム全体で見ると、一貫性やまとまりに欠け、学習や予測がしづらいのです。あるいは、マニュアルを見て操作を覚えた後であればそれなりに各コントロールの合理性を理解できるものの、それはあくまでもハード的な部品数削減のための合理性であり、メンタルモデルの形成には寄与しないものであることが多いのです。
このような、「一応便利に使えはするけどイマイチなデザイン」について、僕はどのように評価すればよいのか迷います。ただ、それが目指すべき理想のデザインでないことは確かです。
問題は恐らく、UCD/HCD のメソッドが、RUP と同様に、ユーザーのタスク（業務）を拠り所としていることにあります。ユーザーの要求を知ろうとすることは確かにシステムの有効性を高めるために必要だと思いますが、ユーザー（コンテクスト）の多様性を考えると、タスクをベースにしてデザインされたシステムは、モーダルで非効率で学習しづらいものになってしまうのです。
そのようなタスク指向のデザインメソッドに対するカウンターパートとして、OVID に代表されるオブジェクト指向デザインのプロセスがあります。
オブジェクト指向デザインのメソッドでは、OOA/OOD で行うオブジェクト分析の結果を流用できます。すなわち、ユーザーの関心の対象であるオブジェクトをクラスとして定義し、それをそのままスクリーンに登場させるのです。またその結果として、モデル層のオブジェクトとビュー層のオブジェクトが比較的自然に対応するようになり、アルゴリズムの見通しも良くなるはずです。
プログラム設計のためのクラス定義では、ユーザーのメンタルモデルには関係しないような抽象度の高いクラスやコントローラーのためのクラスなどが必要ですが、OOUI ではそれらは無視して、ユーザーにとって意味のあるクラスだけをUI上のオブジェクトとして表現します。
開発メソッドにおいてオブジェクト分析の手法が確立されているのに、それがUIに適用されていないのは、RUP に代表される標準的プロセスがタスク指向であるからだと前に書きました。しかしタスクを包括してクラスの性質を定義するというロジックの飛躍を許容するならば、モードレスなデザインもある程度メソッド化することが可能だろうと思います。その飛躍部分をノウハウとして整理するのが、デザインパターンの役割というわけです。
UIを通じて「ユーザーが行えること」を決定するのはオブジェクトのクラスであり、その性質（プロパティとメソッド）です。つまりユーザーが接するクラスの性質を定義することが OOUI デザインの中心的作業になります。
ということで、これまで繰り返し書いてきた方法論を、今一度まとめてみます。
オブジェクト指向でデザインされたインタラクションは、基本的に、オブジェクトファーストになるはずです。ユーザーに対して、まず関心の対象であるオブジェクトのうち、作業の主要な処理対象となるものが提示されることになります。そしてそれらが、空間に見立てたスクリーン上に、自律的な存在として自然にマッピングされているようにするのです。
スクリーン空間に配置されたオブジェクト達は、それぞれの見た目や振る舞いによって自身の性質を体現するので、ユーザーはそれを触って動かしてみることでシステムのポテンシャルを感じ取ることができるはずです。よくユーザビリティテストを観察するオーナーが「この画面の使い方をユーザーは分かってくれるかな？」という心配をしていますが、そのような心配があるうちはUIがどこかモーダルになっているのです。UIがモードレスで、オブジェクトが空間に自然にマッピングされていれば、ユーザーは自分の作業を通じてUIを学習し、電車式でなく自動車式に目的に近づきながら、理論でなく実験によって、徐々に自分なりの使い方を作り上げていきます。そこには決まった使い方というものは無いのです。後は、ユーザーの学習を阻害するような暗黙の制約や不明瞭な因果関係を排除していけばよいのです。
ひとつのシステムにおいて複数の主要クラスを扱う場合は、対象クラスを選択する機能が必要になります。クラス選択はタスク／業務選択と同義であることも多いですが、できれば選択肢のラベル／アイコンにはタスク名ではなくクラス名を用います。その方がモードレスなメンタルモデルを形成しやすいからです。このクラス選択が、ナビゲーションになります。クラス選択からインスタンス選択へ、インスタンスの属性概要から詳細へ、という抽象度のズーミングによるドリルダウンも有効でしょう。ナビゲーションには他にも、特定のツールやビューを呼び出すものがありますが、これらの振る舞いをリアルタイムに反映することで、モードを無くすことができます。それ以外のナビゲーションは全て課税的な操作になるので、できる限り排除します。
オブジェクトは常にユーザーがマウスクリックやタップで直接ポイントできるようにし、またオブジェクトは自身の状態をできる限りリアルタイムに反映するようにします。
スクリーン上で、あるオブジェクトに対する処理がひとつだけなら、シングルクリックでそれを実行できるようにするべきです。アクションが複数あるなら、対象オブジェクトの選択後にアクションを選択させます。インスタンスの一覧においては、複数のアクションを属性として見せ、それらをシングルクリックで実行できるようにしてもよいでしょう。主要なアクションをダブルクリックに割り当てて、その他のアクションはメニューやボタンとして提示するのもよくあるパターンです。ただしドラッグ＆ドロップのような直接的なジェスチャがユーザーの認知的負荷を軽減できる場合にはそれを積極的に採用し、動詞選択という手続きをインタラクションから取り除きます。
同じオブジェクト（群）が複数のビューを持っていてもよいですが、できるだけ同じ場所で切り替えられるようにして、ビューをタスク／モードに依存させない方がよいでしょう。そうすることで、ユーザーはオブジェクトを実体として認知するようになり、ユーザーイリュージョンが強力になります。
— ここに書いたような方法論を用いれば、創作系ではない業務システムのようなものでも、かなりの割合でモードレスにすることができると思います。ただしそれには、前にも書いたとおり、システムオーナー側がユーザーの仕事というものをもっとモードレスなものとして、進歩的な価値観をもって、再定義する必要があるでしょう。デザイナーの本当のチャレンジは、もしかするとそこにあるのかもしれません。
- モードレス：オブジェクト指向
- モーダル：タスク指向
- モードレス：直接操作
- モーダル：間接操作
- モードレス：自動車式
- モーダル：電車式
- モードレス：実験的
- モーダル：理論的