ユーザを理解する 〜Needfinding という魔法の言葉の裏〜

デザインプロジェクトを語る際によくNeedfinding というフェイズの事が語られます。言葉はいう人によって違いますが、エスノグラフィックリサーチ、ユーザ理解、など様々な形で言われていると思います。要は「対象者が何を求めているか、何を望んでいるのかを知ろう」というフェーズのことです。
この魔法の言葉によって自分自身、このフェイズを経れば良いデザインにつながるのだと思っていたんですけど、もしかしたらニードファインディングって言葉自身に２つの目的がありそうなのにごっちゃにしていたので、クリアにするために記事にさせていただきます。

イノベーション始めました。(と言いたい) 〜イノベーションの始め方〜

どっちかっていうと忘備録です。友人と話していて自分はこんな事がやりたいのかなーと思ったことがあったので書き留めておきます。どのようにイノベーションや新しいこととふれあいたいか、という記述です。共感してくれる人がいると嬉しいです。

考えたきっかけは以前友人がアメリカに行ったときに聞いた、という一言でした。

"日本は売り方が下手すぎる。あんなに良い物やすごい技術を持っていながら、売る事が下手だから世界をリードできないんだ。"

経営学×デザイン思考 ~経営学としてのデザイン思考~

「経営学を学んでいる学生からデザイン思考に興味を持ったという意見が寄せられて・・・・ 」「デザイン思考って経営学のアレでしょ？？」
と言う言葉を以前某デザイン会社の人から伺った。

 
デザイン思考が経営学？   

・・・・・・・正直、耳を疑った。

結局デザイン思考ってなに！？ 〜もう一度考えなおしてみる〜

image via gigazine

今更！？って感じかもしれないですが、デザイン思考について語ります。

いやもうデザイン思考とか古いだろｗｗｗって思う人もいるとおもうのですが今だからこそ、書かせてください。

ちょっとした動機

Think to build, build to think

Think to build, build to think.
特にbuild to thinkはME310@Paris の中ではキーワードみたくなっていた

「プロトタイプは疑問にこたえる為に作るもの」ってことは色んなところで書いていた。　(よい疑問を持てば、プロトタイプの形は見えてくる, モックアップとプロトタイプ, プロトタイプは状況に応じて時にラフに、時に詳細に, デザインは人のニーズを満たす物として然るべき, 社会的プロブレムと個人的プロブレム, プロトタイプの限界)

もちろん疑問って、考えていっても自分なりに考えれば答えが出てしまうもの。そうして考えて考えて、最終的にひとつのプロダクトを作るのもある意味よい事かもしれない。
 もっと言えばプロジェクトを進めている時によく

「作るのに時間がかかるから考えてから作ろう」

ということを考える。
ただ・・・もっと身軽に行った方が良い時が多い。 考えているときには思いつかないことが、プロトタイプを通じて見つかったりする。

だから「とりあえず作ってみよう！」ってのも大切。
よくわからんけどとりあえず作ってみよう！って手を動かす事で、それをテストさせる事で思いもしないものを得れたりもする。

たとえば下の写真は、フィードバックが水の使用量を減らせるかという疑問を持った際のプロトタイプ

まーよくわからないけど、とりあえず作ってみた。

ここで得られた知見にも、面白いものはあった。
たとえば

これってカロリー計算とかに似てるかも。最初は意識してみるけど、あとあともう自分で大体感覚で分かる事が出来る

とか

バケツだと水の量が限られているように感じるから、さらに水を減らそうと思ってしまう。

とかなんとなく期待していない意見が得られた。もちろんカロリーに似せた覚えなんてないし、水の量もホントは水道をまねて作っただけだからそこは感じてほしくなかったってとこが正直なところだし・・・
でもそこから例えばカロリーを減らそうと頑張っている人には何が効果的なんだと調べることが出来たり、水の量に限りがあるように見せたりする事で使用量を減らさせる、などちょっと発展させる事が出来る。

さらにそゆのって人からの意見／人を観察して得られた知見であるので結構自信をもって進める事が出来るし、それもプロトタイプとして別にミスってもいいから、って感じで進めて行ける。またそこから何かを得られるかもしれない

虎穴に入らずんば虎児を得ず、ではないけどとりあえず作ってみる、それが案外色んなところに導いてくれたりもする。

もちろん毎回ではないけど。

ただそんな作ってたら時間ないよーとか思われるかもしれないけど、例えば先の画像のバケツのプロトタイプなんて1時間やそこらで作れる。それをテストするのだって一人５分程度しかかからない。それらで得られた知見について進めていく事が出来るのは大きい事だと思う。


あと微妙に思ったのが「作る事」＝プロトタイプではないという事。またプロトタイプでなかったら作っていけないなんてルールもない事。もしかしたら電車で５時間行ったところにあるようなものを使っている人を観察するよりも、同じようなものを作ってそれを使っている姿を観察する方が効率的かもしれない。そういった意味で作ったものは、モックアップではあると思うけどプロトタイプではない。ただ、「観察」も重要であるしもちろん時間の許す範囲でだけど、何がプロトタイプで何がプロトタイプでなくて、なんて考える前に、ちょっとこれどうなんだ！って思ったら作ってみるのが得策なのかも知れないデスネ

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

語学レベルと人の説得

ME310のプロジェクトを通じて、日本人とプライベートで話すとき以外はずっと英語で話していた。
パリでのプロジェクトだったにもかかわらずフランス語を身につけられなかった事は若干恥ずかしい事なのですが・・・許してくださいw

そんな中で感じた事。語学力の話。

「人に何かを伝える事が出来る、会話が出来る」という事と「人を説得する事が出来る」ということは全くの別物だった。自分の考えはこうだ！的な事は考えていてもそれをストレートに伝える事しか出来ない。少しそれを比喩したり寄り道をして人の興味を引いてそれを人に納得させる、もしくは説得する、このことが恐ろしく難しく感じた。

日本語で言うなら今書いた文章、そしてこれから書く文章をただ「英語で人を説得するのは難しい」 という一言だけで伝えてしまうようなイメージ。
これに人を納得させる力等ある訳がない。

ただ逆に流暢な人はやはり人をまとめる事であったり人を聞く姿勢にさせる事が出来る。自分としては本当にそれがうらやましかった。

初めにパリに行った時は（今どうなっているかは分からないけど）正直説得なんて全然出来なかった。でもだからこそ自分なりにいろいろ工夫した

以下に自分なりに工夫した事等を書いておきます

自分の意見があってそれを言いたいとき、自分は以下の事をした

• 「話の道筋をあらかじめ考えておく」
• 「画像等visual の題材を用意しておく」
• 「既存のものをたとえにして説明する」
• 「似たような話が出た時にここぞといく」

もちろん・・・普通の事。ただ少しでもそれを考えておくと人に話した時に伝わり方がかなり違う。特に画像等を持っていった場合は理解が全然違うし興味を引く事も出来る。もちろんやり過ぎはないようにした。一人だけ頑張ってると向こうからしたら居心地が悪いと思ったし・・・
最後の「似たような話が出た時にここぞといく」ってのも結構効果はあった。当然コミュニケーションなわけだからいきなりぶっ飛んだ話をしても聞く事すらしていないときすらあるイメージなのだ。もちろんその似ているアイディアを出した人が自分のアイディアにくっつきすぎてしまうというデメリットはあるけれども・・・そこさえ上手くクリアすればとても「聞く準備の出来た状態」の相手に話す事が出来る


語学以外でカバー出来る事はフルに活用した。そのくらいしなくてはあの頑固な（笑）人たちは説得する事は出来なかったので・・・難しかったなーー

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

問題とニーズの階層

今までME310を通して感じた事のまとめの記事の中でいくつか問題点やニーズについて、「掘り下げる」という表現を使ってきた。例えば以下の二つを見てほしい

プロトタイプの限界　より引用

プロジェクトが例えば、「飲み会のエクスペリエンス向上」というお題であったとする。
そして問題点として「お酒をあまり飲まない人が居る」という問題を発見したとする。


それを解決するためにお酒を人に飲ます事のできるソリューションというのを例えばいくつか思いつく、それはアプリケーションなどであったりツールであったり、もしかしたらメニューの構成であったりメンバーであったり席順であったり・・・

（中略）

たとえばここで設定した問題を、もう少し深く掘り下げていく。もしかしたらもう少し良い疑問を持てるのかもしれないという期待を込めて。

1. 「お酒を飲まない人が居る」
↓
じゃぁそれはなぜ問題なのか？
↓
それが例えば  2. 「会話に対して同じようなテンションで盛り上がれないから」だとする
 ↓
じゃぁなぜそれも問題なのか？
↓
3. 「みんなで盛り上がりたいから」
↓
 ・・・・

個人的プロブレムと会社側プロブレム より引用

