よくありがちな調査はたくさんするものの改善につながるアクションにいたらない原因として、適切な分析が行なわれていないのではないかという指摘でした。
分析の欠如におけるワークフロー上の原因
Webに限らないと思いますが、何かをデザインする際の一般的なワークフローを描くとすれば、こんな流れを示せるのではないかと思います。
しかし、調査から実際の設計にいたるあいだを取り持つはずの分析・企画の部分に難があるケースは意外と多いのではないでしょうか？
１つには調査者がデザインをわかっていないこともありますし、その逆にデザインする人が膨大な調査データから有意なパターンを抽出するスキルがないことも原因としてあるでしょう。
調査者、設計者のいずれかが他方に歩み寄るのか、あいだを取り持つ別の分析～企画のスキルをもった人材を投入するかはどちらも問題解決の方法としてはありだと思います。
ただ、後者の場合、まったく新しいスキルをもった人材を投入するコストが発生しますので、手っ取り早く問題解決を望むのであれば、前者の方法をとり、既存のリソースを活かすのがよいでのはないかと思います。
では、分析とはどういうものなのでしょうか？
分析とは、原因と結果の因果関係を抽出すること
分析とは、一言で言って「原因と結果の因果関係を抽出すること」にほかなりません。原因と結果において、多くの場合、コントロール可能なのは、結果ではなく原因のほうだったりします。
例えば、Webユーザビリティを考えた場合でも、ユーザーの使いにくさという結果を直接コントロールすることはできませんが、その原因となる使いづらいデザインをコントロールすることは可能でしょう。
ユーザビリティ調査に行なう際、調査の視点は実際の結果としてあらわれる「ユーザーはどこでタスクの遂行が困難になっているか」「どこで間違い、遠回りをしてしまったか」ということをまず把握することです。
しかし、こうした事実としての結果が抽出できただけでは、その結果の改善を行なうことは必ずしも簡単ではありません。なぜ、そうした結果が起きているのか、その原因に関する仮説を抽出し、かつ、原因のうち、どれが実際に改善が可能なのかのプライオリティ付けもする必要があるでしょう。
このことを図にしてみると、こんな風になるでしょうか？
ようするに、分析とは、先のワークフローにおいて、調査と設計を取り持つことを実際に可能にすることです。
制御可能なデザインにおいて、何が問題の原因となっているかをつきとめることで、改善のためのリデザインを効率的に可能にすること。それが分析の役割だと思います。
原因の指摘は個別ではなく、本質的に
それゆえに、原因の指摘は、単に個別の事実を指摘するものではなく、より本質的な要因をとらえることが必要でしょう。例えば「このボタンがわかりにくい」というが個別の事実を指摘するものだとすれば、「ボタンはボタンらしく、ボタンではないものはボタンではないことがわかるように」というのがより本質をついた指摘となります。
本質的な指摘が重要なのは、個別の指摘だとリデザインを行なう際に本当にその個別の部分のみをリデザインの対象にしてしまうことも可能性としてはないわけではないからです。
それこそ、デザイン可能な対象の規模が大きければ大きいほど、現在のデザインがどのようになっているかを把握することはむずかしく、それゆえにすべてを把握する前にデザインを行なってしまうこともあるでしょう。
そうすると、「このボタンがわかりにくい」と指摘されたボタンを、わかりやすくリデザインした結果、実は他のページのあるアイコンと似たデザインになってしまい、結果としてそのアイコンまでが実際に利用するユーザーにボタンとして捉えられるようになってしまったということも決して発生しないわけではないからです。
そういうことが起こりえるからこそ、分析者の指摘は個別の対象に対して行なうのではなく、デザインの本質をつかんだ指摘であることが望ましいのです。
ないものねだりより今あるリソースの活用を
こうした視点に立てば、先のワークフロー上の「調査」と「設計」のあいだの溝もある程度は解消可能になってくるのではないかと思います。もちろん、より本質的な改善が望まれる場合だったり、プロジェクトそのものの規模が大きくなる場合は、分析～企画を行なう人材を別途調達したほうが結果として効率的な場合もあるでしょう。
しかし、すべてがそういうケースにあてはまらないのも確かだと思いますので、ないものねだりをするよりも、いまあるリソースとしての自分たち自身が自分以外の人のタスクの理解に歩み寄りの意志、姿勢をもつことのほうがはるかに重要だと思います。
関連エントリー
この記事へのコメント