HCDの理解2011[初級編Vol.5] ペルソナ／シナリオ法

HCDの理解2011[初級編Vol.5]　ペルソナ／シナリオ法　構造化シナリオ法とペーパープロトタイピング　に参加しました。

今回はお盆前でバタバタしていたこと、自分の仕事環境が変わったことなどもあってブログ更新が遅くなってしまいました。

またセミナー開催日が月に一度の出勤日で、午前中の営業会議に出席した後早退させてもらい大急ぎで会場に向かうという強行軍。結局座学には間に合わず、WSの途中からの参加。到着したらすでにWSが始まっていて、チームのメンバーが頭をひねっているところでした。

ただでさえハードな内容なのに今回は２回分を１回でこなさなければいけないことと、先生の講義を受けられなかったことで状況や内容を理解するのに相当時間を要し、少し残念な立ち上がりとなりました。



バリューシナリオの設定

前回作成したペルソナシートを元に起こりうる状況を想定して、ペルソナの行動特性をもとにした、より具体的な状況（シーン）を３〜４つ設定します。

このあたりの設定は、まずビジネスニーズ有りきだろうと思いました。ペルソナを作っている時も感じましたが、結局ビジネスニーズがないと僕らの判断や想像で済ませてしまうことが多くなってしまいます。課題となるサイトを設定した時点で、事務局側でビジネスニーズも設定してもらったほうが色々スムーズに行くだろうと思いました。



アクティビティシナリオ作成

アクティビティシナリオは、バリューシナリオ設定で作ったシーンを掘り下げたもので、シーン→アクティビティシナリオ→タスクの設定という流れで進みます。ここまで来ると第３回の内容とつながってくる感じがわかりました。

また、タスク設定にインターフェイス用語を使ってはいけないというのが面白くもあり、納得できるものでした。WEBを使ってきた人はそれを中心に考えがちでそれが問題になるとのこと。またアクティビティシナリオは時代を超えて不変のもので、メディアや媒体を置き換えても成立しなければならない。この二点は非常に勉強になりました。



インタラクションシナリオの設定

アクティビティシナリオとタスクの設定が終わると、本来ならインタラクションシナリオの設定に入ります。しかしWEBの場合は必要ないとのことで割愛。プロダクトの場合はここもしっかりやるようです。



ストーリーボードの作成

タスクをもとにUIをワイヤーフレームで制作し、使用感や問題点などをチェックしていきます。IDEO社ではできるだけラフに作ったほうがデザインの本質が分かりやすいと言っているというお話がありましたが、先生がラフと雑は違うぞーと仰っておられました。ラフと雑は言葉にすると違いがわかるのですが、実際は意識できてなかったのでこれも勉強になりました。

また本来はタスクの数だけ作るとのことですが、時間もないので１つだけ選定してストーリーボードに落としこんで行きました。その後ウォークスルーもするとのことでしたが、先生が徐に近づいてきて前触れ無く講評を開始し、全チーム終わったところでWSも終了となりました。



まとめ

とにかくこのセミナー・WSは時間が足りませんでした。先生にわざわざ足を運んでもらわなければいけない点や、参加者数の問題等もあるので仕方のないことですが…。

しかし時間をかけたからと言って一度の受講で理解できるようなものではなく、実務に落としこんでいくうちに徐々に身につくのだろうと思いました。とにかく「一回やっとく」ことが重要で、学ばなければいけないことがわかった、ということが最大の収穫だったと言えるかも知れません。それにカードソートを繰り返し行なったことで、カードソートの重要性について実際に理解できたことも大きかったです。

HCDはWEBに限定されるような知識ではなくて、とにかく使う人の事を中心に考えるというもの。学生時代プロダクトデザインを学んでいた頃にはバリアフリーからユニバーサルデザインに、と言っていた頃だったので当時はまだこの考え方は広まっていなかったのでしょうが、時間に余裕のある学生のうちに何周かやっておくと非常に勉強になると感じました。

もし今年まとめのセミナーが開催されるのであれば、ぜひ参加したいと思っています。

HCDの理解2011[初級編VOL.4] ペルソナ・シナリオ法

HCDの理解2011[初級編VOL.4]　ペルソナ・シナリオ法　に参加してきました。

毎回思うのですが、このWSはとてもハード。初めての僕らにはとにかくわからない事だらけ。どうしても上手くやろうとして、時間をかけすぎてしまったり、浅野先生に注意されたり。しかし回を追うごとにやり方というかペースには慣れてきてる気がします。

まずは座学からです。こちらもスピード感満点。あとで復習することが大前提になります。今回は割と早く振り返ることが出来ました。

ペルソナ／シナリオ法はHCDプロセスのひとつ

ユーザーは誰か
曖昧な特定では対象ユーザーの共通認識が出来ない。そんなユーザー像のことを「ゴム製ユーザー」と呼ぶ。