例えば・・・レストランの顧客のエクスペリエンスを改善しよう、となったとする。
そこで問題を頑張って探す。
その際に例えば
「長蛇の列が出来る」
「ご飯にありつくまでに時間がかかる」
「込んでいる」
というところを問題点として発見したとしよう。

そして例えば長蛇の列が出来てしまう、という所に焦点を当てたとする。
なんでそれが問題？と考えたりした際に、ユーザーを観察して得た問題であるにも関わらずそれが
「長蛇の列が出来るとそれを見てお客様が来なくなり、店側は利益を損ねてしまう」
という様な論点に移ってしまうのはありがちな経過である。

もちろんこれも、「プロブレム」であり 間違いだとは言わない。
ただこの極端な例でおそらく気付かれた通り「店側の利益」など客にとってはしったこっちゃない。正解はないけど、自分であればもう少しこれを「個人的プロブレム」まで掘り下げることに魅力を感じる
「長蛇の列」が出来る「原因」はなにか、それがどうエクスペリエンスに影響を与えているか？
そもそもなぜ「長蛇の列」が出来るとユーザーのエクスペリエンスは下がるのか？列をなくす事を考える事でなくその困っている事を解消すれば良いのではないか？逆にラーメン屋でまっているとわくわくする事があるのはなぜか・・・など・・・

これら全て問題点を多少深く掘り下げている、という感覚。
フィールドリサーチ（ユーザーインタビューやリサーチなど）をした際にたくさん問題というのは見つかる。例えばチームであったらそれらを言い合って、どこにどのような問題があるかをもう出ない！というくらい挙げていく。するとそれらはいくつかのカテゴリに分ける事が出来る。そのまとめあげたものも問題なのである。そしてまとめられた要素からすればそのカテゴリは1階層上の問題。

また「なぜそれが問題となりうるのか」という事を議論する事も役に立つ事が多い。よく研究等でもそれを「なぜ」やりたいのかを何回も問えと言われる。そうする事でより本質に近づく事が出来るからだ。なぜそれがユーザーにとって問題なのか？それを考える事でそれもまた本質に近づく事が出来、より「掘り下げた」問題となりうる

人のニーズに対しても同じ。それぞれの問題とユーザーのニーズというのは密接な関係にあって、それぞれの問題に対してユーザーのニーズを発見出来ると思う。それらを「なぜ」と問い続ける事によってそのニーズの根本にある人のもっと大きい枠でのニーズというものを理解する事が出来る。

言っている事は単純だけれども、正直これが出来ない事が多い。そのニーズがどの程度特殊な状況であるか、人々に共通であるか、それらを上手く並び替える事でうまく人のニーズというのを整理する事が出来る。そして整理した上でプロジェクトを進める事でプロトタイプの限界や社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜で紹介したような「間違い」や「勘違い」の様なものはおこりにくくなるのである。

ニーズを整理出来たら、今度はどこから着手するかは自分たち次第。小さいニーズを狙ってもいいし、大きなニーズからまた少し派生させて新たなニーズを予測しても良い。
そうする事によって次の手順は踏みやすくなるし、花形であるソリューションを出す際の可能性は大きく広がっていくはずである

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

個人的プロブレムと会社側プロブレム

以前
社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜

という記事を書いた。
これはプロジェクトを進める段階で発見される「プロブレム」には２種類あって、それは

• 「社会的プロブレム」: 社会や環境のつくり上げた問題。地球温暖化などがその一例
• 「個人的プロブレム」: 個人が不便に感じる問題点、朝起きるのが辛い、などがその一例

に分けることが出来、ユーザーのニーズはこの「個人的プロブレム」に潜んでいるという物である。

ただもう一つ、プロジェクトを考える上で大事なプロブレムがあることに先日気がついた
「会社側プロブレム」 である。
それは何か？
一種の「会社の要望」の様な物。

例えばそのプロジェクトが会社から持ち出されたものであれば、会社的にこうしたい、こうであると嬉しい、というものはあるはず。考え方としては社会的プロブレム、と多少かぶる部分もあるかもしれないけど敢えて切り離して考えたほうが分かりやすいと思った。

例えば・・・レストランの顧客のエクスペリエンスを改善しよう、となったとする。
そこで問題を頑張って探す。
その際に例えば
「長蛇の列が出来る」
「ご飯にありつくまでに時間がかかる」
「込んでいる」
というところを問題点として発見したとしよう。

そして例えば長蛇の列が出来てしまう、という所に焦点を当てたとする。
なんでそれが問題？と考えたりした際に、ユーザーを観察して得た問題であるにも関わらずそれが
「長蛇の列が出来るとそれを見てお客様が来なくなり、店側は利益を損ねてしまう」
という様な論点に移ってしまうのはありがちな経過である。

もちろんこれも、「プロブレム」であり間違いだとは言わない。
ただこの極端な例でおそらく気付かれた通り「店側の利益」など客にとってはしったこっちゃない。正解はないけど、自分であればもう少しこれを「個人的プロブレム」まで掘り下げることに魅力を感じる
「長蛇の列」が出来る「原因」はなにか、それがどうエクスペリエンスに影響を与えているか？
そもそもなぜ「長蛇の列」が出来るとユーザーのエクスペリエンスは下がるのか？列をなくす事を考える事でなくその困っている事を解消すれば良いのではないか？逆にラーメン屋でまっているとわくわくする事があるのはなぜか・・・など・・・

世の中に出ている商品には、会社が「会社側プロブレム」のみを考えて商品を作ってしまう事が多い。「これが売れればうちの会社は・・・」の様に・・・

この記事ではgoogle+ がそうである、というような事も書いてある。
他の例では、「広告を見るためのアプリ」などもそうである。バス停とかに、暇だったらこれダウンロードしたらいろんな広告見れるよ、的な広告があるらしい。。。そりゃ・・・広告見てくれたらうれしいけど、それをダウンロードして使う人って居る？的な感じになってしまうだろう。

どんな種類のプロジェクトであれ、議論を始めるきっかけとなる足場を探す事は必要であり、これ無しにプロジェクトは進められない。そしてどんな種類の「プロブレム」も足場にはなりうる。ただそこから深く考えていこうというときにその問題をどうとらえるか、それを如何にユーザー側から見た「個人的プロブレム」に落とし込めるか、それがデザインプロジェクトにとっては鍵になってくるのである。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

プロトタイプの限界

以前 [社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜]
の中でも少し触れた話なのだが、今回は「プロトタイプの限界」についての議論を進めていく

そもそもプロトタイプとは？って人のは…さっきの記事の中か、
プロトタイプは状況に応じて時にラフに、時に詳細に
という記事を読んでいただくことをおすすめします。

一応簡単に書くと

何かの疑問を解決するために作るもの

ということになります。

そんなプロトタイプにも限界があるというのが個人の考え。
ではどういうところに限界があるのか？それは前回の記事でも触れたような話。前回はこんなふうに書いていた。

プロトタイプの限界の章にあるように、プロトタイプは形にしたものを改善する、もしくは評価するのはとてもいい。ただそれ自体が本当にいいものかどうかってのは測れない・・・かもしれない。

つまりそれはどういう事か？
プロジェクトが例えば、「飲み会のエクスペリエンス向上」というお題であったとする。
そして問題点として「お酒をあまり飲まない人が居る」という問題を発見したとする。

それを解決するためにお酒を人に飲ます事のできるソリューションというのを例えばいくつか思いつく、それはアプリケーションなどであったりツールであったり、もしかしたらメニューの構成であったりメンバーであったり席順であったり・・・

そんななかでプロトタイプを作成してテストする。
例えばプロトタイプでお酒を飲ますためのアプリケーションなどを考えたとしよう。そしてそこで「どのインターフェイスがもっとも人を飲む気にさせるか」的な疑問を持ったとする。
そのプロトタイプを通じてどのようなことが分かるだろうか？それはせいぜいどのような要素が飲む気にさせるか程度であり、そもそもそこに疑問を持ったことは正しかったのか？というような一歩引いた意見は出てこなくなってしまうのだ。

もちろんそれは、プロトタイプの失敗という形でみえてくるかもしれない。プロトタイプってのは失敗してなんぼのものであり、それを恐れてプロジェクトは進められない。ただもしも、もっと早くから失敗してしまうかもと見えていれば、というふうに思ったりもする。
まー失敗の定義も難しく何が失敗であるかなど誰にも言えないのだが・・・


失敗の定義がわからない以上、この話を進めるのもナンセンスかもしれない。ただもしよければもう少しお付き合いいただきたい。

自分だったら今回発見した「お酒を飲まない人が居る」という問題について進めることはしない。なんとなく。ではどうするか？
たとえばここで設定した問題を、もう少し深く掘り下げていく。もしかしたらもう少し良い疑問を持てるのかもしれないという期待を込めて。

1. 「お酒を飲まない人が居る」
↓
じゃぁそれはなぜ問題なのか？
↓
それが例えば  2. 「会話に対して同じようなテンションで盛り上がれないから」だとする
 ↓
