Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kotaro Kokubo
October 24, 2018

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

PMCONF 2017 の UX トラックでの講演資料です

Kotaro Kokubo

October 24, 2018
Tweet

Other Decks in Design

Transcript

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

    View Slide

  2. View Slide

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

    View Slide

  4. • UX is 何?
    • ユーザビリティと UX
    • マーケティングと UX
    • UI と UX
    • 名前重要

    View Slide

  5. UX is 何?

    View Slide

  6. Experience
    User Service/Product

    View Slide

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

    View Slide

  8. UXは環境やコンテキストに依存する
    • ユーザーと対象(サービス、プロダクト)という

    ⼆者の間の話のように聞こえるがそうではない
    • それらを取り巻く環境やコンテキストにその認知は

    ⼤きく依存する
    • UX を考える時はユーザーの利⽤環境、マーケット認知、

    社会的認知など様々なレベルのコンテキストを考える

    必要がある
    • 別に新しい話ではなく、できるデザイナーは

    昔からそこを分かっていて考えてやっていた

    View Slide

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

    View Slide

  10. ユーザビリティとUX

    View Slide

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

    View Slide

  12. View Slide

  13. View Slide

  14. Success! Great Usability!

    View Slide

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

    View Slide

  16. But…

    View Slide

  17. Is there any experience?
    Past Present Future

    View Slide

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

    View Slide

  19. View Slide

  20. View Slide

  21. View Slide

  22. !
    Experience!

    View Slide

  23. これらの違い

    View Slide

  24. Prediction Expectation Result
    Case 1

    View Slide

  25. Prediction Expectation Result
    !
    Case 2

    View Slide

  26. Prediction Expectation Result
    !
    Gap!
    Case 2

    View Slide

  27. Prediction Expectation Result
    Gap
    Micro Experience Unit

    View Slide

  28. Experience
    User Service/Product
    Context/Environment

    View Slide

  29. マーケティングとUX

    View Slide

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

    View Slide

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

    View Slide

  32. Product Lifecycle
    Introduction Growth Maturity Decline

    View Slide

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

    View Slide

  34. 対象ユーザーペルソナが変わると

    プロダクトデザインの何が変わる?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. UIとUX

    View Slide

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

    View Slide

  41. System Model Mental Model
    システムがどのように

    動作するか(事実)
    システムがどのように

    動作するように⾒えるか(認知)
    これらをいかに⼀致させるか

    またはさせないか

    View Slide

  42. システムモデルとメンタルモデル
    • これらは単純に⼀致させればよいというものではない
    • 効率的で合理的なシステムの動作モデルと、ユーザーがわ
    かりやすく使いやすいと考えるモデルは違うことは多い
    • どちらかが先に決定するわけではなく、相互に影響しなが
    らできあがることも多い
    • おそらく昔はシステムモデル先⾏だったが、ユーザビリ
    ティや⼈間中⼼設計といった概念の普及により改善された
    • UXという概念の普及もこの流れの⼀環と⾔える

    View Slide

  43. System Model Mental Model
    システムがどのように

    動作するか(事実)
    システムがどのように

    動作するように⾒えるか(認知)
    これらをいかに⼀致させるか

    またはさせないか

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  50. 名前重要

    View Slide

  51. 「モデル」とか「理解」とか

    ⾔ってるけど

    ⼈はそもそも物事を

    どのように理解するのか

    View Slide

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

    View Slide

  53. 理解 = 分かる = 分かつ
    • ⼈は物事に名前がついて初めてそれを他のものと区別する
    ことができる
    • あるふたつのものが本来的に存在するのではなく、別々の
    名前をつけることによって⼆つの存在に分離する
    • 分かつことによって、その抽象的性質を帰納的に推論でき
    るようになる
    • この抽象モデルを⼿に⼊れることが「理解」

    View Slide

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

    View Slide

  55. System Model Designer’s Model User’s Model
    • オブジェクトモデル
    • スキーマ、DB カラム
    • クラス、メソッド
    • 変数
    • UI エレメント、

    コンポーネント
    • UI ラベル、⽂⾔
    • ⾊、スタイル
    • UI ラベル
    • ⽂⾔のトンマナ
    • オブジェクトの名称
    • ⾏為の名称
    User Interface
    これらをいかに⼀致させるか

    またはさせないか

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

  59. おすすめの本

    View Slide

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

    View Slide