7週目の記事もあるので良かったら読んでみてください。（8週目はスキルウィークで記事書いてません）
Day 36: Low-Fi and Sketches
この日は課題が渡されて、スケッチや簡単な工作で作られた Low-Fi プロトタイプを使ってコンセプトを固める日でした。課題はチーム毎にバラバラで、僕たちの課題は「家での農業」でした。そして、プロトタイプを作る際に気を付けることを教わったので、それを少し深ぼって説明しようと思います。
What do we want to learn?
まず、一番最初に「Prototype = First Example」だと教わりました。まずプロトタイプを通して自分たちのアイディアを Tangible にすることが重要だと教わります。これは CIID で一貫して教わりますが、バックグラウンドや文化が異なる人たちのチームでは、目に見えたり触れられたりする実物はかなり強力なコミュニケーション手段になります。
今週の授業ではプロトタイプの意味を少し拡張させたイメージです。ただ作ってチーム内でコミュニケーションするだけでなく、チーム外からフィードバックを得るところまでが、1つのプロトタイプの役割です。このコミュニケーションとフィードバックのイテレーションを何回も繰り返すのがプロトタイプの目的だと教わりました。
そして、プロトタイプを作るに当たって、意識するべき下記の3つの問いがあると教わりました。
What do we want to learn?（何を学びたいのか？）
What fidelity is appropriate?（どのくらいの作り込みが適正か？）
What can we afford?（どのくらい時間やお金をかけられるのか？）
特に1つ目の「What do we want to learn?」は常に意識するべきだと教わりました。実際に今週を通して感じたのは、「何を学びたいか？」によって作らなければならないものと、作らなくて良いものが明らかになります。実際に作り始めると、みんな作ることにのめり込みすぎて無用に作りすぎてしまうことがありました。なので、僕たちのチームではプロトタイプを作る前に、常にこの問いを忘れないように努力していました。
一般的に初期の段階の作り込み度は低くて、終盤で高くなって行きます。それに伴って、使う技術力も高くなります。予算や期間やリソースを鑑みて、最速で最も簡易なプロトタイプを選択するようにするのが一番重要だと思います。
話は逸れますが、「Fidelity」をどう訳すのかよく分かってなくて、「詳細度」や「作り込み度」と訳してます。何か良い言葉があったら教えてほしいです。ちなみに、今週たくさん出てくる「Low-Fi 」や「Hi-Fi 」の「Fi」は、「Fidelity」のことです。
コンセプトを固める
Low-Fi のプロトタイプの説明で、まず上記の動画を共有されました。Low-Fi のレベルではテクノロジーを使うまでもなく、紙やダンボールで十分だと教わりました。更に、Low-fi で重要なことは最速の方法でコンセプトの全体を理解できるようにすることだと教わりました。僕たちのチームは動画を作る時間がなかったので、スケッチでストーリーボードを描きました。そして、それをもとにコアのインタラクションがある箇所を紙とダンボールで形にしました。
今週を通して学んだことは、Low-Fi のプロトタイプを通してコンセプトを明確にしておかないとこの後のフェーズで議論がかなり行ったり来たりします。そして、コンセプトが明確でないと、プロトタイプするときに何も作れません。「なぜ作るのか？」がなくては、もちろん「何を学びたいか？」という問いも出てきません。初期のプロトタイプの段階では、「なぜ作るのか？ = コンセプト」を明確にすることが一番の目的だと思います。僕たちのチームは、このフェーズを少し怠ってしまった気がします。まずはコンセプトのブレインストーミングをして、ストーリーボードを細かく議論して、今後の軸足を作るべきだったかなと思います。
一応、この段階で「健康意識の高い人向けにスピルリナを生産する」というコンセプトを作ってます。
Day 37: Feedback and Iteration
この日は前日の Low-Fi のプロトタイプを使って、フィードバックをもらって Mid-Fi に昇華させる日でした。そして、Fidelity を変えていくに当たって、気を付けるべきことを教わりました。なので、それを共有しようと思います。
3つの要素
プロトタイプを作る際に気を付ける3つの要素があると教わりました。それらは「Visual（見た目）」「 Functional（機能）」「 Content（内容）」です。この3つの要素の作り込み度をコントロールして、全体的な作り込み度をコントロールします。
例えば、Low-Fi ではこの3つ要素はかなり低くなります。しかし、それぞれの要素が明確になるように意識する必要があります。このプロトタイプが机に置ける大きさなのか、庭に置くぐらいの大きさなのかはコンテキストを考える上で重要な要素になります。重要なのは、コンテキストを理解する上で必要な要素が含まれているかが判断軸になります。また、少し分かりにくいと思いますが「Content」の作り込み度を上げるにはデータを使います。例えば、地図アプリを作ってる場合はその地図に本当の建物や地名を入れるとリアリティを上げることが出来ます。
Fidelity を変える際に、多くのこと同時にテスト出来ないので、一つの要素に集中して変えたほうが良いと教わりました。その集中する要素を選ぶ際には「What do we want to learn?」の問いをベースにして選びます。CIID で行われるイテレーションは基本的に1〜2日の時間間隔です。とにかく、初期の段階は近くにいる人や知ってる人に頼んで使ってもらいます。それで、どんどん初期の段階のフィードバックを溜め込んで行きます。なので、変更する要素は一つに集中するべきで、確実に一つの問いに答えていくように教わりました。
正直、ペルソナではない人たちからフィードバックを得るのは良し悪しあるなと思います。しかし、一番重要なのは、細かい修正のたびにフィードバックが得られるということです。1日や1時間で小さくたくさん変えて、その変更を直ぐに試せて、直ぐに検証できるのが一番良いことだと思います。
最後にエンジニアでなくても、「Functinal」と「Content」作り込み度をあげるツールを教わったので共有します。Figma と Bravo とAirtable を使って、モックアップに機能とデータを追加できます。（Airtable はすごい便利だったので今後も使っていこうと思います！）
Day 38: Experiences
この日は前日の Mid-Fi のプロトタイプを実際のコンテキストに置いて使ってみる日でした。実際に自分たちで使ってみることで分かることあリマした。また、コアインタラクションだけでなく、サービスの一連の流れを考えることで、サービスの不十分な要素が明らかになったりして面白かったです。その際に学んだことを共有しようと思います。
Role play
この日は、まず自分でロールプレイすることにしました。実際に自分たちで使ってみると、自分たちでも案外使えないところがあったりします。僕たちのチームはデバイスとアプリを使う IoT っぽいサービスをデザインしていました。そして、ロールプレイすることで、「いつデバイス使うんだっけ？」や「いつアプリ使うんだっけ？」などのように、自分たちでも明確に出来ていない問題を浮き彫りにしてくれました。
このように、まずは自分たちでロールプレイしてみるのは、インタラクションが明確かどうかを判断する一つの指標になると思いました。それまで、ポストイットやスケッチと空想の中で議論していました。そういう時に、自分たちのデザインの全体をロールプレイして使ってみることで、紙面とは違った観点に気づくことが多いなと感じました。特に、今回の僕たちのチームのように、タッチポイントが別れていたり複数あったりする場合は、サービスが複雑になっていたり考慮が不足している可能性が高いので、ロールプレイの役割は大きいのではないのかなと思います。
Detailed storyboard
詳細なストーリーボードは僕たちのチームで出来なかったことですが、改めて振り返ってこの段階で用意するべきだったなと感じています。
Low-Fi の時に作った粗いストーリーボードはありましたが、Mid-Fi や Hi-Fi になってくると、より詳細なストーリーボードが必要になると強く感じました。特に「Functinal」の作り込み度を上げる際に、詳細なストーリーボードがないと何を作る必要があるのか理解できなく、プロトタイプする際に苦労しました。
実際に、講師からのフィードバックでも「インタラクションを明確にしているストーリーボードを作った方が良い」と言われました。僕たちのチームの場合は、「人とデバイスのインタラクション」と「人とアプリのインタラクション」があり、それぞれを整理して明確にするべきだったと思います。全体感が見えない中で、どこの機能に力点を置くのか分かりにくかったと思います。この状態だと、後になって「やっぱりこれも必要だ」みたいなことが起こりそうで、エンジニアとして怖い状態でした。この時に僕がエンジニアとしての視点で、チームにストーリーボードを作ることをもう少し強く提案できたら良かったなと思います。
ただ、僕はすごく IoT に興味があるので、インタラクションの整理が重要だと分かったことはすごい大きな学びでした。自分でなにか作る際には、この詳細なストーリーボードは必ず用意して、タッチポイントを整理しようと思いました。それが出戻りの少ない開発に繋がると思います。
Day 39: Hi-Fi and Interactivity
この日は Hi-Fi のプロトタイプを作る日でした。前日までのフィードバックをもとにして、完成度を上げることに集中していました。更にこの日はプロトタイプするプロセスの全体感を教えてもらいました。そのことについて共有しようと思います。
フェーズと問いはセット
自分たちがプロトタイピングのどのフェーズにいるかを意識する必要があると下図を使って説明されました。（初日に説明してほしいと思いましたが。。。）
この図は僕のプロトタイプの理解をとても助けてくれました。初期では「コンセプト」をプロトタイプの目的にして、徐々に「インタラクション」「実際のコンテキスト」「実際の使用感」のようにプロトタイプの目的を昇華させていきます。そして、この目的に沿って「何を学びたいか？」を設定して行きます。今回の授業では実装はしていませんが、概ねこの図に沿ってプロトタイプの作り込み度をコントロール出来たと思います。また、最初から、サービスの全てをプロトタイプする必要はなく、コアなインタラクションをプロトタイプした方が早くて的確なフィードバックを得られるから良いと教わりました。
また、自分のどこのフェーズにいるのかを意識するのと同時に、「何を学びたいか？」 の問いの重要性を再確認しました。ここが明確でないと、プロトタイプの力の入れどころが難しくなります。おそらく、初期の段階は全体感への抽象的な問いで十分だと思います。しかし、作り込み度を上げる、時間とリソースの問題で何を作り込むべきかの選択が必要になります。初期は「とりあえず作る！」の意気込みでコンセプトに対するざっくりとしたフィードバックを得るのが、おそらく正しいと思います。そうでないと、初期の段階は分からないことが多すぎて「何を学びたいか？」の問いが設定できないし、プロトタイプ作れないと思います。フィードバックを得て徐々に「何を学びたいか？」の問いと作り込み度の精度上げることを意識することが良いと思います。
Day 40: Presentation
この日は今週のプロジェクトの発表の日でした。僕たちは「Alina」というプロトタイプを作りました。その発表資料を下記に載せておきます。（動画は僕が編集しまいた！）
今週はチームでものづくりしていく難しさを実感したと思います。日本にいた時は、基本的に僕が考えて僕が作っていくという感じでした。チームで考えるとしても僕含めて二人だったり、エンジニアと一緒にディスカッションしたりでした。しかし、今週は4人のチームで4人ともバックグラウンドがバラバラなので、気にする点も少しずつズレていました。この中で共通認識を持ってプロトタイプに取り掛かる難しさを勉強できたと思います。
そして、その共通認識を作るためには、実際に使ってみたり、ストーリーボードを描いたり、ユーザーテストしたりして、徐々に問題意識を揃えていくのが良いのだろうなと思いました。そういう意味で、自分たちのアイディアを Tangible にするというのはコミュニケーション手段として強力だなと感じました。
10週目の記事もあるので良かったら読んでみてください。