じゃぁなぜそれも問題なのか？
↓
3. 「みんなで盛り上がりたいから」
↓
 ・・・・

という様に問題というのは基本的にはどんどん深くまで掘り下げることが出来る。ただ掘り下げれば掘り下げるだけ抽象的になってしまうこともあるので注意なのだが、例えば途中の2. の段階で
「じゃぁどうやったら盛り上がれる？」「あまり盛り上がらない、と言われている人が盛り上がるのはどんな時？」「話したくないの？話したいけど話せないの？」「話したいのに話せない、という人は何を考えている？」
などともう少し派生した問題点、もしくはニーズに行き着くことが出来るのも事実。

もしくは1. の段階で「なぜ飲めないのか？」を考えることで
↓
「お酒嫌い」「みんなと飲みたいお酒の種類が違って頼みづらい」

などどの階層にもある

ちなみに最初に設定した問題「お酒を飲まない人が居る」ってのはある意味「個人的プロブレム」ではなく「社会的プロブレム」（こんな場合は環境的プロブレムとでも言うべきなのだろうか？） ( [社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜] 参照) であり敢えてへんな問題点を設定したのだが・・・
ただここで後述した問題点、それらはもう少しユーザーに近いニーズなのではないかと自分は考える。見つけた問題点に自信を持つ。そしてそこから「どのように〜」といった疑問をプロトタイプで解決していくことが個人的に考える「良い流れ」だと思う



まとめると、プロトタイプってのは設定した疑問の外側、もしくはそれよりも上層の問題（問題とニーズの階層参照）にはたいてい出得ないものであるのだ。
Build to Think, Think to Build の章で書いたように、もちろんプロトタイプを作ることで、想定した以上のフィードバックに出会うことはある。ただそれでもそれはたいてい設定した疑問よりも上層の問題を解決、発見するには至らない。
これははじめのプロブレムを見つける段階、ニードを見つける段階が如何に大事かを裏付ける事実だと捉えて欲しい。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

モックアップとプロトタイプ

昔ここでも記事を書いたけど、今回はもうちょっと体裁を整えて丁寧に書きます笑

モックアップとプロトタイプはどう違うのだろう？
以前プロトタイプは状況に応じて時にラフに、時に詳細に、でも書いたように
プロトタイプを作る目的は
[to answer the question]、「疑問に答える事」
 である。

だから何かしら疑問を持った際にその疑問のみに答えられるような必要最低限のプロトタイプを用意すれば、それは「良いプロトタイプ」なのである。

 今この記事を書いていて思ったのだが、「モックアップ」について自分自身で意見を述べられるほど頭の中に入っていなかったので多少引用させていただきます。

