デザイン思考 Day10

• Thu, Jul 08 
• 
  
• 06:00  デザイン思考　Day10　フレームワークと要件　クーパーはFace 3でもDesigning for the Degital Ageでも、シナリオから要件をだして、フレームワークを構築しなさいと言う。だが、まず簡単なフレームワークをつくって、実践の中で要件を決め、これを繰り返そう。
•  
• 06:02  というのも、シナリオから要件を作るときに言葉にならない実践が落ちることがままあるからだ。なのでまずシナリオをもとにフレームワークを簡単に作ろう。画面のボタンはどうなっているのか、インタラクションはどうなるのか、データの構造はどうなっているのか、どのような機能をもつのか？
•  
• 06:04  フレームワークはグラフィックスデザイン、プロダクトデザインにも必要だが、この段階ではまずはインタラクションのフレームワークを考える。行為の連鎖を考えて、そのときの画面の遷移をスケッチする。画面がないという素晴らしいフレームワークの場合、センサーとアクチュエーターの関係と状況を描く
•  
• 06:07  このような作業をすすめていくと、ペルソナのメンタルモデル、ペルソナのゴールが甘いな、と感じることがある。そのときは躊躇無く直す。ペルソナが本当は何をしたいのかを明確にする。ヒントは「動詞」を見つけることだ。またシナリオで記述していないことも明らかになる。ここが大切。
•  
• 06:09  フレームワークを考えるときに足りないところを見つけて、要件を徐々に明確にしていく。この段階で新たなシナリオを少し書いてもいい。これをコンテキストシナリオという。利用環境や社会的背景、文化的な背景などを含むが、広く浅く、簡単に書いて、インタラクションの詳細に踏み込まないこと。
•  
• 06:12  そして、ここからが大切だが、シナリオでは最適の道具がある「ふりをする」。これを僕は　クーパーの理論から引用して「魔法のシナリオ」と呼んでいる。君たちのシナリオはいまその段階だ。それをもとに最初のフレームワークを描く。普通に絵に描くのだ。すると描けないところが出てくる。それが要件。
•  
• 06:15  要件は、データ要件と機能要件がある。データ要件はシナリオに登場する人や物や行為の「形容詞」である。機能要件は人や物や行為の「動詞」と考える。魔法のシナリオをもとに簡単なフレームワークをつくり、次に要件を探していく。絵に描くのだが、簡単で言い。詳細なところは未だ分からないからだ。
•  
• 06:18  rationaleを覚えているだろうか。インプットとファンクションとアウトプットを明言したものだ。まずはインプット部分のフレームワークから取りかかろう。ペルソナがどのようにしてファンクションあるいはシステムに情報を入力するのか。そのときの画面は？機器の操作は？そこを定義しよう。
•  
• 06:20  次はファンクション（システム）の定義だ。これは機能要素とデータ要素に分かれる。ここではシナリオに使った言葉ではなく、システムの言葉を使う。データ要素は、写真、電子メール、顧客レコード、等々である。データ要素間の関係も考える。シナリオに当てはめていくとどんどん出来ていくはずだ。
•  
• 06:24  次に機能要素をフレームワークにする。データとインプット情報との関係である。ここにきて、デザインはサーバー内の処理の問題につながっていく。機能要件を機能要素に翻訳する、と呼ぶ作業だ。情報を処理する仕組みやユーザーに情報を提示する仕組みなどである。つかう人に優しい仕組みを目指す。
•  
• 06:25  さて、ここまでで大分絵がたまっているはずである。スケッチングしたものを使ったり、ハードウェアスケッチングしながらインプットとファンクションのフレームワークを定義する。最後はアウトプットのフレームワークだ。ファンクションがどのように人間に働きかけていくかを描く。画面だったり明るさだったりだ。
•  
• 06:28  あつまった絵を整理しよう。クーパーはこれを「キーパスシナリオ」と呼んでいる。ペルソナが製品とどのようにインタラクションするかを描くのだ。そのときに絵で描く。映画のストーリーボードと同じものを描くのだ。絵と言葉を共存させる。この作業を丁寧に行なう。
•  
• 06:29  文字のシナリオが増殖して細部が決まらない。これがよくある失敗だ。丁寧にフレームワークを描き、インプット、ファンクション、アウトプットを定義していく。何枚もの絵が出来る。それをもとにストーリーボードを描く。ここまでがインタラクションフレームワークである。
•  
• 06:32  次の作業がビジュアルデザインフレームワークの確定である。ここではビジュアル言語を創り出さなくてはいけない。センサーとアクチュエーターを駆使すると音とか振動でペルソナとやり取りをする。このばあいは音とか振動のインタラクション言語を作る必要がある。かなり高度だ。
•  
• 06:34  どうやって言語をつくるのだろうか？まずはビジュアルから。色、サイズ、画面のアイコン、アイコンの種類、くらいを決めよう。音や光や振動も同じように考えて言い。難しいところはインタラクションの実践と切り離して考えるところにある。実践の中の状態はready-to-handだ。
•  
• 06:36  だがインタラクション言語を開発するときには、インタラクションを抽象的に考えなくてはいけない。present-at-handの状態にする。ペルソナがゴールを達成するために必要な行動を実行する要素はなにかを見つけ出す。これが言語の単語にあたる。次に要素を組み合わせて目的を実行する。
•  
• 06:38  要素の組み合わせの規則が言語の文法に当たる。これがデザイン言語だ。選んだ要素をフレームワークに当てはめて、使ってみる。これが言語学で言うパフォーマンス。要素とパフォーマンスを参考に文法、言語学でいうコンピテンスを決める。ここは簡単に作業を始めて何度も繰り返す。あせらなくていい。
•  
• 06:40  プロダクトデザインフレームワークを作る事も必要だ。ビジュアルデザインフレームワークを作りながら、並行して行う。インタラクションとプロダクトのコラボレーションを行う。日本の企業は開発がインタラクションのフレームワークをつくり、プロダクトが形をきめて、それからビジュアルを作る。
•  
• 06:42  この流れが一番いけない。ソフトウェアとハードウェアとグラフィックスはお互いの行動をみながら活動しなくてはいけない。そのために早い段階でラフなプロトタイプをプロダクトデザインフレームとして作ってしまう。ダンボールでも良いが意外につかえるのがレーザーカッターだ。さっと形を作る。
•  
• 06:44  つぎは形態デザイン言語を決める。具体的な色や形や材質や仕上げ、を検討する。すでにインタラクションフレームワークがあるのでびっくりするほど詳細に決まるはずだ。とくにデザインの訓練を学部で受けている諸君の腕のふるい処だ。何度も繰り返して言語を開発していく。
•  
• 06:46  この段階で、フレームワークのスケッチ、スケッチを再構成したストーリーボード、ビジュアルフレームワークのデザイン言語を決めた図、ハードウェアのフレームワークとしての簡単な物理的モデル、そのデザイン言語を説明する図、が必要である。しっかりと作ろう。これを何度も繰り返して作業を進める。
•  
• 06:48  このようなデザイン作業は美大で学ぶことと同じだ、と思ったかもしれない。技法としては同種のものである。だが、この技法を活用するまでに民族誌に始まりスケッチを繰り返してきた。君たち自身の内部に豊かなコンテキストが詰まっている。それを前提に目的を達成する実践を行う能力もある。
•  
• 06:50  ここまで自分自身を変えた上で、デザインを行うのだ。これが開発の上流過程でデザインを行う意味であり、実践としてのデザイン思考の価値だ。またすでにTinkeringの能力のある諸君は、デザインフレームワークを決める段階で多くのインタラクションのtinkeringもおこなっている。
•  
• 06:52  すでに、ハードウェアやソフトウェアでもスケッチをしている。これもフレームワークとしてまとめておこう。このフレームワークを実際に作ってみる。これが動的コンセプトの作成であり、プロトタイプの構築なのだ。ここが来週の課題となる。では9時からの授業で会おう。（完）

Powered by twtr2src.