プロトタイプの限界 より引用
プロジェクトが例えば、「飲み会のエクスペリエンス向上」というお題であったとする。
そして問題点として「お酒をあまり飲まない人が居る」という問題を発見したとする。
それを解決するためにお酒を人に飲ます事のできるソリューションというのを例えばいくつか思いつく、それはアプリケーションなどであったりツールであったり、もしかしたらメニューの構成であったりメンバーであったり席順であったり・・・
（中略）
たとえばここで設定した問題を、もう少し深く掘り下げていく。もしかしたらもう少し良い疑問を持てるのかもしれないという期待を込めて。
1. 「お酒を飲まない人が居る」
↓
じゃぁそれはなぜ問題なのか？
↓
それが例えば 2. 「会話に対して同じようなテンションで盛り上がれないから」だとする
↓
じゃぁなぜそれも問題なのか？
↓
3. 「みんなで盛り上がりたいから」
↓
・・・・
個人的プロブレムと会社側プロブレム より引用
例えば・・・レストランの顧客のエクスペリエンスを改善しよう、となったとする。
そこで問題を頑張って探す。
その際に例えば
「長蛇の列が出来る」
「ご飯にありつくまでに時間がかかる」
「込んでいる」
というところを問題点として発見したとしよう。
そして例えば長蛇の列が出来てしまう、という所に焦点を当てたとする。
なんでそれが問題？と考えたりした際に、ユーザーを観察して得た問題であるにも関わらずそれが
「長蛇の列が出来るとそれを見てお客様が来なくなり、店側は利益を損ねてしまう」
という様な論点に移ってしまうのはありがちな経過である。
もちろんこれも、「プロブレム」であり 間違いだとは言わない。
ただこの極端な例でおそらく気付かれた通り「店側の利益」など客にとってはしったこっちゃない。正解はないけど、自分であればもう少しこれを「個人的プロブレム」まで掘り下げることに魅力を感じる
「長蛇の列」が出来る「原因」はなにか、それがどうエクスペリエンスに影響を与えているか？
そもそもなぜ「長蛇の列」が出来るとユーザーのエクスペリエンスは下がるのか？列をなくす事を考える事でなくその困っている事を解消すれば良いのではないか？逆にラーメン屋でまっているとわくわくする事があるのはなぜか・・・など・・・
これら全て問題点を多少深く掘り下げている、という感覚。
フィールドリサーチ（ユーザーインタビューやリサーチなど）をした際にたくさん問題というのは見つかる。例えばチームであったらそれらを言い合って、どこにどのような問題があるかをもう出ない！というくらい挙げていく。するとそれらはいくつかのカテゴリに分ける事が出来る。そのまとめあげたものも問題なのである。そしてまとめられた要素からすればそのカテゴリは1階層上の問題。
また「なぜそれが問題となりうるのか」という事を議論する事も役に立つ事が多い。よく研究等でもそれを「なぜ」やりたいのかを何回も問えと言われる。そうする事でより本質に近づく事が出来るからだ。なぜそれがユーザーにとって問題なのか？それを考える事でそれもまた本質に近づく事が出来、より「掘り下げた」問題となりうる
人のニーズに対しても同じ。それぞれの問題とユーザーのニーズというのは密接な関係にあって、それぞれの問題に対してユーザーのニーズを発見出来ると思う。それらを「なぜ」と問い続ける事によってそのニーズの根本にある人のもっと大きい枠でのニーズというものを理解する事が出来る。
言っている事は単純だけれども、正直これが出来ない事が多い。そのニーズがどの程度特殊な状況であるか、人々に共通であるか、それらを上手く並び替える事でうまく人のニーズというのを整理する事が出来る。そして整理した上でプロジェクトを進める事でプロトタイプの限界や社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜で紹介したような「間違い」や「勘違い」の様なものはおこりにくくなるのである。
ニーズを整理出来たら、今度はどこから着手するかは自分たち次第。小さいニーズを狙ってもいいし、大きなニーズからまた少し派生させて新たなニーズを予測しても良い。
そうする事によって次の手順は踏みやすくなるし、花形であるソリューションを出す際の可能性は大きく広がっていくはずである
（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）
読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓
0 件のコメント:
コメントを投稿