知恵蔵2011の解説
直訳すると「模型」。プロダクトデザインなどにおいて、外観デザインの試作・検討レベルで用いられる模型をいう。従来は木製のものが一般的であったが、現在は合成樹脂製がほとんど。木製のものは、「木型」とよばれ、商品の大きさや色・質感などや、製造のための「原型」としても使用された。家電製品をはじめ自動車、航空機など、精密さを要する製品デザインに、モックアップは不可欠なものである。現在はCAD/CAMの普及によって職人による手加工から、図面データによる自動切削加工によって製作されるようになった。 なお、デザインの進捗(しんちょく)段階に呼応し、さまざまな呼称がある。初期段階=スタディー・モデル、外観デザイン検討段階=プレゼンテーション・モデル、内部機構検討段階=ワーキング・モデルまたはプロトタイプ・モデルなど。
(モックアップ とは - コトバンク http://kotobank.jp/word/%E3%83%A2%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97)

一応頭にこのようなものがモックアップ、とはあるのですが多少の誤解があるかもしれません。「モックアップとプロトタイプ」について自分なりの考えを述べていきます。

ある意味モックアップもプロトタイプの一つになりうると思う。ただ必ずしもそうとは言えない。

たとえば新しい傘を作るっていうプロジェクトがあったとして。
そのコンセプトを「相合い傘しやすいように傘作ろう」 ってなったとする
（ちなみにこれは僕が友達と東工大の授業のプロダクトデザインという授業でセットした題）

その新しい傘ってのは、いろーーんな要因を含んでいる。
サイズであったり、形であったり、重さであったり、色であったり、音であったり。

プロトタイプってのはたとえば
「サイズはどのサイズがベストなの？」
「どんな形がふさわしい？」
「どんな重さまでが許容範囲？」
とかとかそういった疑問を解くために作られるべき。

一方モックアップは、ある程度イメージ出来るファイナルプロダクトの形を作ってみる感じ。ここで言うとこれら全部の要因を含むもの。たとえばそれでもテスト出来るよーっていって、いくつかのモックアップを作ってテストするとする。ある意味それもプロトタイプなのかもしれないけど、多分そのプロトタイプで重要なインサイト（洞察）を期待する事は出来ない。なぜならそこでの疑問は「どのモックアップが一番いい？」というような抽象的であまり良くない疑問であり、（正しい疑問を持てば正しいプロトタイプは見えてくる 参照）あまりに詳細に作られているが故に、フィードバック自体も詳細になりすぎて自分の本当に試したい事に対する意見を貰えなくなってしまうのだ（プロトタイプは状況に応じて時にラフに、時に詳細に 参照）
さらにモックアップは時間がかかる。そしてコストもかかる。そのモックアップが受け入れられなかった場合にショックはなかなか大きく、その失敗はにわかには受け入れがたい・・・と思う。

ただモックアップが悪いと言っている訳ではない。モックアップを作る事でユーザーはたとえばその商品なり経験をより鮮明にイメージする事が出来る。それを使ってたとえばインタビューをする、物理的な大きさ等の確認をする、詳細部分を確認する、プレゼンする、などそれによってしか出来ない事もたくさんあるのだ。モックアップとはもう少しあとのフェーズに出てくるべきものの様に思われる。

注意すべきところはデザインプロセスの中で多くの場合に「曖昧さ」と戦う時期がある。そんな場合にタンジブルな自分の考えに近いモックアップを自分の横においておく事は精神衛生上落ち着けることが多い。一刻もはやくファイナルプロダクトを見たいし、そもそも作れるのか不安だし、おもしろいアイディアだから早く具現化したいし、みたいなどっちかというとプロトタイプ作りたい欲よりもモックアップ作りたい欲のほうがプロセスに居る間は強いのだ。

ただそこをぐっとこらえて、正しい疑問をもち、正しいプロトタイプを作る事。それが重要だと思う訳なのですよ。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

よい疑問を持てば、プロトタイプの形は見えてくる

タイトルが・・・もっとも伝えたい事です笑

この言葉は師（？）である Sushi Suzuki さんのツイッターから引用、着色したものです。昔のつぶやきだったので一字一句合っているかは分かりませんが、こんな感じの事を言っていたと思います


正直・・・正しいかは分からない。
けど何となくそうと信じてやってきた言葉。

何が「よい疑問」なのかも分からないしそれらが全て「プロトタイプ」を通じて検証出来るとは限らない。

ただ「プロトタイプなにつくりゃいいんだーーーー」ってなる人はたくさんいると思う。
そんな時に、一度「疑問」に疑問を持つ事はとても大事。

プロトタイプは以前にも色んな記事で言ったように、「疑問に答えるために作るもの」であり、その形は必ずしもファイナルプロダクトと似ているとは限らない。むしろ似ていない方がよいフィードバックやインサイトを得る事が出来る事もある。
（プロトタイプは状況に応じて時にラフに、時に詳細に, プロトタイプの限界 参照）

たとえば下はディスプレイの傾き加減や高さを決める際のプロトタイプ

紙に This is a display って書いてそれに棒をつけただけのプロトタイプ。（もちろん何かしらにそゆのが載ってる本とかありそうだからやる必要なかったのかもしれないけど）タッチスクリーンがどこに固定されているのが一番使いやすいかを聞いたもの。ここでの質問はシンプルで、おそらくこれは作るのに一番悩まなかったうちの一つのプロトタイプ。
まぁ誰でも思いつくようなものだけど、たとえばこれでプロダクト全部を作る必要もなければ形ですら作る必要もない。聞きたいのはディスプレイの高さと傾きなのだから、それが試せるプロトタイプを作れば良い。

あまり疑問を持たずにプロトタイプを作った事もあった。それはやはりファイナルプロダクトを意識してしまって、全てのファンクションを盛り込んだ。作ったあとに、あれ？何聞きたいんだっけ？ってなったりした。。。問題も疑問も、そこに視点をおいて初めて見えるものであり、とりあえず進めているだけでは見つかるものでもない。そして「なにすりゃいいんだーーー」ってどうせなる。 そういう時はプロトタイプをどうしようでなく、疑問をどうしようと考えることを勧める。それがプロトタイプを作る一歩目だからだ。

ユーザーの問題を見つけてそれを解く時にじゃあこうだったらどうなるんだ？っていう疑問。それがまず一歩目。
そしてその「こうだったら」という度合いや抽象度が2歩目かな。
例えば「かっこいいものって何？」ってのも「疑問」だ。ただこれに答えるためのプロトタイプは自分には思いつかない。そこでなぜ？を問いつめる。なんでまずそのプロジェクトの中でかっこいいものが必要なのか？ユーザーはそこで何を求めているのか？それが例えば人に見せびらかしたい、であれば人にクールに使っている姿を見せびらかすために何か出来ないか？あーだこーだ、じゃぁこれってどうかな？とかのようにもう少し具体的な「よい」質問を持つ事が出来れば、プロトタイプってのは自然に作れる・・・・気がする・・・
具体的な事が「よい 」ことであるとは限らない。ただ少なくとも聞いている本人でさえ何を聞いているのか分からないような質問は絶対にさけるべきだと思う。

「形にする」っていう段階でかなり前進する。ただそれはプロトタイプの限界の章でも述べたように多少危険でもある。（何が危険かはプロトタイプの限界読んでください。。。）良い疑問やよい問題意識を持つ事はプロトタイプを作る上でも、プロジェクトを進める上でも重要になってくるのだ。

正直この記事は実体験に基づいている訳でなく、このように思って進めてきた、という心意気のようなものなので物足りなかったかもしれません。申し訳ないです。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

ユーザーインタビューとその限界

ユーザーインタビュー・・・ME310の中でそれらは何に使われていたか？
それは時にユーザーについて学ぶ事であり、それは時にペルソナを作るための過程であったり、様々な用途に使われユーザーを理解するのにとても役に立つ。
まーとにかく、ユーザーにインタビューすることは何らかのプロジェクトをデザイン的なアプローチのもと進めていくには必要不可欠だと思うんですよ。
これと微妙に似て非なるものが「アンケート」これについてはどっかで書こうかな・・・って感じです。ただたいしたトピックにはならないです。用はexplore な感じがインタビュー。analyze な感じがアンケート。自分から新しいトピックを作り出すためにアンケートは用いられないし、「何割の人がこういっているからこれはだめだ」という考え方はあまりにデザインとかけ離れていると自分はとらえる

そんなインタビューも私の考えからすれば限界があるのですよ。
僕らのチームの行ったインタビューにはいくつか種類があった
1. ノーマルユーザーインタビュー
2. エキスパートインタビュー
3. エクストリームユーザーインタビュー

結構聞かれる事があったのでそれぞれの言葉の説明

ノーマルユーザー: 普通のユーザー。トピックを考える上で真っ先に上がるような人のこと
エキスパート: その道のエキスパート。専門家。
エクストリームユーザー: 専門家と勘違いしてしまう人がいるかもしれないけどこれはあくまでユーザー。その分野で特殊だと思われるユーザーの事

具体的な例を示すと・・・たとえばトピックが空港だとして
ノーマルユーザーは自分とか他のごくふつーーーーーに空港使う人
エキスパートは空港で働いている人とか、空港立てた人とか、航空を専門に勉強している人とか
エクストリームユーザーはたとえば月に５０回くらい空港を使う人であったり、空港なんてぜっっっったいに使いたくないと考える人であったり、飛行機の種類とか全部言えるような人だったり、何十カ国も飛行機で旅しているような人であったり

それらのインタビューで得られるものはもちろん違う。
1 のノーマルユーザーへのインタビューは、そのトピックに対してどのような考えをもってどのような態度をとっているか、について聞く。ある程度クラスター化（グループ化）出来るくらいたくさんの人に聞くのが望ましい。またそのトピックに対する問題点等を発見出来る

2. のエキスパートインタビューは例えばどのようなところでどんなテクノロジーがあるか、やそこにどのような問題があるか、 今何が行われていて何が行われていないのか、それらを把握するのにはもってこい。また専門家ならではの視点から様々な知見を得る事が出来る。

3. のエクストリームユーザーは専門家とはまた違う、またノーマルユーザーからは得る事の出来ない、もしくはノーマルユーザーの気付かない問題点を発見するのに役に立つ。自分の知らない知識とかエキスパートとはまた違う視点を持っていることが多い

これら全てのユーザーインタビューはそれぞれ等しく価値がある。
ただ強いて言うなら、インタビューは現状を理解する上でもっとも役に立つもの。
ここから問題点を発見するのは案外難しい。

とくにノーマルユーザーから聞いた話から問題が見つかっただけで喜んでいてはもーだめなのである。インタビューで聞ける内容は、個人が頭で意識している内容のみであるからだ。（もちろんインタビューを上手く行えばそれを引き出す事も出来るのかもしれないが自分には出来なかった）

問題ってのはいろいろある。その中で個人が、特にノーマルユーザーが把握している内容等価値はほぼないに等しいと言っても良い。ここでの価値とは経済的な価値である。もちろんプロジェクトを進めるにあたってそれらの問題を頭に入れておく事は非常に重要。ただそのくらいの表面をなぞっただけの問題点など誰もが気付いている事なのだ。

エキスパートとのインタビューは個人的な見解では「社会的プロブレム」（社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜 参照）やその分野の会社の抱える問題点を発見するのには役に立つがエキスパートはあくまでエキスパートであり、ユーザーではない事に注意しなくてはならない。そこからユーザー起因の問題を発見する事は若干難しい

上の2点とは違い、個人的にはエクストリームユーザーへのインタビューはおもしろい問題を発見するためには非常に役に立つと思う。たくさん使うからこそわかる問題、いろいろ知っているからこそ分かる問題、まったく使わないから感じている恐怖などノーマルユーザーの気付かない、つまり世の中の９０％の人は気付いていないような問題点をかれらは頭で知っているのだ。
ただそれでもやはり頭で意識している内容のみしか聞き出す事が出来ないので自分でも気付いていないような問題、インサイトは得る事は難しくなっていることが多い。


と、ちょっと強めにいってしまったのだが、プロジェクトの進め方はもちろんいろいろある。ある程度明白な問題をすばらしいソリューションを用いて解く、これもイノベーティブになる可能性はある。そして誰もが見つけられなかった問題を解く、これもイノベーティブにはなりうる。ただもしも後者の形でプロジェクトを進めたいのであれば、ユーザーインタビューよりも個人的にはインタビューに加えて、「観察」を行うべきだと思う。

観察の仕方はそれぞれ。ビデオをとって人を観察しても良い。自分自身がユーザーになってみるのも良い。写真をとってその写真をみてあれこれ言い合うのも良い。共通なのは要は、現場に行けという事。
たとえば下の写真は自分が旅行しているときに見つけたブロブレム。おそらくインタビューからではえる事が出来ないものである。

問題？って感じかもしれないけど８割がたの子連れの家族はこのように家族を引いている。まぁいいけどさ、この空港の荷物運ぶやつをデザインするのもある意味チャレンジであり面白そうだと個人的には思っている。（ちなみにアイディアブログの方にその問題をとくアイディアを出しました）

最後までおつきあいありがとうございます、といいたい所なのですがもう一言付け加えておきます。
「有言実行」という言葉がいつしかかっこ良く見えてしまうほど、いった事を実行するのは難しい。たとえばリサイクルについて人にインタビューしたとする。そしたらその人は100点満点の答えを出すだろう。ただ実際は？と聞かれたらそれを実行している人は滅多にいない。車を運転しているときに自分が一番不安なシチュエーションは？と聞いたときに携帯を打ちながら運転している時、とは誰も答えないと思う。事故の何割かはそれが起因しているにも関わらず。むしろそのくらい運転に慣れた人ならどこにも不安はないと答えるのが普通なのだ。

インタビューはもちろん強力なツールである。しかしよりよいインサイトを得るためにはインタビューだけでは物足りない。観察とインタビューとを混ぜてこそ、良い物が生まれると私は考える。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

ブレーンストーミングについて

ブレーンストーミングについて。ブレインストーミングの方がいいのかな？

この記事では個人的にブレストを左右する３つのトピックについて書いていきたいと思います。もちろんブレストを左右するものはブレストのお題であることも分かるのですがそこには触れず。今は書いてはいないのですが「プロジェクトの種類」って記事でもしかしたら触れるかもしれません（08/July/2011）

以下が書く内容

1. メソッド
2. ツール
3. ナショナリティと言語


1. メソッド
KNLog: イノベーション：ブレインストーミングの一例 の中で書いた話と完全に重複するのですがきちんとした形で記事を残したかったので書いておきます。

まず最初に始めるときに、何となくだけど2種類に分かれる気がする。

「３分間最初自分自身で考えて、それらをどんどんシェアしていこう」
「とりあえず思いつくがままに発言していこう」

個人的には後者が好きかな。何となく最初に考える方では自分のアイディアにスティックしてしまう可能性が高いので。後者の方がお互いにお互いの意見を取り入れて上手くミックス出来るイメージがある。ただそれもメンバー次第だしどっちがいいとは言えない。例えばおしゃべりすぎる人とおとなしすぎる人がいる場合、何となくだけど最初に考える時間をとった方がいい気もする。とりあえず適当にアイディアを出すのが好きな人が多いときとかは思いつくまま発言がいいと思う。それは本当にどっちがいいとかは言えない。



始めて少し経ってから、ブレストをしている最中に話が詰まってしまう事はよくある。そんなときにある程度役に立つ方法を紹介

まず一つ目は、逆の事を考えるという発想。たとえば
「電車でのエクスペリエンスを快適にするには？」とかが課題だとして

椅子を快適にするとか時間を短くするとか・・・いくつか普通に出てくる。ただ何となく悪い例のせいもあるかもしれないけど、うまく掴みづらい感がないだろうか？

そしたら逆にめっちゃ不快にする方法とか不便にする方法を考える

乗り換えの案内がない、臭い、トイレが無い、どこに行くかが分からない、急行とかばっかり、切符が買いにくい、ドアが空かない、電車に乗るときに落ちそう になる、めっちゃ混んでる、出入りが不便、すぐドアが閉まる、バスとかとの乗り継ぎが悪い、家から遠い、山の上にある、川の中にある、階段が多い、うるさ い、自分がどこにいるか分からない、とか何となくこっちの方がたくさん出てくる気がする。
もちろんこれら全てが有用であるとは限らない。ただこれらを逆に「なくそう」とか「どうやったら改善する事が出来るか」を考える事で通常の道を通ったときには思いつかないアイディアが出てきたりする・・・はず笑


もう一つは何かと適当に繋げる、というもの。
これはビジコンとかやってる人には有名なのかな？
たとえばさっきの例で言うと、「電車を快適にする 」それと例えば「携帯電話」を一緒に考えようとか「イルミネーション」を考えようとか「東京タワー」を考えようとか「プール」を考えようとか、「香水」を考えようとか適当に何でもいいので何にも関係なさそうなものをお題に出してやってみる。
ちなみに一度ビールを飲みながらbeer storming を繋げる方法を用いてやった事があるのですが結局アイディアの８割は下ねたかアルコールの話になってしまいましたw

たとえば「携帯電話」だったら乗り換え案内的なものからgps, 眠ってても自分の駅で勝手に起こしてくれる機能とか、なんか一人で考えてもたくさん出てくる
「イルミネーション」道案内ライトでしよーぜーとか・・・
「東京タワー」これは難しいかもだけどランドマークを色んなところに作って待ち合わせを楽にしようとかかなー？まーでも考えればいろいろ出てくるはず
「プール」・・・・水・・・シャワールーム付けとくとか？分からんw
「香水」電車いいにおいにしようプロジェクト・・・(結局汗とまみれて臭くなりそうだな・・・って自分でいってても思ってしまうのですがブレストは基本なんでもあり。自分自身の意見も批判しなくていい・・・はずw)

あともう一つはフレームワークを用いるというもの。
どんなフレームワークがあるかな、とちょっと自分のパソコン探したけどあまり見つからなかったので見つかったらまた載せておきます。
ちょっと適当に書いてしまうので有用かは分からないけど、そのトピックをフレームワークに当てはめて考える事でより深いブレストが出来ることもある
たとえば「問題点」て何だろう
その問題がなぜ問題なのかwhy を５回聞いてみよう
それに対してそれを解く「解法」てどんなものがあるだろう
とか
このトピックのお題って何なんだろう。それのもっと深くに眠っている真相を探ろう、どういう意味でとらえる事が出来るか、どのような側面を持っているかとか
どんなユーザーをターゲットにとしているか、とか
そんなフレームワークを用いる事で円滑にブレストが出来る事もある。

2. ツール
上でいったフレームワークもある意味ツールの一部なのかもしれないけどもっとphysical なツールについて
ポストイットとかホワイトボードとか。
個人的にはペーパーボードって言うのかな。。。でっかい紙がボードにあるようなのが好き。めくってもめくっても紙、みたいな。保存も出来るし消えないし。
ただ今回はポストイットについてその有用性と危険性について述べたいと思う。

ポストイットのメリットはおそらく可動性？とでも言うのかな。意見をクラスター化するのがとても楽。このアイディアはこういう事だなとか、ブレスト以外のプロブレムファインディングのときとかまさにそうだけど、要約するのがとても楽。
デメリットというか危険性については、個人作業の集約になってしまいがちな事。ブレストの一番の売りはdiscussion をdevelop して個人からは生まれないようなアイディアを出していく事。たとえば思いついた事をとりあえず書き出して、あとでホワイトボードにはろうってなってしまうと、アイディアが出来たバックグラウンドも分からなければ興味すらなくなる事もある。そいった意味で上手くコミュニケーションをとりながら、決して個人作業にならないようにポストイットを使っていかないとだめだと思う。ちゃんと自分で何を考えてるのか発言して、こういうアイディアっていってそれについて話し合ったあとにその要約なりタイトルなりをポストイットにかいて形として保存する。そんな感じで上手く使ってかないと難しい><

3. ナショナリティと言語
おそらく日本語でこのように書いてあるブレストの話で世界的な文化的な違いを考慮した記事ってのは少ないんじゃないかと思う。まーそーいった意味でいい記事になる可能性も秘めてたんだけどなー・・・いかんせん文章書くの苦手だからなぁ・・・

正直フランスでの生活で文化の違いはあからさまに感じた。ただそれを「文化の違いだからしょうがない」って形で終わらせてしまうのはもったいない話。理解しようと努力もしたし理解させようとも努力した。最終的にナショナリティてよりはパーソナリティって考えられるようになったのは小さい変化だけど個人的には大きな変化。ただ最後に気付いたのは自分が相手を理解するよりも先に、向こうは俺を理解していた。それはうれしかったけど同時にそれに気付けてなかった自分が恥ずかしくなったりした。

フランスでブレストをする際にいくつかのタイプがあったと思う。もちろん日本的な、いわゆる日本人が考えられるようなブレストをしてくれる人もいたりした。それは当然なのかな。だけど、自分が見た中では２種類の日本ではあまり見ない特徴のあった。

一つ目は、自分の意見にやたら自信持っている人がいる事。こう言うと日本にもいるじゃーんてなるんだけどな・・・伝えるのが難しい。ただ向こうの人は本当に自分の意見に自信を持っている。そしてある意味「自身」も持っている。なんて言うかな。やっぱカラーがあるんだ。そして人によっては気に入らないアイディアにはためらいなくケチつける。それがブレストで掟破りであってもw　それは辛かったな。「それ日本だったらいけるかもだけどフランスではむりだよ」みたいなこと言われたのは本当に辛かった。自分の意見に自信を持っていて、これで行きたいって思うと止まらないんだ。これがいい！みたいな。日本でこんなに主張される事はないから若干引いてしまったりする。んでそれに決まって進んでいったりする。ただagreeable が無い訳ではない。なんというか文句は言うけどもちろん周りの事を考えてくれたりもする。ただやはり自身のアイディアに自信を持っていて、それは本当に日本の姿勢とは違った。
日本の友達から、 どっかの会社では期間を決めて、誰のアイディアに進むかを決めたりもする、という話を聞いた。誰も意見を曲げないからこの期間は誰々に従う、この期間は誰々に従う、的な。ある意味柔軟というかなんと言うか・・・

もう一つは、議論を積み上げない事
自分が理系の大学から来てるかもしれないけど、フランスでのブレストはとにかく話が飛びやすく感じる。というか議論をすると穴があるような気がして気持ち悪くなる事がある。ブレストだからそれは良かったりもするんだけど、ただ、え？それは次のフェーズでしょっていう議論までそこから発展してしまう事がある。日本人がゆっくり積み上げていって体積のある議論であるのに対して、もうちょっと直線的なイメージかな。
正直自分がよくブレストした人たちはコンピュータ大好き人間でそこまで議論が弾んだりはしなかったけど、他の日本人の話を聞いたり周りを見ているとしていると本当にこんな感じ。

うまく説明出来ないな。ただ明らかに違う。これは慣れるのに本当に苦労した。冗談とかもうまく掴めなかったりしたし大変だった。
あとはやたら集中力のない人がいたりとか、議論の外側の人が話を遮るのに躊躇しないことが多いとか、そゆのは結構ある。

あと苦労したのは言語かな
向こうでは英語を話してた。コミュニケーションは普通にとれる。自分の思っている事もしっかりと伝えられる。ただ自分の伝えたいものってのがどっかにあって、それを湾曲的に？比喩的にとか直線以外の方法で伝える事が出来ないから説得するのにすごい苦労した。上手く伝えるために絵を描いたりとかいろいろ話の道筋を準備したりとかしたのはいい思い出。


あとはなんか他にもいろいろ工夫した事もあったんだけどなぁ
繰り返しなんかを言うとか司会者を日によって変えるとか上手く人に振るとか細かいところだけどやっぱりメンバーによって工夫していかなきゃ行けない。ブレストってのはただの手段でしかないからな。目的を達成するためにその形は変えていくべき

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

プロトタイプは状況に応じて時にラフに、時に詳細に

プロトタイプってのは、まぁそれはテストをするために用いられる題材を呼ぶ訳ですけれども・・・ME310の中では、
「to answer the question」

という認識で統一していた。(a か the かは正直定かではないw)
プロトタイプの目的ってのは、プロダクトに似てるものを作る事ではない。
何かの疑問を解決するために作るものなんだ。

ちなみに下の画像は昔ペーパーバイクプロジェクト（紙素材だけで人が乗れて人が押せる／引ける乗り物を作ってゲームして遊ぶプロジェクト）を行ったときに作ったプロトタイプ

ここでの疑問は「このタイヤほんとに人を支えるだけ強いの？」
でした。ショッピングカートの下にタイヤつけて、その中に人入れて押したりするだけのプロトタイプ。まー単純だけどプロトタイプとしてペーパーバイク全てを作る必要はないしテストしたい部分だけを作ればいい

このプロトタイプだと「人」のテストが出来ていないのでちょっと説明しづらいけど、こゆプロトタイプって「対人」の時にもっと強くなると思う

次の写真は分かりにくいけど、これはユーザーに水の使用量を見せる事で、ユーザーに出来るだけ水の使用量を抑えさせる試み。横にボードで1l, 2l, とか使った量が簡単に分かるようになってる。

ここでの疑問は「フィードバックってエコ活動する上で役に立つの？」というもの。


log(shogo807) でも紹介されてたIDEO がデスク周りにあるものだけで作った医療器具のプロトタイプをご紹介
記事の中にはこう書かれている

IDEOが以前行った医療機器に関するデザインプロジェクトのブレインストーミング中、あるデザイナーは近くにあったペンと消しゴムとテープを使って簡単なプロトタイプを作りました。こうしたアイデアの可視化は議論を一気に加速させます。

画像はIDEOを超えよう(1)というブログからはらせていただきました

ここでのプロトタイプは上で書いたのと若干違うかもしれないけど、クライアントと話をしている際に、「今望んでるものってこういう感じ？」といって洗濯バサミやらなにやらを用いてこれを作ったと聞いた。これも「疑問」ではある。こゆプロトタイプをたくさん作ってどれの、どのような面が気に入ったか？と聞く事は確かなプロトタイプ

「プロトタイプの限界」 って章ではプロトタイプを行う際の問題点を出すつもりだけど今回は正しいプロトタイプの作り方。


どっかの研究で、そのプロトタイプが綿密に作られていれば作られているほど、ユーザーからのフィードバックもよりdetail になるという結果が得られた・・・って誰かがいっていた気がする・・・

でもそれは確かに自分たちでやっていても思った。たとえばこのバケツでの汚いプロトタイプのときには、ある程度自分たちの疑問に沿ったフィードバックを貰えた。もちろん水が限られているのが分かるからさらに焦った、とかいう unexpected なフィードバックもあったりしたけどそれもなにげにヒントになったりはする (これについては build to think, think to build で話す)
ただこれを、例えばArduino とか iPad とかを使ってかなり綺麗に、ほんとうに最終プロダクトみたいな形で提示したときにはユーザーのフィードバックは「かっこいい」とかに始まり「ここのインターフェイスが分かりづらい」とか「これどういう意味」とか、焦点がどんどん詳細な部分になり、自分が持っていた疑問とは違った分野のフィードバックが主体になってしまう事があったのだ。もっといえば「ケチつけるのが申し訳ない」とまで思わせてしまうような自己主張の強い、もしくは完成度の高いプロトタイプになってしまうと、もはや何のためにプロトタイプをしているのか分からなくなってしまう。

だからこそプロトタイプを作るときにはまず始めに「疑問」を持つ事から初めて、それの疑問に答えるためにはどのような形のプロトタイプが必要か、という事を考えなくてはならない。タイムマネジメントの事も考えれば更にムダはいっさい省いて、as fast as possible で作ることが望ましい。ただそれを考えなくても、疑問と関係のないfunction や見た目の美しさなど考慮することは「しない方がいい」のではなく「してはいけない」のだ


５分で作れるプロトタイプは５分でテストしろとも言われた。
そしてたくさんいろーんなタイプのプロトタイプをし続けて様々なインサイトを得る。インサイトをゲット出来ればファイナルプロダクトも自ずと見えてくる・・・はず

ファイナルプロダクトのイメージをクリアにもてば持つほど、人はモックアップを作りたがる。ただ正直に言わせてもらえば、モックアップは疑問を解決するためにはあまり役に立たないと思う。ただ作ったって自己満で終わる。

もちろん最終的にdetailをつめるときはある程度ファイナルプロダクトに近いものは必要。そこでdetailを考える事もかなり大事。ただcritical な部分では、モックアップは必要なかったりもする。
他の事に時間をたくさんかけるために、プロトタイプは極力シンプルに。
もちろん何をテストするかによるのは言うまでもないだろうけど。

もう一つシンプルにする理由もある。頑張って作ったプロトタイプってのは失敗を認めたくなくなる。失敗したら重要な要因だけ頭に入れてバイバイって言えるくらいのプロトタイプが、個人的には望ましいと思うんだ。

ただ正しいプロトタイプの作り方、ってさっき大きく書いてしまったけどそれは間違い。もちろんプロトタイプに正解なんてないし、１つの疑問に対して１００個くらいおそらくプロトタイプの仕方なんて出てくる。。。。（かも知れない）
でもプロトタイプはあくまでプロトタイプ。それによって何か意見を貰わないと。もしくは何かを発見しなくては意味がないのだから「文句無しのもん作ってユーザーとか上司に文句言わせないようにしよう」って下心がちょっとあったら、その心は見直されるべし。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

ペルソナの必要性、意義と強み

ME310 のデザインシンキングのプロジェクトに参加して「ペルソナ」ってのがまーある程度よく出てきたのでそれに対する考えをまとめたい。


「デザイン」をやるにあたってペルソナってのは大事だ


ってよくいわれるっぽい。

web設計なんかでもいわれているはずだ。

ただ正直、プロジェクトが終わった今でも、ペルソナ？ってなってしまう感は否めない。
少なくとも今、何も調べていない段階で自分がいえるペルソナの強みは３つ

• ユーザーの把握
• シナリオのリアリティ。
• 情報伝達性

1. ユーザーの把握
自分たちがペルソナを作ったのはユーザーをリサーチした結果ペルソナ作らなきゃいけないっぽいからその結果使って作っとくかってなった。ただ逆に、ペルソナを作ろうってなっても同じような事をしていたと思う。観察、インタビュー、テスト、アンケートなどなど
自分の今行う分野にどのような人がいて、何かしらトピックに対してどのような態度を持っているのか、どのような事をいままでしてきたか、などを聞いていく。これによっていくつかのユーザーのパターンが出来上がるはず 。
それらを上手くまとめあげたものがペルソナ。
だからユーザーリサーチとかが身に付いてない人に、ペルソナは大事なんだ！だからやれーって言えば、嫌がおうにもユーザーリサーチとかはするようになるのかもしれないとは思う。
ただこの時点でも写真まで使う必要はないのでは？とは思ってしまうかもしれないけど・・・

2. シナリオのリアリティ
何か新しいものを作ったときに、それは３行以内くらいに説明出来る事が望ましい。とはよく言われる。ただ詳細に説明したい時、特にドキュメントやプレゼンテーションのdetailの部分ではそうはいかない。
そんなときに力を発揮するのもペルソナだと思う。
こういうユーザーの場合はこういう事が出来て・・・こういうユーザーの場合はこれが・・・とかポストイットとかに書きだすだけでも出来なくはない。
けどユーザーがその新しいものとどう関わるかやそれにより何がどう便利になるかとかは、ペルソナとシナリオを考える事でもっと上手く説明は出来るし、詳細まで考える事が出来る。またそれぞれのシナリオを考えたときに何となく上手くいかなそうな部分とか矛盾する部分とかそういうのも出てくる。そこからまた上手くいかない部分を修正する事が出来たりもすると思うし、detail までつめる事が出来る。まーここまでいくとペルソナの話でなくシナリオの話になってしまうのだけれども、シナリオは個人的な意見としてはペルソナ無しには出来ない。

3.情報の伝達性
誰かに伝える時、もしくは同じチームメンバーと何かをシェアする時、ペルソナがいなかったら誰がユーザーかも分からず、ある程度分かっているにしても完全に同じマインドセットになる事は難しいと思う。自分で何かを開発したり考えたりするとき、一番分かりやすいユーザーは自分自身。ただそれは他のチームメンバーにとってもそうなはず。それを上手くシェアするためにもペルソナは必要。またシナリオを詳細に伝えるためにも、ペルソナもきちんとしておいた方がよい。そしてペルソナをきちんとした上でシナリオをチーム全体が共有する事でチームとして同じビジョンを持つ事が出来る。


ただ・・・デザインをsympathy と言う人もいた。
確かにそれを哲学として持っている人からすれば、ポストイッ トに書かれている情報の山より もそれをまとめあげ、【人】として見る事の出来るペルソナの方がsympathy は上手く出来ると思う。細かいところだけど、ペルソナの強みはそんなところにもある気がする。常に「人の顔」を見ながら商品を作る。顔色でなくねw

そんなところが自分的に把握しているペルソナの強み・・・かな
たしかに重要そうな内容だけども、たとえば自分に時間がないときにこれをやるかと言われたら微妙かもしれない。


web制作に置けるペルソナの重要性などは
Togetter - 「web制作におけるペルソナの必要性」

ペルソナの必要性を開発者視点で説明してみる - ウェブユーザビリティ.JP

こゆとこに書いてあった。
webだと多少は違うのかもしれないけど、多くは同じかな。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜

Tweet

〜デザインは「プロブレム」を解いて然るべき〜

というタイトルとは違うんです。

今回の話は、「プロブレムとは何か」

ME310のプロジェクトで、自身のプロジェクトは新しい水／ゴミ処理に関するサービスを作り出す事。
さらにそのサービスはグリーンでなければならない、というプロジェクトブリーフを貰った
（ちなみにME310のプロジェクトに興味がある人用に書いておきますがプロジェクトの形は様々です。自分のは多少ビジネスより、他にもコンセプトを作るもの、技術を応用するものなど様々な形のプロジェクトがあります）
プロジェクトを進めていく段階で「プロブレムファインディング」を行った。
ユーザーを観察することで、もしくはユーザーにインタビューをする事でそのトピックに対して人がどのようなアプローチを持っているかを考えるためのもの。
そのプロブレムがいずれ「ニーズ」に変わるための重要な位置づけになるのは言うまでもない。

そこで見つかった問題の一つに
「フィードバック」ってのがあった。
フィードバックがないから、エコ活動が無力に感じる、だからやらない。
「じゃぁフィードバックがあったら人はもっとエコ活動出来るんじゃないか？」
ってのはおそらくエコ活動系のプロジェクトに取り組む人なら誰もが思いつくような話だと思う。
ただ・・・ちょっとそこで疑問に思う。
たしかに、フィードバックを貰えば、人はグリーンに活動する事が出来ていた。それはプロトタイプ等で実証した。（多分探せば研究でもあるはず）
ただそのフィードバックにお金を払う人はどのくらいいるんだろう？？
もっといえば、それをユーザーにとってvaluable であるといってよいのだろうか？？

そこにフィードバックがあれば、人に目的の行動を行わせる事が出来る。ただ、そのフィードバック自体がユーザーの望むものかと言われればそうでもない。


それではなぜ、プロブレムを発見したのにニーズを上手くつかみきれない、そのような「勘違い」が起きてしまったのか？

確かにこのアプローチは「プロブレム」を解いていて、それを解決するためのある意味でデザイン的なアプローチである。
ただここで議論したプロブレムってのは、「人々がグリーンな活動をしていない」という問題。その問題をどのように解くのか？？？

その解はもちろん様々。ただ個人的な見解を言わせてもらえば、そこに問題意識を置く事時点でこれはもはやユーザーセンターのデザインではないのだ。

なぜならその「プロブレム」はユーザーのプロブレムではないからである

それは社会の作り上げた、勝手に言葉を作ってしまえば「社会的プロブレム」。
もちろん責任感の強い人は社会全体の作り上げた問題を解くために努力はする。そこにニーズがあるのもまぎれもない事実である。ただこれと（個人的に）対比させる事の出来るもう一つのプロブレムである「個人的プロブレム」と比べれば、そこに対するニーズの大きさは比べようもないほど違うのだ。

では「個人的プロブレム」とは何か？
それは例えば「お湯が最初でなくて冷たい」とか「ゴミが臭い」とか「ゴミ出し面倒」とかもっと言えば「パスタ作るのに時間がかかる」とか「起きるのがめんどくさい」とかそういった、個人それぞれがいやがるものや苦に思うもの。
デザインてのは「個人的プロブレム」を解いてしかるべきなのである。
個人的プロブレムにはユーザーの「ニーズ」が必ず存在する。
そしてそこにはそれを解くための「ソリューション」もいくらでも存在する。
そのニーズを満たしてこそ、個人的には「デザイン」

そのソリューションの一つとして、「社会的プロブレム」も解いちゃえ、というアプローチが個人的にはとても魅力的なアプローチ。
もちろん答えなんてないし他にもたくさんアプローチはあるけど、個人的なプロブレムを、社会的なプロブレムを解きつつ解決していくって道が個人的にはすきでそんな事ばっか考えてた。

例えばシャワーを浴びるときに最初の１分くらいは水が冷たい。
それをたとえばだけど目覚ましと連携させて起きた瞬間にお湯を最初の一滴からだせるような準備をしておく。（欧米の人は朝シャワーなので・・・）
そしたら最初のシャワーで冷てっってなることがない（個人的プロブレム解決）
そしたら少なくとも１分は長く寝れる（個人的プロブレム少し解決？？w）
そして毎日水の量も１分分は減る（社会的プロブレム解決）
さらにたとえばシャワーを浴びているときにコーヒーの準備でもいいしバスの時間を出すでもいいし、なんかいろいろ手伝える事したり出来たら・・・とか
ちなみに１分水の量が減ったらかなり水の使用量は減るけど、その分電気代とかかかってしまいそうだよな・・・改善が必要な案だけど、なんとなくそんな感じのアプローチ

他にも例えばパスタを短い時間で作れる機械を発明しようってなれば、個人的プロブレムは解決、んで社会的プロブレムも熱的な観点で見ればエコだったりする。

よくわからないけど、個人的にvaluable なデザインってののメインなフォーカスは「個人的プロブレム」に当てていないといけない気がする。


プロトタイプの限界の章にあるように、プロトタイプは形にしたものを改善する、もしくは評価するのはとてもいい。ただそれ自体が本当にいいものかどうかってのは測れない・・・かもしれない。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

最適化とDesign thinking 〜最適化はイノベーティブか？〜

この間の記事にすこーーーし、そして分かりづらーーーーく書いたけど、

Analytical thinkingとDesign thinkingを対局、というか、直交軸で考える人はよくいる。

なんとなく釈然としないが、大まかには賛成だ。

そんでもって今回のお題は

「最適化とイノベーション」
or
「最適化とデザイン・シンキング」


たとえば・・・・レストランの顧客のUser Experience を改善させるためにDesign thinking の考え方を取り入れてInnovative なSolution を出してみよう、という課題があったとする。

（ちなみにだけど、今の文にはかなり日本語として気を使った。Design thinking は使うものではない、というのが自分なりの考えであり、また何かしらの目標があってしかるべきなものとかんがえている。。。まー題名の辞典でメソドロジーと考え方を比較している時点でちょいダメだけど・・・）

実際に頭の中で考えるのでそこまでパワフルというか・・・しょぼーくなりそうだけど、まずは、自分なりにデザイン・シンキングとしてのプロセスを書いてみる。

まずはまーフィールド調査。
多分レストランに行ったことある人なんてほとんどだから、そこら辺をインタビューするかな。なんでレストランに来たのか、誰と来たのか、何を望んでいるのか、などなど

まーここらへんは想像できるっちゃ出来る、どんなのが来るか。
次は、エクストリームユーザーを探すことかな。2タイプ
1.絶対にここに行きたくないって人
・・・を探すのは難しいかもしれないけど、レストラン全般に話を広げれば多少はいる気がする。
2.めっちゃここを使っている人
・・・はまーいそうだね。その人に何が気に入っているのか、とか聞く

あとはまー場所によるけど大人数で来たことのある人とか少人数で来る人とか、かなー

あとはウエイトレスとか働いている人にもおはなしを聞くべきかな。何を注意しているか、とかどんなクレームを受けたことがあるか、とか・・・

あと時間があったり物理的に許されるのであれば、オブザベーションとかで観察もするよな・・・

まーそこからペルソナなりプロブレムを挙げたりする。

正直直感的に、家族とかにたくさんインタビューするのは面白そう。あまり気づかないところに気づきそうだ。フォーカスグループとか・・・




んーーーー一旦ここで細かいことを考えるのを止めてみる。単純に考える。レストランだとおそらく誰もが通る道、というか見つける「問題」は
「待ち時間」だと思う。

それを短くするために頑張ろう！！！
ってなるのは当然の話。

ただそこで、
じゃぁ店のレイアウトをこうして、机をこう並べて、人をここで待たせてお金の払い方をこうさせて・・・

ってソリューションは、まーアリなんだけど個人的には魅力を感じないんだよなー。
イノベーティブか！？って言われるとわからん。もちろんイノベーティブになる可能性はいくらでも秘めてる。ただそれは個人的には「最適化」であって「デザイン」ではない気がするんだよな。。。とても個人的な感想。そのレイアウトのどこに、人が反映されている？って考えると、結局あるのは人は待ちたくないという思い込みだけで、最終的に戦うのは紙の上。。。。目的関数に「時間」をおいた、ただの最適化・・・

多分・・・・まーレストランにもよるだろうけど、待ち時間ってそんなに問題じゃないこともある。ラーメン屋とかなんて、待ってる人が多いほうが魅力的だ。
で待ってる時はいらいらしつつも、期待感は高まったりしてる。そゆ、微妙ないいところもあるんだよね

だったら待ってる時間に如何に期待を高められるか、とかそういう方が個人的には魅力を感じるんだよなー

もちろんそれは人の好みでどっちがいいとかは無いんだけどさ。それに自分で考えるとしたら待ち時間は考えなそう。考えるかもしれないけど、もう少し別の部分を考えるかな。

例えば、車に乗ってくる人とか子供連れで待っている人。勝手な予想だけど、子供を待たせるのが嫌だから店内とか駐車場とかを見て、空いてなさそうだったら帰る、とかあるだろうな。特に店の中なんて見えないことのほうが多いし・・・
そゆ人たちにはただサインを書いておくだけでも違う。入れますよ的な。それがあると人は減っちゃうのかなーって思ったりもするけど・・・

うーーん、でも難しいなー。。。結局自分だったら最適化、に走ってしまいそうだ。それは自分の仕事では無い気はするけど・・・

まーでもなにを求めてレストランに来てるか、とか聞くのも楽しいと思う

日常から離れるため
片付けしなくて良いから
家族でお話しするいい機会だから
誕生日だから
奥さんにお疲れ様、を言うために
etc...


わからない。ソリューションとか


ただ例えば、個人個人を覚えてくれたりして、いつきて何食べた、とかがわかるのもいいかもしれない。あまり話さない家族向けにネ。あの時あれ食べたねーとか、前にここに来たときだれだれと喧嘩してたよねーとか、ちょっとした思い出話を提供してくれるものとか。こんどこれ食べたいから思い出せるようにチェックしとこ、とか・・・なんならもう10年前とかの話しとかできたりしたら楽しいかもなー

まーとりあえずひとりではアイディア出ないな・・・何人かでブレストしてみたい。もちろん、「最適化」は好みじゃない、なんて前置きは無しでｗ

んで早めになんかつくって、いろいろテストしてみるのが大事だな


でもそう思うと、レイアウトを考えたりするのは楽しそう。いろいろテストできるし、分かりやすいinfoは何か、とかいろいろ考えることはできるし・・・


んーーーーー


「最適化」をしよう！ってなったらデザインではない気がするけど、結局そっちに行ってしまうのはデザインな気もするｗ 考えて考えて、ユーザーのことを考えて、つくってテストして、フィードバックもらって・・・

俺がそう思うのはデザイン・シンキングがmindset であると考えているからかな。最適化もデザイン・シンキングの中には含まれるな・・・（個人的に、を強調しますｗ）

ただやっぱ、最適化！っていっちゃうとanalytical な感じがしちゃうんだよな。そうじゃないんだ。人にとって分かりやすい設計はどうか、とかそう考えってったら結局はあるていど最適なデザインになるはずなんだ。ただその最適化の目的関数には「時間」以外のいろんなモノを含めることが可能なんだ。デザインの力で・・・



と今日はそんな感じで結論

一応最後のが自分の結論ですが書いている間に考えがだんだんまとまってきた感じの記事ですので、途中いみぷな部分が沢山ありそうです。すいませｎ＞＜

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

おもしろデザイン｜ガムのボトル

ここにある記事がおもろい

確かに紙を取り出すためにいちいち蓋開けるのめんどいしなー
ゴミを捨てるとこも困ることあるしなー

いいデザイン :)


