2011年6月28日火曜日

WCAN2011 Summer

WCAN2011 Summerに参加しました。

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

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

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

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


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

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

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

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

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

事例紹介

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


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

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

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

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

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


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

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


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

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





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

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

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

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

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

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

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

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


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

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

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


1:プロジェクトを俯瞰する

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


2:目標を腹に落とす

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


3:コミュニケーションを楽しむ

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

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

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

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

4:WBS(Work Breakdown Structure)

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


5:わくわくする未来をつくる

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


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

2011年6月21日火曜日

アイデアのつくり方

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

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

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

  1. 原理
  2. 方法


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

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

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


1 資料を収集する


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

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


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

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


3 すべてを放棄する

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

■生活者のどこで待ち伏せるか
  • コンタクトポイントで待ち伏せる

  • 新しいメディアを作って待ち伏せる
    広告に出会うと思っていなかった場所にメッセージがあると効く

  • クチコミを利用して待ち伏せる
    BUZZ、WOM(word of mouth)、VIRAL

  • CGM(Consumer Generated Media)で待ち伏せる
    クチコミが今一番起こっているのはCGM上:マーケティングの場としても重要

  • エンターテイメントの中で待ち伏せる→プル型コンテンツ
    ↓検索結果でも待ち伏せる

  • 検索結果で待ち伏せる
    SEOは検索結果が上位に来るようにする施策
    SEMは検索結果から自社サイトなどへの訪問者を増やす施策

  • メディアをニュートラルに考えてクロスに待ち伏せる→ターゲットに伝えるために最適なメディアを中心に据える→メディアミックスとクロスメディアの違いに注意する


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

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


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

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

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

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

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

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

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

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



2011年6月13日月曜日

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:指定された目標を達成するために用いられる際の有効さ、効率、ユーザの満足度

ユーザビリティ(使いやすさ)

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

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

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

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

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




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

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

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

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




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



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




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



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



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



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




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