ウィキペディアの「Smalltalk」のページには、次のようにあります。
アラン・ケイが「オブジェクト指向」という言葉を創った当初は、Smalltalk システムが体現した「パーソナルコンピューティングに関わるすべてを『オブジェクト』とそれらの間で交わされる『メッセージ送信』によって表現すること」を意味していた。
これは非常に興味深い話だと思います。なぜなら現在一般に「オブジェクト指向」という言葉が使われる場合、それはプログラミングにおける設計／実装の手法のみを指しているからです。しかし本来アランケイの発想では、ネットワーク上のノードや、クライアントデバイス内の各種フレームワーク、そしてユーザーがインタラクトするUIのイディオムなど、コンピュータメディアを構成するアーキテクチャの全てについて、抽象的なものから具象的なものまでをシームレスに包含するコンセプトだったのではないかと思われるからです。もしそうならば、Alto という GUI 環境と Smalltalk というオブジェクト指向開発環境は、同じコンセプトの実現に向けて作られたものだと言えるでしょう。すなわち、OOUI のコンセプトです。（ただし Smalltalk は特定の GUI フレームワークに依存しないようですが）
実際、「人間のためのコンピュータ – インターフェースの発想と展開」に寄稿されたアランケイのエッセイ「ユーザーインターフェース 個人的見解」を読むと、次のように書いてあります。
Smalltalk のオブジェクト指向性は非常に示唆的であった。オブジェクト指向とは、オブジェクト自身が自分が何をできるのか知っているという意味である。抽象的なシンボルの場では、それは、最初にオブジェクト名を記述（するかあるいは持ってきたり）してそしてそれに何をするかを指示するメッセージを付ける。具体的なユーザーインターフェースの場では、それは最初にオブジェクトを選択することを意味している。それから何がしたいのかをメニューによって提示する。どちらの場合でも、オブジェクトが先であり、やりたいことがその次となっている。これは具体的なものと抽象的なものとを高い次元で統合している。
また、そのような環境で実現すべきコンピュータならではの魔法のような演出を、アランケイは「ユーザーイリュージョン」と呼んでいます。ユーザーイリュージョンはメタファーを高次元化したような概念で、例えばハイパーメディアのように、現実世界にある道具をメタファーとしつつも、現実世界には存在し得ない新しいメンタルモデルを、自然な形で与えることが望ましいとしています。他にも例えばデスクトップのフォルダについて、現実世界のメタファーに縛られたために排他的な存在になっているのはおかしいとして、「受け身的な容器ではなく、関連したアイコンをたえずとらえようとする、能動的な探索子」であると良いと言っており、最近の Mac では当たり前になっているスマートフォルダのアイデアなども披露しています。
GUI（OOUI）では、空間に見立てたスクリーン上に、操作対象であるオブジェクトがアイコンやウィンドウといった視覚表現で提示されます。各オブジェクトはそれぞれの属性情報や機能性を内包した静的な存在で、それ自体はコンテクストに依存せず、自発的に動き出すことはしません。つまりその存在は状況に対する必然ではありません。しかし各オブジェクトは、ひとたび外からのメッセージを受けると動きだし、自分自身の状態を変化させたり、他のオブジェクトに連鎖的にメッセージを送ったりします。
メッセージの起点となるのは基本的にユーザーからの入力イベントです。入力は、マウスなどの GID によってスクリーン空間上のオブジェクトに直接行われるので、即物的であり、ある操作が作業に及ぼす影響は、基本的にその操作の直後に起こるフィードバックによって完結します。各オブジェクトは、決められたストーリーを構成するために存在しているのではなく、ただ自分の役割を果たすためだけに存在しているのです。その様は、あたかも、自身の客観的性質に従いながらモードレスに存在する現実世界の物体のようです。
このような世界観自体が、アランケイの言うユーザーイリュージョンの一環であると言えます。そしてこのイリュージョンは、一定の処理フローを前提にプログラムを記述する手続き型／構造化言語では実現が困難でしょう。だから OOUI のパラダイムを実現するためには、オブジェクト指向言語が必要だったということではないでしょうか。
ところが後年になると、オブジェクト指向で作られたソフトウェアが持つ高い保守性や拡張性にばかり注目が集まり、単なるプログラミングの様式のように認識されるようになってしまったのだと思います。
一般的に OOA/OOD の過程では、システムの構造や働きをモデル化するのに、UML が用いられます。UML には複数のダイアグラムがあります。表したいシステムの側面に応じて使い分けるわけですが、別な言い方をすれば、あるシステムの性質はひとつの記法では抽象化できないということです。
UML はその名の通り、複数のモデリング手法を統合して標準化したものですが、その成り立ちにおいては、RUP に代表される、ビジネスアプリケーションの開発プロセスに対する親和性が強く意識されています。
ビジネスアプリケーションというのは、業務システムと言ってもよいですが、それがオフィスで使われるかどうかに関わらず、もしくはユーザーインターフェースを持っているかどうかに関わらず、ステークホルダーの特定の要求を特定のビジネスロジックによって満たすために作られます。だから当然、要求やロジックが特定できることを前提とした存在です。つまりタスク指向の道具というわけです。そのようなシステムを開発するプロセスでは、必然的に、上流工程において適切にタスクを分析することが重要になります。
UML の各ダイアグラムは、それぞれ開発プロセスのどの段階で使われるのかがおおよそ想定されています。上流の業務分析／要求分析で用いられるのは、アクティビティ図やユースケース図です。これらは業務フローやシステムが提供するサービスのスコープをモデル化するもので、要するに、ユーザーがそのシステムで行うタスクを定義するものです。
しかしここで注意すべきは、アクティビティ図やユースケース図というのは、オブジェクト指向とは関係が無いものであるということです。これらの図にオブジェクト（クラスまたはインスタンス）は登場しません。つまりビジネスアプリケーションの開発では、設計の拠り所として、オブジェクトではなくタスクを用いるということです。これは結果的に、設計や実装にオブジェクト指向の手法が用いられたとしても、ユーザーが認知するシステム像、つまりインタラクションデザインやユーザーインターフェースデザインにはそれらが全く反映されないということを意味しています。プログラムは Java で書かれているのに画面はただのウィザード、みたいなシステムが普通に存在しているのです。アランケイがイメージしていた、オブジェクト指向によるユーザーイリュージョンの創出という取り組みからは、随分離れたことをやっているわけです。
さて、ペルソナなどによってユーザーを定義することがかえってデザインの要件定義を困難にするのであれば、我々は何を手掛かりにすればよいのでしょうか。その答えは、ここまでの考察の中である程度見えてきていると思います。
まず立脚点として、道具のデザインの二大コンセプトである「モーダル」と「モードレス」に立ち返ってみます。
モーダルなデザインはタスク指向であり、その目的は、ユーザーを一定のゴールに導くための「プロセスの自動化」にあります。ユーザーが持つべき興味の対象はタスクであり、ユーザーが行うべき意思決定は「タスクの選択」に集約されます。多くの業務アプリケーションはこの考え方で設計されており、ユーザーがタスクを選択した後は、基本的に決められた手順で必要なパラメーターを入力していく操作になります。
タスク指向なシステムの最適化対象は、つまり、ユーザーのタスクということになります。だから要求分析においては、正確にタスクを定義しなければなりません。タスクというのは「任務」ですから、ユーザーには何らかの「課せられた仕事」があるわけです。誰がそれを課すのかというと、会社だったり、社会的なプレッシャーだったり、自分自身の欲求だったりします。いずれにしても、システムの役割は、ユーザーがある特定の目的を達成するための手続きをサポートすることです。上流工程では、その目的を達成するためにはどのような手続きが最適なのか、ということを明らかにすることになります。そのためには、現行システムにおいてどのような手続きがとられていてどのような問題があるのか、ユーザーは本来どのような手続きを期待しているのか、もっと効率的な手続きはないのか、といったことを探る必要があります。
手続きというシーケンシャルなストーリーは、フローチャートとしてモデル化できます。あるいは、シナリオとして明文化できます。ジョンキャロルのシナリオメソッドでは、As-Is シナリオを徹底的に分析し、ストーリーとして冗長な箇所や矛盾した箇所を特定し、それらを理想的な記述に置換することで、実現すべき To-Be シナリオを導出します。また、ラリーコンスタンティンの Usage-Centered メソッドでは、ユーザーのタスクを細分化して、一連の不可分な入出力操作を最小単位とするユースケース風なダイアグラムを作ることで、シナリオから機能要件を抽出します。これらはいずれも、タスクというトップダウンな「任務」を手掛かりにしたデザイン手法です。
タスク指向のシステムでは、タスクが定義されてしまえば、ユーザーインターフェースはほとんどできたも同然です。タスクはシーケンシャルな手続きに還元できるはずなので、極端に言えばすべてウィザードにしてしまえばよいのです。
ウィザードであれば、タスクに必要な最低限の入出力操作は機械的に定義できるので、それを GOMS-KLM などで最適化すれば、システムの利用価値を最大化することができるでしょう。
ということで、タスク指向のデザインは比較的簡単です。問題は、オブジェクト指向のデザインについてです。