読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

Design thinking デザイン・シンキングとはなにか

今日の授業の内容は「デザイン・シンキングとはなにか」


まープロジェクトも最後に近づくし。。。。そゆ話題にもなるよな


元々はTim brownが提唱したんだよねたしか。
Design Thinking てarticle でこんな事書いてた。

* A methodology that imbues (しみ込ませる, 吹き込む) the full spectrum (scope) of innovation activities with a human-centered design ethos
* A discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity
* Many of the world’s most successful brands create breakthrough ideas that are inspired by a deep understanding of consumers’ lives and use the principles of design to innovate and build value
* Considering the difference in cultural and social conditions, design thinking can suggest creative alternatives to the assumptions made in developed societies
* Design thinking can lead to innovation that goes beyond aesthetics, but that doesn’t mean that form and aesthetics are unimportant
* It often entails a great deal of perspiration

ヒューマンセンタードデザインの倫理に基づいたイノベーションのためのアクティビティを起こすようなメソッド
またはデザイナーの感性とか考え方を用いて訓練し、それが人々のニーズ、そしてテクノロジーの実現可能性などにフィットするようにとかマーケティングの機会、顧客にとって価値のあるものを提供するためのもの。
とかユーザーを理解する事でなし得るなんちゃらとか
まーいろんな言い回しがある。