• ソニーでは「若者向け」のデザインを35〜45歳までの間させない。35歳から45歳の間は自分のことを若者だと思っている可能性が高いが、現実には違うことが多いため。45歳を超えると、自分の子どもが若者になっているので自分と違うことが認識出来る。

たったひとりの為にデザイン
最大の人間に対応すると、機能が多くなりそれが障害となる。100%の人より10%の人を100%満足させる。結果、それが大勢の人を満足させることにつながる。

• CAのキャリーバッグは昔CAのためだけに作られたものだが、今や全世界に広まり便利に利用されている。
• ポスト・イットは聖歌隊員がしおり替わりに使い始めたものが広まった物。
• ウォークマンはソニーの社長のために作られた物。

ユーザーは誰
狙いのユーザー像を明確にする
商品評価を行うのは人。売れる商品を作るためには、その人を知り、開発者間で共有する必要がある。

• 不明瞭なユーザー：開発者（自分）がユーザー
• 厳密なユーザー：ペルソナがユーザー

ペルソナが目指すゴールを決め、そこまでのシナリオを考える
Goal-Directed Design／目標主導型設計

ペルソナ手法の背景

• 暗黙の了解をなくす
• 外化することによって共通認識とし、ぶれないユーザー像とゴールへの道筋を作ることが必要

ペルソナ手法の利点
ユーザー情報の理解
異分野間でも共通認識を持つことができる
声の大きい人ではなくペルソナを基にユーザー評価ができる

• ペルソナは打ち合わせに持っていく
• 人形を使うのも良い
• 日本人はペルソナを使うのが下手→ペルソナ／シナリオ法がダメという結論に行きやすい

ペルソナの作り方（以下は座学の内容にWSの感想も交えていきます。）

• ビジネスニーズに沿ったターゲット層の情報が必要
• 今まで蓄積したマーケティングデータからインタビュー対象を選定。しかし制作会社にはそのデータは回って来づらい。

１）6〜7名のユーザーを抽出し、約２時間程度の観察・インタビューを行う

• ユーザーは自分自身の潜在ニーズを説明できない
• 慣れのないうちは大きな視点で見るが、慣れてくると細部を見るようになり構造的な問題を発見出来ない

僕は今回の課題サイト「名古屋市科学館」のビジネスニーズにマッチするセグメントなのでしょう。インタビューを自チームと他チームの２回受けました。なので、インタビューする機会はありませんでしたが、インタビュアーの方の違いを感じられて、それはそれで面白かったです。あとから考えるともう少しこういう展開で聞いたらいいのではないか、といった感想も持ちました。

※インタビューは「なぜ？」を５回聞く！理由までしっかり聞かないとラダーアップを始めたときに在り来りな結論に達する。



２）集めたデータから重要な内容をポスト・イットに書き起こす

• 事象をポスト・イットに書く際には単語で書かず、情景が浮かぶように理由等も含めて文章化する。

最初のうちはついつい事象だけを書いてしまいますが、他チームに対する先生の注意の声で自分たちの書いている内容を見なおして、これじゃマズイという感じに修正していきました。


３）データをグルーピングし、ユーザーのタイプに分ける。各人物像の骨格をまとめる。

• ラダーリングをする
• 今回はラダーアップを実行
• ビジネスニーズがあれば、そこから落としこむラダーダウンも併用する。
• 階層を「ユーザーの事象」「ユーザーの行為目的」「ユーザーの本質的要求価値」の３つに分ける。
• ユーザーの本質的要求はそのままアクティビティタスクになり得る。
• 上手くラダーアップできない場合は事象が曖昧。インタビューが聞き足りない。

カードソートの１種と考えていいのでしょうか。しっかり事象を見つめることで、本当に本質的要求が見えてきました。僕らの導き出した本質的要求は「子供と一緒に趣味を楽しみたい」「手間をかけずに効率的に子育てをしたい」「子供にとって良い親でありたい」の３つ。僕も気づかなかった親の気持ちに迫っているのではないでしょうか。


４）表現を肉付けし、一貫性のある人物像としてペルソナを完成させる。

• ユーザーの基本情報と本質的要求がわかる。
• ビジネスニーズがないと作れない？
• ビジネスニーズに照らして調整。属性の近いユーザーを統合する。

ペルソナシートを作ります。しかし今回はビジネスニーズについて触れる機会がなく、僕達の判断でペルソナを作りました。
ここで感じたことは、ペルソナは上記のプロセスを踏むと勝手に出来上がるものでは無いのだろうということ。
ビジネスニーズに沿ったペルソナを能動的に作る過程で、開発者の価値観のみが反映されたものにしないようにするために、様々なプロセスを通過する必要があるのかなということです。



後日ツイッター上で浅野先生がおっしゃっていましたが、人間は１回では18%しか理解出来ないそうです。このWSを１周だけやって業務に生かせるかというと微妙ですが、参加するのとしないのでは、ものの考え方に大きな差が出るだろうと思います。本当なら来年も１周受けてさらに成熟させたいところですが、開催が危ぶまれています。もし開催されないなら残念。


