HCDは有害か?さらに説明しよう

この記事は、Don Normanによるエッセイ「HCD harmful? A Clarification」の全訳です。
原文: HCD harmful? A Clarification (2005)

Interactions Magazineに掲載された私の記事『有害とみなされる人間中心デザイン』には、ちょっと手こずっている人々が多いようだ。

(いや、多いなんてもんじゃないね。記事へのコメントや他のブログでの言及を合わせたら500件は下らないはず。)

とりわけまずかったのは、私が「活動中心デザイン(ACD)」という言葉で何を訴えたいのか、それが「人間中心デザイン(HCD)」とどう違うのかをはっきり伝えられなかったことだ。

私が過去の発言を根こそぎ反故にしたと感じた人もいれば、単に頭がおかしくなったと思った人もいるようだ。ほんとはこういうことが言いたかったに違いない、とあわてて説明に走った人もいた。

自分としては、これまで主張してきたことに何ら変化が及ぶとは考えていない。むしろ、自分の仕事はすべて統一感のあるパターンの一部であり、人間のニーズにぴったりと見合った製品やサービスに向かうものだとみなしている。

ただし問題なのは、HCDがデザインを限定的に捉えた見方として発展してきたことにある。人の活動全体に目を向けるのではなく、ページ単位あるいは画面単位での分析がおもな焦点となってきた。その結果、活動の連続や中断、はっきりしないゴールなど、実際の活動に見られるさまざまな側面がすべて見過ごされてきた。そして、これまた問題なのがエラーメッセージというやつだ — そんなものは撤廃すべきである。メッセージというものは必ず、それ自体に何らかの説明を含み、先へ進む別の手段を示さねばならない。

従来よりも広い観点 ― すなわち、活動中心的な観点に立たない限り、こうした変革を起こすことはできないのだ。

現在のHCDからは、そのどれ一つとして見えてこない。当然あってしかるべきなのに、そうなってはいない。

達成すべきタスクと、実際に行われている活動に焦点を合わせることで、考慮すべき物事に対する人々の見方が広がることを、私は願っているのだ。

さて、実質的にというよりは重点の違いで変わってきた点が一つある。ユーザーをモデル化しようとしたり、魅力的なシナリオや「ペルソナ」を作ろうとしたり、そんな風に個々の人物を過剰なまでに重視する傾向が生じたことだ。もしそれが、デザインチームの限りある時間とリソースを、実際に役立つ大切なこと以外に振り向けてしまうとしたら、そのほとんどは見当違いで的外れなものでしかなく、ひょっとしたら有害にもなりかねない。

シナリオやペルソナには何の値打ちもないのか? そんなはずはない。シナリオは強力なマーケティングツールだし、ペルソナは素晴らしいコミュニケーションツールだ。私が書いた『Ad-Hoc Personas & Empathetic Focus』を読んでくれればわかる。でも、偉大なデザインを目指すならば、活動を中心に見据えてデザインすべきなのだ。

シナリオはかなりのハイレベルで策定するのが普通なので、具体的なインターフェース要素をデザインする際にはあまり役立たない。タスクフローの図式が重要となる。

タスクとは、たとえば「このメールに返信する」といった単一の明確なゴールを目指す状況のことだ。活動とはそれより一回り大きなグルーピングを意味し、きちんとつながり合う複数のタスクで構成されている。たとえば、「一日分たまった返答作業を片付ける」という活動は、メールを読んだり、返信したり、情報を探したり、時にはそれをメールにコピペしたり、カレンダーをチェックしたり、その他にも関連するタスクをあれこれこなすということだ。

私にとっては、エラー分析が改善のためのスイートスポットだ。デザイナーは、活動が行われる順序をちゃんと気にかけているのが普通である。しかし、ユーザーが問題に出くわしたり、未知の事態に陥ったりした場合にどうすべきかをまともに考えていることはめったにない。

タスク分析、タスクフローダイアグラム、シナリオ、活動分析、活動フローダイアグラムなどなど、呼び名はどうでもいい。肝心なのは、その分析によって、何かがおかしくなった時にたどりそうなステップを詳しく解明するということだ。その人に何を伝えるべきか? どんな選択肢を示すべきなのか?

それぞれの状況において、その人は何をしたいのだろうか?

何もかも順調だったり、必要な情報がすべて正しい形式で入手できるような、完璧な状況に応じたデザインをするのは比較的たやすい。しかし、特殊な事態が生じたり、情報の入力ミスや入力漏れがあったり、内容は正しくても入力箇所や順序が間違っているなど、予期せぬ状況にも対処するのが、よいデザインなのである。

ここがまさに、快適な体験と苛立たしい体験との違いがあらわになるポイントなのだ。

そのための一手とは、すべてのエラーメッセージを見て、それらが出る理由を特定し、もう二度と出ないようにデザインし直すか、もし出るとすればユーザーを援助する形に変えることだ。何をすべきだったのかを告げる「ヘルプ」ではなく、適切なアクションを示し、ユーザーが何らかのガイドを求めてこわごわと不完全な情報を入力できるくらい、前進を促す「アシスタンス」にするということ。

忘れないで欲しいのは、「完璧」なふるまいなどめったに生じない、ということだ。ほぼどんな状況でも、何かしら特殊なものだと言える。だから、特殊なケースを踏まえた、エラーメッセージを排したデザインをしよう。

達成したいタスクや活動にもっと目を向け、イケてはいるがデザイン的には虚ろなシナリオやペルソナには力を入れ過ぎないようにすべきだと、私は確信している。自分が本当にそのタスクを理解し、一つの活動を形成する複数のタスクの構造を理解し、ほぼ誰もが経験している活動の中断やその本質的なあやふやさを理解するならば、個々の潜在的ユーザーの熟練度や年齢、性格などに目を向けるより、はるかに効果的なサポートができる。

活動中心デザインをすれば、後は自然とうまくいくのだ。その反対 — つまり、活動をちゃんとサポートせずに人間中心デザインをするよりも。

いずれ、この分析をさらに広げられるとよいのだが。

以上が参考になれば幸いである。

広告