それに対してNorman は
そんなの嘘だとかA Useful Myth (ためになる神話)だとか言った。


MEの中でいくつかに分けたグループで一回話しあって、その後にSushiがプレゼンしてくれた。
もちろん「これがデザイン・シンキング」って明確に決めることはできないからいろんな人の説明を教えてくれた。
その説明の中のひとつに面白いのが 2*2 のdimention で

you know <-> you don't know

と

... what you know <-> ... what you don't know

って軸がああってそれぞれの場所を

explicit knowledge, uncertainty, ambiguity, intuition

に分けていた

ambiguity から intuition に行く矢印を design thinking

intuition から explicit knowledge にいく矢印をanalytical thinking としていたり・・・

なんとなくあんまりちゃんと言いたくないというか秘密にしておきたい気が少しあるので図は描きません・・・w

design thinking の対比にanalytical thinking を持って来るって人も居た。
なんとなく賛成できるようなできないような


いろんなdimentions での話になるから、反対というか・・・・図形的に言うのなら垂直に交わっているものはたくさんありそうなんだよな。。。


個人的に、design thinking と対比した考え方はむしろadvertisement やmarketing の考え方。。。
マーケティングまでは言い過ぎだけどなぁ・・・・advertisement は少なくともそうな気がしてて・・・