その他メモ

• ペルソナを幸せにする＝コンセプト
• 非構造化インタビュー
  「最近どう？」のような質問からラポールを形成し、有用な情報を得る手法。時間がかかる。
• 半構造化インタビュー
  最初の質問を間違えるとすべてがだめになる
• ユーザーを調べればOKという訳ではなく、ビジネスニーズがわからないといけない
• 技術的シーズ＝「うちにはこんな技術があるからこんな事をしたい」

考具 ―考えるための道具、持っていますか?

だいぶ前になりますが「アイデアのつくり方」に続いて読みました。
以前アップした「アイデアのつくり方」でざっくり理解して、こちらで具体的な方法を、という順番で読めたので、すっと入っていく感じでした。

「天才」と呼ばれる一握りの人をのぞいて、人間はあまりに自由すぎるとかえって自由な発想をしにくいと思います。制限があったほうが焦点がぶれなくてまとまることが多いように感じますが、この本はそういった「少しだけ制限を与えてくれるもの」を多く紹介してくれています。

もちろん業務で既に使っているようなものもありましたが、方法や狙いなどを再確認する意味でも、読んでよかったです。実際に早速実務に役立てることができました。紹介されているものを全部使うのではなく、まずは自分に合うと思えるものから試していくといいかも知れません。



アイデアマンになれるかどうかは後天的
置かれた環境よりも自分の意識のほうが大事
アイデアが出るか出ないかの違いは、意識しているかどうかの一点のみ



1章　アイデアが企画になる、アイデアが企画としてまとめられる

アイデアと企画は「What」と「How」で成り立っている「何を」「どうする」をセットで考える習慣を持つ

• アイデア・企画を考える順番を知っておく
• デザインは「わがまま」→「思いやり」
• 最初から相手に合わせてしまうとアイデアがショボくなる
• アイデアとは自由奔放な発想
• アイデアとは既存の要素の組み合わせ以外の何ものでもない
• 少しだけ新しくても「新しい」
• アイデアは企画の「素」であり、アイデア＝企画ではない
• 量が質を生む
• アイデアは1行でいい
• くだらないことも全て紙に書いてみる

アイデアをフィージビリティスタディしたものこそ「企画」
企画とは予算と準備と時間さえあれば実現できる目処が立つ計画
「企画書」に新しいアイデアが含まれていないと「新しくない」
ひとつの企画が新しいアイデアばかりで構成されている必要はない

情報が入る→アイデアを拡げる→企画にまとめる
アイデアが企画につながる頭の使い方は「拡げて絞って、また拡げて絞る」




2章　どうしたら「必要な情報」が入ってくるのか
まず、今集めたい情報は何か、何を解決しなければいけないのか、をメモする

考具１　カラーバス

• 「今日の色」を決め、その色のものが何かを見る
• 「見る」以外のことをする必要はなく、一度しっかり意識したという事実でOK
• カラーバスは注目する視点をいつもと違うジャンルで絞ると発見の幅が広がることを教えてくれる
• 色だけでは飽きるので、「形」「位置」「音」等何でもOK
• アイデア・企画を考えることにおいては「すり替え」「言い訳」「ほんの少しの強制力」がとても力になる

考具２　聞き耳をたてる

• 人の話を聞くことのもうひとつの効能は、他の誰かの生活をほんのヒトコマだけ共有できること
• ちょっとだけ目を向ける、耳を立てる

考具３　ちょいメモ

• なんとなく気になったものだけをちょこっとメモる
• メモする効能は頭の中にあるものを外に出すことにある

考具４　七色いんこ（誰かになりきること）

• 「考える」という概念の中に「実際に体を動かしてみる」を含める
• 自分と違う立場・ポジションを出来る限りなりきって疑似体験する

考具５　フォトリーディング

• 読書の定義を変えること
• 自分にとって大事と思える情報を探す
• 何度も目を通しておくことは大切

考具６　臨時新聞記者（現場・取材　中学生に説明できるまで理解する）

• 課題解決のヒントを求めて現場に行く
• 自分の実感としての知識・記憶があるかどうかはアイデアの爆発に決定的な差を生み出す
• 分かりづらい話は自分自身にとってわかりやすい方法、エピソードで理解する
• 分解してしまう　「分解」のあとに「選択」と「集中」
• 現場を知っていると企画に説得力が出る、プレゼンの迫力が違ってくる

３章　展開・展開・展開　アイデアが広がる考具

1. 普段からアイデアのネタ元を色々貯めこんでおく
2. 目の前の課題についての特殊知識や必要な情報をさらに頭に入れる
3. 貯め込んだ中から使えそうなネタ元や情報を引っ張り出す
4. 引っ張り出したネタ元、情報を組み合わせてアイデアを生む

※特に１と３が大切

考具７　アイデアスケッチ（手書き）

