「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 を通じて自分なりのまとめ] の中の１記事です）
読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓
0 件のコメント:
コメントを投稿