タスク指向のデザインはなぜ生まれるのか？

『タスク偏重のデザインはなぜ生まれるのか？』の続きです。

簡単だから

オブジェクト指向のUIにするには手順を解体し、オブジェクトを中心に構造化する必要があります。重複しているものはマージし、必要に応じて新しいオブジェクトを定義したり新しいイディオムを検討することもあります。

（例:「簡単に新規作成する」という機能に対して複製、テンプレート、マスターというイディオムを検討する）

これらはそれまで作ってきたものとうまく整合するようにしなければいけませんし、整合しないならどこをやめたら全体としてひとつの形にできるのか考えることになります。これは大変です。

対してタスク指向のUIデザインは簡単です。

新しいタスク用に新しい入り口を作って、必要な入出力を線形に並べ、例えばウィザードのようなパターンを使って提供すれば終わりです。

結果として他と整合性がなくなってしまったとしてもタスクに最適化したという言い訳もできてしまいます。

整合性を捨てるということであれば、既存のデザインを理解しなくても作ることができます。別の言い方をすると既存のデザインを理解できなかった時にタスク指向のUIがデザインされやすくなるということです。

「既存のオブジェクトとの関係性がわからないから、とりあえず別の入り口を用意して、その中だけ作ろう」となりますし、その先の画面でも「とりあえずタスクに必要だとされる入出力を並べよう」となってしまいます。

ということでUIの構造がわからない状態でデザインする際にタスク指向のUIが生まれてくる可能性があります。

同じように良さそうなイディオムが見つからない、うまく統合できないなどが要因で発生してしまうこともあるでしょう。

デザインチームで分業している場合はそういった土壌からタスク指向のUIがデザインされていないか考える必要があります。

業務システムのデザインを手順化だと考えるから

「混沌としている業務の中から最短の手順を見つけ、線形にする」という考えでデザインしようとするとタスク指向のUIになります。一見、線形にすることは有益であるようにも思えますが、異なる文脈を受けつけることを拒否しています。

実はこれも一種の「簡単だから」ともいえます。ただし、こちらの場合はシステムを理解していないのではなく、デザインの前提を線形に固定することでデザインを「簡単」にしているのです。

（タスクがなければできないユーザビリティテストも少し似た傾向があります。テストのしやすさのためにタスクを設定し、そのタスク上で評価をするのですが、そもそもタスクを固定したこと自体がどうなのかについて、顧みられることは少ないのです。）

ということで、業務をシステム化する時にそれまでは手順がなかった業務であってもシステム内に手順がデザインされる可能性があります。

しかもそのシステムを通じてしかその業務をすることができなくなってしまうと手順が完全に固定されてしまいます。

デザイナーがタスクを課せられているから

デザインされるものはデザインする環境を反映します。タスク指向UIが作られる背景を観察してみると、なんのことはないデザイナーがタスクを課せられていて、それをユーザーのタスクであるかのように転化していただけだったりします。この場合のタスクはユーザーのやりたいことではなく、ユーザーにやって欲しいことです。

これは店の商品を買って欲しいがために、勢い余って店に入る前に「買う」というドアを選ばせるようなものです。