• 「こうなったらいいな」の形状やシーンを思い浮かべる
• 自分が想像できないものを実態として存在させることは困難
• タイトル１行、イラストと少しの説明を２、３行
• 最初から珠玉のアイデアは出てこない
• １枚１案、３０案は出す
• 展開するときは「拡げる」ことが大事

考具８　ポストイット

• １枚１ネタ
• 思い浮かんだものをそのまま書く
• 書いたポストイットは机や壁に貼る　張り方は事由
• 「アイデアのネタ」と「アイデア」は別物
• アイデアを考えることに「正しい順番」はない
• アイデアを思いついたらすぐアイデア書きに入る
• 行きつ戻りつの試行錯誤がない企画はパワーが無い

考具９　マンダラート

• すこしばかりの強制力が働くと、頭が必死に回転を始める
• 普段の生活で積み重なった記憶を引っ張り出し、組み合わせるだけで新しいアイデアが生まれる
• アイデアに遠慮は厳禁、少し違和感があっても書いておく
• アイデアが押し寄せてきそうならそのままもう一段階マンダラを開く。手順にこだわっている暇はない
• アイデアを出すことと、選ぶ、判断することは別物
• すでに頭の中にあるアイデアを引き出すことができれば新しいアイデアを生み出すことは簡単になる
• アイデアが面白いかどうかは、組み合わせの方法より組み合わせる要素をどれだけ多彩に引き出せるかが重要

考具１０　マインドマップ

• 自分で紙に落としていく過程を通じて本当に理解できるようになる

考具１１　アイデアスケッチ（ＰＣ）

• タイトル＋３行アイデア
• 複製した画面を上から書きなおしていくこと
• アイデアを考えるときは「芋づる式」や一見関係の無いことがミックスされたりぶつかり合うことがゼッタイに必要
• 拡げて、まとめる

考具１２　連想ゲーム

• 連想ゲームの目的は頭の中にしまい込まれた言葉を引き出すこと
• まずは自分好みのアイデアでOK

考具１３　オズボーンのチェックリスト
アイデアのヒント・要素は創りだすのではなく、探す・見つけるということ。「オズボーンのチェックリスト」はアイデアを生み出すために必要な「要素の組み合わせ方」の基本パターンが網羅されている

• 転用したら？
  現在のままでの新しい使い方は？
• 応用したら？
  似たものはないか、真似できないか
• 変更したら？
  意味、色、動き、匂い、形を変えたらどうなる？
• 拡大したら？
  大きくする、長くする、頻度を増やす、時間を延ばすと？
• 縮小したら？
  小さくする、短くする、軽くする、圧縮する、短時間にすると？
• 代用したら？
  代わりになる人や物は？材料、場所などを変える？
• 置き換えしたら？
  入れ替えたら、順番を変えたらどうなる？
• 逆転したら？
  逆さまにしたら、上下左右、役割を反対にしたら？
• 結合したら？
  合体、混ぜる、合わせたらどうなる？
• 
  

困ったときの辞書がわり。
アイデアのつくり方は至ってシンプルで、今と昔で違うのは方程式に入れるデータ。データを変えるだけなのでアイデアが尽きることはない。

考具１４　ブレーンストーミング　グループで使う考具
【４つのルール】

• 批判しない
• 自由奔放な発言を歓迎する
• 質より量を求める
• 他人のアイデアに便乗する

• ブレストはまったく別の視点を盗むチャンス
• ブレストは数の勝負。競争感覚を忘れない

４章　企画　アイデアを企画に収束させる

アイデアなくして企画なしだが、実務においてはアイデアは企画になっていないと使えない


考具１５　５Ｗ１Ｈフォーマット

• まずアイデア有りき「わがまま→思いやり」
• 新しい企画は予定調和の中からは生まれない

考具１６　タイトル

• 企画にタイトルを付ける

考具１７　ビジュアライズ

• 「絵にならないもの」は企画として成立しない
• できるだけ細かく丁寧に想像してみる
• やりたいことをどれだけ明確にできるかが成功するかどうかの判断基準になる。

考具１８　マンダラート

• マンダラートを主体的行動軸と取り巻く環境の軸に分けて使う

考具１９　企画書

• 企画書で肝心なのは「原稿」→「原稿」の構成に80%の時間をかける
• 企画書屋にはならない
• タイトル、５Ｗ１Ｈ、読んだ人がビジュアライズできるか
• 相手の頭の中で企画をビジュアライズさせたい
• 中心ツールは「言葉」→「言葉の力」を磨くこと

５章　行き詰まったとき
なにより大切なのはアウトプットし続けること

考具２０　アイデアマラソン

• 自分が産み出したアイデアをノートに書いておく
• 通し番号を振り、スタートしてからの日数とのギャップを計算
• 思いついたアイデアは誰かに話す

考具２１　問いかけの展開

• 与えられた課題を変えてみる、ズラしてみる
• アイデアに詰まったら質問、問いかけを拡げる