たぶんそこら辺に関しては
Design thinking and Advertisement | デザイン思考と広告
の中で述べた気がする。。。

analytical thinkingに対して、intuitive thinking と言うものを対比した人もいた。。。ふむ。
そこまで来ると、卒論の時に友達が選んだテーマの
感情的な人と理性的な人のグループワークについての研究とか、まさにこゆのだよな。。。


ちなみに俺らのグループの中ではキーワードとして

What: mindset, process
Who: Human centric, means both for human, and by human, with different background of people
How: User testing, prototyping,
Why: to learn realistic, to satisfy/meet users needs

とかが出てきたかなーwhen と where は省略ｗ


とりあえず、あとプロジェクトちょっとだから頑張ろっと

まとまってない記事ですいません。

ここまではプロジェクト中の忙しい時期に適当にかいてしまったものです。
プロジェクトが終わって、おそらくそれがSushiが俺らに教えたかった事なんだろうと思うものがある。それは「それぞれの人たちにとってその答えが出来た」という事。

自分の中でデザインシンキングとは

Human-centered なview point を持って、User のvalue に着目し、プロトタイプ等を素早く作りテストして、ベンチマークや分析、インタビュー、観察を通じて、様々なバックグラウンドを持つチームがそれぞれの特徴を活かし goal に向かう時に持つためのmindset である
てな感じかなーw
人間臭いく発見された人に起因した問題の人間らしい人に優しいソリューションを出すための考え方。それが俺のDefinition.

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

モックアップとプロトタイプ

いいQuestion を持てば・・・



自ずとそのプロトタイプは見えてくる



・・・・はずw






アイディアが面白くて・・・それをテストしたい・・・


じゃあどうしよう？


とりあえず同じ機能をもったやつを作ってみよう・・・・





とはするべきではないのよね・・・



これがモックアップとプロトタイプの違い・・・・



Sushiがそんなこといってたなー最初の方・・・





ふむ・・・・



何が大事で、何が大事でないか、



どれが大事で、どこに大事な情報が含まれているか。。。




それはよほど勘の利く人か、経験をした事のある人にしか分からない。。。。




気がする