少し遅くなりましたがまとめを記しておきます。まだまだ消化できてない感じですが、現段階で一度アウトプットしておくことのほうが大事かと思います。先日見たスタンフォード白熱教室でも早い段階で失敗を重ねろって言ってましたし…。鈴木曜さんの仮説と検証のサイクルと同じで、スピード感を大事にしたいですね。
全体的な感想
まずはライトニングトークを含めてどれも興味深かったが、一番と言われれば林千晶さんのセッションだったと思う。これは参加者の大部分に同意してもらえるのではないのだろうか。
第一に話がとても上手だったということ。堂々と、はっきりゆっくりとお話されていて、全体にとても説得力があった。まずプレゼンの技術というところでとても勉強になった。そしてセッションの内容も、所謂技術論は展開せず考え方の紹介とその事例を林さんのフィルターを通して伝えてくれた。詳しくは後で纏めるが、とにかく前向きになれる内容だった。今まで積んできた経験がバックボーンとなって、ああいう形でアウトプットできるのだろう。
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のフレームワーク＋アジャイル型幸運の引き寄せ方＝プロジェクトデザイニング
プロジェクトデザイニングとは
- プロジェクトを俯瞰する
- 目標を腹に落とす
- コミュニケーションを楽しむ
- WBS（Work Breakdown Structure）で見通しを良くする
- わくわくする未来を作る
１：プロジェクトを俯瞰する
- 顧客からの要求は一部であり、その問題を解決するだけではいけない
- ９つの知識エリア、42のプロセス
- トラブルが起こるのはたいてい自分の弱いところ。苦手なのものは仲間に任せる。
２：目標を腹に落とす
- 知らない→頭で理解する→気持ちがわかる
- ストーリーを知るということ、背景を知らなければいけない
- ゴールを明確化するとプロセスが見える。
- ビジュアライズすること
- As isとTo be：現状を知ることで良いTobeにつながる
- アウトプット：ドキュメントにすることで揺るぎない基盤とする
３：コミュニケーションを楽しむ
- ミーティングは可能な限り楽しく
- 会議室ではないコミュニケーションを
- PMの90%以上がコミュニケーション
- メンバーの性格を知ることがチームビルディング
ブレストは楽しんでやる 美味しい物を食べながら等
IDEO社 ブレスト７つの秘訣
- すぐに判断しない
- 突飛なアイデアを歓迎する
- 人の意見をベースに展開する
- テーマを変えない
- 人が話しているときは聴く
- 視覚化する
- 質より量
対立を解消するためには「対峙」する。
なぜ対立が起こったのか、きちんと向き合うことがwin-winにつながる。
４：WBS（Work Breakdown Structure）
- 難しいことほど細かく分解する
- 求められる品質もWBSを通じて可視化出来る
５：わくわくする未来をつくる
- 満足したい：「幸せになりたい」が根本的欲求
- 眼に見えるものの裏側に真実がある
Serendipity：セレンディピティ
偶然をきっかけにひらめきを得て幸運を掴みとること
出来る限りオープンでいれば、情報や人が集まってくる。
0 件のコメント:
コメントを投稿