６章　自分なりの考具
インプット系考具
「既存の要素」をどれだけ発見できるか、インプットできるか

アウトプット系考具
アイデアを展開し、企画へ収束させるためのツール

• 手書きがアイデアの基本
• アイデアのヒントは至る所にある。発見できるかどうか、探しているか、見つけようとして問いかけているか、がポイント。

終章　頭の動き方のシステム化こそ「考具」
「私は◯◯◯◯◯な人」の◯◯◯◯◯を埋める＝自分のゴールを明確にすること
ゴールイメージを決める＝行き先がわかれば何が必要かもわかる

成功するためのノウハウは明らかなのに、実際に行動にうつす人は１％しかいない。だから成功するのは簡単。

WCAN2011 Summer

WCAN2011 Summerに参加しました。

少し遅くなりましたがまとめを記しておきます。まだまだ消化できてない感じですが、現段階で一度アウトプットしておくことのほうが大事かと思います。先日見たスタンフォード白熱教室でも早い段階で失敗を重ねろって言ってましたし…。鈴木曜さんの仮説と検証のサイクルと同じで、スピード感を大事にしたいですね。

全体的な感想
まずはライトニングトークを含めてどれも興味深かったが、一番と言われれば林千晶さんのセッションだったと思う。これは参加者の大部分に同意してもらえるのではないのだろうか。

第一に話がとても上手だったということ。堂々と、はっきりゆっくりとお話されていて、全体にとても説得力があった。まずプレゼンの技術というところでとても勉強になった。そしてセッションの内容も、所謂技術論は展開せず考え方の紹介とその事例を林さんのフィルターを通して伝えてくれた。詳しくは後で纏めるが、とにかく前向きになれる内容だった。今まで積んできた経験がバックボーンとなって、ああいう形でアウトプットできるのだろう。

MITの事例を紹介してくださったが、初めて参加した今回のWCANも、あの場に居るということを経験できたことが一番大きかったように思う。


【セッション１】　矢野りんさん
Web or App?　モバイル対応を視野に入れたデザイン入門

モバイル用のデザインを視野に入れたTipsなどを紹介してくださった。
話の中盤では、やはり今勉強しているHCDにつながっていった。コミュニケーションデザインのワークショップから引き続き、ユーザー目線に立つ、ということの重要性を再認識させられた。

カッコいいデザインとは
ターゲットによって違うので、ターゲットの設定が不可欠。
どこで何を等を想定する。　5W1H等。 WHYが一番大切。

スマートフォンとPCでは用途が違う
PCは情報収集に利用し、スマートフォンはリアルタイムコミュニケーションに利用。
スマートフォンで情報の収集はしない。

デザインとは解決策
それぞれの場面にあわせた解決策を用意すること

事例紹介

• Flickrの事例
• Amazonの事例
• Appleの事例
• TorontoStandardの事例

一般的なPCサイトの要件を満たすとユーザー中心設計になりにくい
クライアントの要件をすべて満たそうとすると、「伝えたい事」が優先される。
しかしスマートフォンサイトの場合は処理能力や画面の大きさの違いですべての要件を満たすことは難しい。必然的にユーザーが知りたい情報を掲載することや、サイト内で迷わないような設計にしなければならない。
これらのことからスモールスクリーンではユーザー中心以外の都合は入りにくい。

デザイナーがユーザーの利便性を考慮することができたら
Web design skill = App design skillになる

スモールスクリーンでは「戻る」機能を重視して設計すると良い
ハブ＆スポークの考え方

スモールスクリーンレイアウトの考え方

• スモールスクリーン化した状態を想定しながら作る
• 相対的なレイアウトを考慮する
• 必要があれば情報量を調整する

スモールスクリーンのUIカラーの基本

• 明度の差でバリエーションを作ってスタイリングする
• タップ出来る部分、重要度の違いなどを部品に立体感を持たせることで意味付けする

ユーザーは画面遷移の「流れ」で情報を把握している
多彩な色使いは嗜好を中断させる原因になる
彩度を抑えた色、明度を上げた色など、中間色をうまく使ってトーンの差によって自然な立体感を出すように心がける。まとまり重視の色使い。

UIは多数決
独創的なものより基本に沿ったものを優先する
ユーザーの学習経験を利用する





セッション２　林千晶さん
プロジェクトデザイニング
プロジェクトマネジメントからプロジェクトデザイニングへ

林さんはプロジェクトマネジメントの「管理する」という間隔に違和感を持ち、プロジェクトデザイニングを提唱。ここも共感できるところだった。
デザインといっても結局は管理することなのだが、管理につきまとう「強制や抑圧」といったイメージより、「メンバーの強みを引き出す」という考え方の方がより共感を得やすいと思うし、他の書籍などでも「強み」に焦点をあてることの重要さは頻繁に出てくる。
そういった意味でも、捉え方次第でプロジェクトに対するアプローチの仕方が変わってくると思う。

