PMがUXするために必要なのは多分IA / IA for PM

Transcript

1. 株式会社 CAMPFIRE ⼩久保浩⼤郎 PMがUXするために必要なのは多分IA

2. None

3. IA とは(雑) • IA = Information Architecture です • IA

   は職種ではなくスキルセットです • プロダクト開発に関わるすべてのジョブロールの⼈が持っ ていていいスキル • 抽象的に情報を扱うスキル、程度に考えてください • 今⽇の話は、⼤体 IA っぽい領域の話だと思ってください

4. • UX is 何? • ユーザビリティと UX • マーケティングと UX

   • UI と UX • 名前重要

5. UX is 何?

6. Experience User Service/Product

7. Experience User Service/Product Context/Environment 広告、レビュー記事、⼝コミ 利⽤デバイス、利⽤環境・シーン

8. UXは環境やコンテキストに依存する • ユーザーと対象（サービス、プロダクト）という
 ⼆者の間の話のように聞こえるがそうではない • それらを取り巻く環境やコンテキストにその認知は
 ⼤きく依存する • UX を考える時はユーザーの利⽤環境、マーケット認知、


   社会的認知など様々なレベルのコンテキストを考える
 必要がある • 別に新しい話ではなく、できるデザイナーは
 昔からそこを分かっていて考えてやっていた

9. User Experience とは 発明されたのではなく 発⾒された概念である 詳しくは「UX⽩書」やその解説をおググりください

10. ユーザビリティとUX

11. 「道を歩く」のユーザビリティ Case 1

12. None
13. None

14. Success! Great Usability!

15. ユーザビリティ = 予測可能性

16. But…

17. Is there any experience? Past Present Future

18. 「道を歩く」の Experience Case 2

19. None
20. None
21. None

22. ! Experience!

23. これらの違い

24. Prediction Expectation Result Case 1

25. Prediction Expectation Result ! Case 2

26. Prediction Expectation Result ! Gap! Case 2

27. Prediction Expectation Result Gap Micro Experience Unit

28. Experience User Service/Product Context/Environment

29. マーケティングとUX

30. 対象ユーザーのペルソナを どう考えるか

31. プロダクトライフサイクルや マーケットへの普及のステージ によって対象ユーザー像は変わる

32. Product Lifecycle Introduction Growth Maturity Decline

33. Diffusion of Innovation Innovator Early Adopter Early Majority Late Majority

    Laggard

34. 対象ユーザーペルソナが変わると
 プロダクトデザインの何が変わる?

35. 学習曲線のデザインが変わる Type B Type A

36. 何に対する学習度か? • サービスの提供価値や動作概念に対する理解度 • 利⽤習熟度A（よく使う機能を意識せず素早く使える） • 利⽤習熟度B（⾼度な機能を⾒つけて使いこなす）

37. Innovator Early Adopter Early Majority Late Majority Laggard Type A

    Type B

38. • 新しいものへの興味が強い • 難しいことも理解しようとする • 絶対数は少ないがオピニオンリー ダーとして影響⼒がある • カーネマンのシステム2的 Type

    A Type B • ⼈が使っているもの、流⾏ってい る物を使いたがる • 理解するのが難しいと使わない • 絶対数は多い • カーネマンのシステム1的 • ⾒た⽬が美しく魅⼒的 • 操作に必要なサインの提⽰ • ⼀度に処理すべき情報量が少ない • 動作モデルが理解可能 • 慣れた予測で素早く操作可能 • ⼀覧性が⾼く情報量が多い ϖϧιφ ޷·ΕΔUI

39. UIとUX

40. PMが考えなきゃいけないモデルたち Business Model System Model Product Mental Model

41. System Model Mental Model システムがどのように
 動作するか（事実） システムがどのように
 動作するように⾒えるか（認知） これらをいかに⼀致させるか
 またはさせないか

42. システムモデルとメンタルモデル • これらは単純に⼀致させればよいというものではない • 効率的で合理的なシステムの動作モデルと、ユーザーがわ かりやすく使いやすいと考えるモデルは違うことは多い • どちらかが先に決定するわけではなく、相互に影響しなが らできあがることも多い •

    おそらく昔はシステムモデル先⾏だったが、ユーザビリ ティや⼈間中⼼設計といった概念の普及により改善された • UXという概念の普及もこの流れの⼀環と⾔える

43. System Model Mental Model システムがどのように
 動作するか（事実） システムがどのように
 動作するように⾒えるか（認知） これらをいかに⼀致させるか
 またはさせないか

44. Mental Model Designer’s Model User’s Model

45. Mental Model Designer’s Model User’s Model User Interface こう思わせたい（意図） こう思った（認知）

46. デザイナーズモデルとユーザーズモデル • これらは常に可能な限り⼀致させたい • それをどううまくやるのか、というのが UI デザイン • UI を通してユーザーがデザイナーズモデルを理解する

    • その理解の結果がプロダクトに対するメンタルモデル

47. System Model Designer’s Model User’s Model Product

48. System Model Designer’s Model User’s Model Product

49. ターゲットペルソナは複数いる • プロダクトライフサイクルやマーケットへの普及のステー ジによって対象ユーザー像は変わる • 対象ユーザー像が違えば提供すべきメンタルモデルも違う • 提供すべきメンタルモデルが違えば UI が違う

    つらい

50. 名前重要

51. 「モデル」とか「理解」とか
 ⾔ってるけど
 ⼈はそもそも物事を
 どのように理解するのか

52. 理解 = 分かる = 分かつ

53. 理解 = 分かる = 分かつ • ⼈は物事に名前がついて初めてそれを他のものと区別する ことができる • あるふたつのものが本来的に存在するのではなく、別々の

    名前をつけることによって⼆つの存在に分離する • 分かつことによって、その抽象的性質を帰納的に推論でき るようになる • この抽象モデルを⼿に⼊れることが「理解」

54. 名前重要 (Ruby の⽣みの親 まつもとゆきひろ⽒) by Matz

55. System Model Designer’s Model User’s Model • オブジェクトモデル • スキーマ、DB

    カラム • クラス、メソッド • 変数 • UI エレメント、
 コンポーネント • UI ラベル、⽂⾔ • ⾊、スタイル • UI ラベル • ⽂⾔のトンマナ • オブジェクトの名称 • ⾏為の名称 User Interface これらをいかに⼀致させるか
 またはさせないか

56. 基本的なところは統⼀した⽅が良い • システムの根幹的な概念や動作モデルに関する名称 • 主要なオブジェクト達（名詞） • それらが取りうる振る舞い（動詞） • 利⽤シーンにおけるユーザーの区別（名詞） •

    ユーザーが取りうるアクション（動詞）

57. 統⼀する利点 • 開発チーム内のコミュニケーションの効率化 • バックエンド、フロントエンド、デザイン、コピーにおけ る名称の⼀貫性 • システムモデルとメンタルモデルの差異が
 意図的か否かが分かる •

    開発ドキュメントが書きやすく、読みやすく • マニュアル、FAQ、マーケティングにも⼀貫性 • 新しい概念に対する命名の必要性判断の⼟台

58. 名前重要 (Ruby の⽣みの親 まつもとゆきひろ⽒) by Matz

59. おすすめの本

60. PMがUXするために 必要なのは多分IA