失敗したプロジェクトをどう捉えるか。
仕方ない、運が悪かった
ではなく
動やったら防げたかと考える

プロジェクトマネジメントの知識体系「PMBOK Project Management Body of Knowledge」
世界中の「どうやったら防げたか」の集大成
今後WEB制作でもプロジェクトマネジメントの手法は必須になってくる。

何の為のプロジェクトマネジメントか
ほとんどの計画は計画通りに進まない
計画通りに進むことが成功でもない

アジャイルソフトウェア宣言では計画よりも現実への迅速な適応を重視する

• プロセスやツール ＜ 個人との対話
• 包括的なドキュメント ＜ 動くソフトウェアを
• 契約交渉 ＜ 顧客との協調
• 計画に従うこと ＜ 変化への対応

左記の事柄に価値を認めながら右記の事柄により価値を置く


PMBOKのフレームワーク＋アジャイル型幸運の引き寄せ方＝プロジェクトデザイニング

プロジェクトデザイニングとは

1. プロジェクトを俯瞰する
2. 目標を腹に落とす
3. コミュニケーションを楽しむ
4. WBS（Work Breakdown Structure）で見通しを良くする
5. わくわくする未来を作る

１：プロジェクトを俯瞰する

• 顧客からの要求は一部であり、その問題を解決するだけではいけない
• ９つの知識エリア、42のプロセス
• トラブルが起こるのはたいてい自分の弱いところ。苦手なのものは仲間に任せる。

２：目標を腹に落とす

• 知らない→頭で理解する→気持ちがわかる
• ストーリーを知るということ、背景を知らなければいけない
• ゴールを明確化するとプロセスが見える。
• ビジュアライズすること
• As isとTo be：現状を知ることで良いTobeにつながる
• アウトプット：ドキュメントにすることで揺るぎない基盤とする

３：コミュニケーションを楽しむ

• ミーティングは可能な限り楽しく
• 会議室ではないコミュニケーションを
• PMの90%以上がコミュニケーション
• メンバーの性格を知ることがチームビルディング

チームスタッフの特徴は最初に知る、最初に仲良くなる

ブレストは楽しんでやる　美味しい物を食べながら等
IDEO社　ブレスト７つの秘訣

1. すぐに判断しない
2. 突飛なアイデアを歓迎する
3. 人の意見をベースに展開する
4. テーマを変えない
5. 人が話しているときは聴く
6. 視覚化する
7. 質より量

対立を解消するためには「対峙」する。
なぜ対立が起こったのか、きちんと向き合うことがwin-winにつながる。

４：WBS（Work Breakdown Structure）

• 難しいことほど細かく分解する
• 求められる品質もWBSを通じて可視化出来る

５：わくわくする未来をつくる

• 満足したい：「幸せになりたい」が根本的欲求
• 眼に見えるものの裏側に真実がある

Serendipity：セレンディピティ
偶然をきっかけにひらめきを得て幸運を掴みとること
出来る限りオープンでいれば、情報や人が集まってくる。

アイデアのつくり方

この本を読んで、わかった気になっていたことが文章化されて目の前に現れて、かなりハラオチしました。昔学校の先生が「遊ばないヤツにいいデザインなんか出来ないぞ」と言われた意味が、やっとしっかり自分なりに理解できました。

アイデアの作成は流れ作業である　この技術を習得すること。

どんな技術を習得する場合にも学ぶべきものは

1. 原理
2. 方法

アイデアとは既存の要素の新しい組み合わせである

既存の要素を新しい組み合わせに導く才能は、事物の関連性を見つけ出す才能に依存する

アイデアのつくり方は5つの段階を必ず順番通りに通り抜けなければならない


１　資料を収集する

• その時々の案件に関する「特殊資料」
• 世の中の種々様々な出来事に着いての一般的知識

• 特殊資料を集めるにはカード索引法が有益
• 一般的資料を集めるのにはスクラップブックやファイルが有益

２　これらの資料を咀嚼する

• 仮の、部分的なアイデアが出てくるので紙に記入する
• 組み合わせるのに疲労しても続ける
• 組み合わせる努力をやり遂げたとき、次の段階に移行する

３　すべてを放棄する

• 音楽など感情を刺激するものに心を移すこと

４　アイデアの到来を期待していないとき、突然訪れてくる

５　現実の有用性に合致させるために最終的なアイデアを具体化し展開させる。

• 信頼できる人の批判に晒す。自分だけで考えない
  

明日の広告 変化した消費者とコミュニケーションする方法

少し前になりますが読みました。今回はホントにメモしか残ってなかったです。自分しか分からないかも。

■広告は消費者へのラブレター


以前：ラブレター（広告）が相手の手にわたりやすかった。
他に楽しいことが少なかった。
渡したラブレターを相手がちゃんと読んでくれた。

現在：ラブレターを受け取ってさえくれない
相手の手に届きにくくなった。
他に楽しいことがたくさんあり興味をなくしている。
届いたとしても信じない
内容を友達と検討し、判断を任せたりする

4マスに広告を打ってさえいれば見てくれる時代ではない

■相手の趣味・行動を調べ、よく観察し、相手の身になってみる。その上で相手の行動を先読みし、待ち伏せ、確実に広告を届ける。

コンタクトポイントを見極める。
他の楽しいことに目がいかないように「心を動かす表現」をする。
相手の友達にも気に入られるようにケアする。
ラブレターを渡した後が大切。「買ってくれた人へのもてなしが重要」→エンゲージメント
買ってくれた人は「強力なクチコミ源」

商品開発からコミュニケーションを始める
商品設計にコミュニケーション設計を内包させる。

ネットは商品の真実の姿をさらけ出す。

10年間で世の中の情報量は10倍になった（2004年）
ネットの出現＋情報洪水＋成熟市場で消費者が根本的に変わった
疑い深い消費者の登場

広告は「偶然出会うから記憶に残る」今まで通りのやり方では偶然出会えない

変化していない消費者もいる「老人」と「子供」

30代前半くらいまでの人にとって信頼できるのは「友達・好きな人（芸能人など）・信頼できる人」

消費者はターゲットからパートナーへ。受け手から送り手へ

■ターゲットの気持ちになる

■生活者のどこで待ち伏せるか

• コンタクトポイントで待ち伏せる
  
  
• 新しいメディアを作って待ち伏せる
  広告に出会うと思っていなかった場所にメッセージがあると効く
  
  
• クチコミを利用して待ち伏せる
  BUZZ、WOM（word of mouth）、VIRAL
  
  
• CGM（Consumer Generated Media）で待ち伏せる
  クチコミが今一番起こっているのはCGM上：マーケティングの場としても重要
  
  
• エンターテイメントの中で待ち伏せる→プル型コンテンツ
  ↓検索結果でも待ち伏せる
  
  
• 検索結果で待ち伏せる
  SEOは検索結果が上位に来るようにする施策
  SEMは検索結果から自社サイトなどへの訪問者を増やす施策
  
  
• メディアをニュートラルに考えてクロスに待ち伏せる→ターゲットに伝えるために最適なメディアを中心に据える→メディアミックスとクロスメディアの違いに注意する

■初動が大切
「伝えたい相手をしっかりと見る」→これが一番大切

消費者本位で考える

• 「伝えてもらいたがっている人」をリアルに想像する
  「伝えたい人」ではない、それは送り手本位の考え
  
• 「買いたい人を創りだしてしまう」のもアリ→ピロリ菌の事例等 PRを上手に活用

伝えたい相手のデータが少ないときは、商品と共に生活してみる

心を動かすには単なるインフォメーションではいけない
同じように最適なコミュニケーションデザインなら、クリエイティブの勝負になる

消費者は頭のスイッチをオフにしているときに、偶然広告に出会う

買ってくれた人をもてなすこと（NIKEの事例）

コミュニケーションデザインは既存のマスメディアをもう一度魅力的にする

ネットは全てのコンタクトポイントを結びつける体液みたいな物

変化した消費者は長めに付き合うことで強力な味方となる

「広告は消費者の為のソリューションでなければならない」

HCDの理解2011[初級編Vol.3]

6/11（土）
HCDの理解2011[初級編Vol.3]に行ってきました。

適切なユーザー評価をし、問題となる箇所を洗い出して改善案を考えるというWS。
適切なユーザ評価を通じて問題点が明確化され、より精度の高い改善につながる

今回行ったのは、ユーザビリティテスト（プロコトル法）
・タスク設定がキモ。
・NE比によって導かれた問題のある箇所の発話に注目。
・発話にこそ解決策がある
・タスクの設定はうまく行った
・エキスパートテストやNE比の分析、そこからの問題点の洗い出しでミス

【全体の流れ】
前日：事務局より課題となるWEBサイト通知
↓
座学
↓
ペルソナを作り、そのサイトにあったタスクとインタラクションを設定
↓
エキスパートテスト①（パイロットテスト）
↓
エキスパートテスト②
↓
ノービステスト①
↓
ノービステスト②
↓
書き起こし
↓
NE比分析
↓
発表


【前日：事務局より課題となるWEBサイト通知】
送られてきた課題はチームごとに違い、自分宛に来たメールには
「名古屋市科学館のサイトをなるべく細部まで見ておくように」
※その他DVカメラの持込依頼、PCの持込依頼も。




【座学】講師：浅野先生
とにかくこういったWSでは時間がないので、
後で見直すことを念頭においてメモをとることに専念。

今回はHCDプロセスのユーザ評価を学ぶ
HCDではプロセスのドコから始めても構わないがサイトリニューアルの場合はユーザ評価から

「何を評価するのか」
vol.2：特定ユーザによって特定の利用状況下でユーザ調査
vol.3：指定された目標を達成するために用いられる際の有効さ、効率、ユーザの満足度
↓
ユーザビリティ（使いやすさ）

「評価手順」
①何を評価するのかを明確化
②評価方法の選択
評価の専門家
開発者
ユーザ
③評価と分析
形成的評価なのか総括的評価なのか
形成的評価とは：「どこが分かっていないのか」を調べる
└常に実践することが大事

「評価手法」
様々な評価手法があるが特に覚えてきたいものは下記４つ
・エキスパートレビュー
・認知的ウォークスルー法
・ユーザビリティテスト（プロトコル法）
・長期観察
上から実施が易→難
得られる情報は少→多

実際の調査には様々な手法を組み合わせて行う

「エキスパート評価」
評価者がユーザビリティガイドラインに基づいて行う。
ユーザビリティエンジニアが評価。
・ユーザビリティガイドライン
ヤコブ・ニールセンらが開発
ニールセンの10項目

「認知的ウォークスルー法」
検査者自身がユーザの認知的な行動軌跡を推定して問題点を抽出する方法
段階ごとにブレスト
・各段階を可視性、マッピング、良い概念モデル、フィードバック等の
チェック項目をブレストで評価していく。




【ペルソナを作り、そのサイトにあったタスクとインタラクションを設定】
名古屋市科学館が課題ということで、前回のCDWSに続き自分がペルソナモデルに。

ペルソナ：35才　男性
子どもを連れて名古屋市科学館にプラネタリウムを見に行きたいので情報がほしい
車で行く、子供は３才

タスク設定
・車で行く場合の科学館までの交通アクセスを調べたい　なるべく安い駐車場の場所と料金も
・参考にプラネタリウムの、本日の空席情報が知りたい
・竜巻ラボをテレビで知ったので、夏休みの平日における展示時間が知りたい
・プラネタリウムの、夏休み子供向けプログラムが知りたい

インタラクション設定
・交通アクセスに最下部に駐車場の情報と料金が掲載されている
・TOPに大きなボタンが配置されている　プラネタリウムのページからも到達可
・大型展示から到達可能なタイムスケジュール閲覧
・プラネタリウムの「プラネテーマ」から到達可




【エキスパートテスト①（パイロットテスト）】
開発者によるパイロットテスト
ここでタスクの調整を行った。



【エキスパートテスト②】
ここで失敗
情報取得の経路が分かってしまうので、
タスク設定にエキスパートテスト担当者が関与してはいけない
あくまでサイトを良く知っているがタスクは知らない人間がすること
※最終的には同じ課題の他チームに協力してもらって実行した（タスクを知らない人間）
次回からはこうした方が良いのでは？事務局に提案。




【ノービステスト①】
【ノービステスト②】
タスク設定がうまく行ったので、得たい情報がスムーズに得られた。



【書き起こし】
ここで失敗
時間がなく、次の段階に移行。
本来ならば発話にこそ改善策が隠れているのだが、
省いたことでエキスパートの立場からの改善策になってしまった。



【NE比分析】
ここで失敗
NE比を確認したものの、グラフ作成に失敗し、
NE比の高い問題となる箇所を絞り込まなかった。
その為、タスク全体に修正をかけようとしてしまい、
結果的に時間が足りなくなった。
しっかり視覚化できていればチームで共有でき、
もっとスムーズに問題点の洗い出しから
改善策の検討まで進めたと思う。



【発表】
最近別のWSで発表を担当したこともあって、遠慮。
これが結果的に発表した人を犠牲者にしてしまった。
パワポでまとめる作業もメンバーにお願いした。
オフィス系ソフトの熟練も必要なことが浮き彫りになった。




【その他メモ・雑記】
・ペルソナは３人設定し、３種類のタスクを実行させるとそのサイトの問題点はかなり明らかになる
・タスクは明確な行動でなければならない（個人の嗜好を存在させてはならない）
・行動データが取れなかったら発話とインタビューで裏付ける
・インタラクションもしっかり設定する
・発話の記述があると発表に説得力が出る
・アクティビティとインタラクション次第
・三角点法　三角形の中心にこそ真実がある
・セマンティックディファレンシャル法（SD法）
・ペルソナ：シナリオ法ができればユーザ評価は成功する
・タスク設定が難しい
・NE比は操作自体に時間がかかるものがあるので、かかった時間ではなくNE比によって判断材料とする
・サイトリニューアルの場合、HCDプロセスのユーザ評価から始めても良い
・デザイナーはユーザのことを考えてデザインしないが、しっかりとした検証と確認・修正が必要。
・年に一度しか行わない行動と、継続的に行う行動、前提とする行動の種類によってもデザインは変わる
・NE比５倍以内＝放置　５〜１０倍＝修正　１０倍以上＝放置し、リニューアル時に根本的に変更
・従来のウェブサイトの形＝ツリー型、最適な形はそんなに簡単ではない
セミラティス型＝階層にとらわれず行動を元に設計する
・LATCHを学べていない