Slide 1
Slide 1 text
株式会社 CAMPFIRE ⼩久保浩⼤郎
PMがUXするために必要なのは多分IA
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
IA とは(雑)
• IA = Information Architecture です
• IA は職種ではなくスキルセットです
• プロダクト開発に関わるすべてのジョブロールの⼈が持っ
ていていいスキル
• 抽象的に情報を扱うスキル、程度に考えてください
• 今⽇の話は、⼤体 IA っぽい領域の話だと思ってください
Slide 4
Slide 4 text
• UX is 何?
• ユーザビリティと UX
• マーケティングと UX
• UI と UX
• 名前重要
Slide 5
Slide 5 text
UX is 何?
Slide 6
Slide 6 text
Experience
User Service/Product
Slide 7
Slide 7 text
Experience
User Service/Product
Context/Environment
広告、レビュー記事、⼝コミ
利⽤デバイス、利⽤環境・シーン
Slide 8
Slide 8 text
UXは環境やコンテキストに依存する
• ユーザーと対象（サービス、プロダクト）という
⼆者の間の話のように聞こえるがそうではない
• それらを取り巻く環境やコンテキストにその認知は
⼤きく依存する
• UX を考える時はユーザーの利⽤環境、マーケット認知、
社会的認知など様々なレベルのコンテキストを考える
必要がある
• 別に新しい話ではなく、できるデザイナーは
昔からそこを分かっていて考えてやっていた
Slide 9
Slide 9 text
User Experience とは
発明されたのではなく
発⾒された概念である
詳しくは「UX⽩書」やその解説をおググりください
Slide 10
Slide 10 text
ユーザビリティとUX
Slide 11
Slide 11 text
「道を歩く」のユーザビリティ
Case 1
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
Success! Great Usability!
Slide 15
Slide 15 text
ユーザビリティ = 予測可能性
Slide 16
Slide 16 text
But…
Slide 17
Slide 17 text
Is there any experience?
Past Present Future
Slide 18
Slide 18 text
「道を歩く」の Experience
Case 2
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
!
Experience!
Slide 23
Slide 23 text
これらの違い
Slide 24
Slide 24 text
Prediction Expectation Result
Case 1
Slide 25
Slide 25 text
Prediction Expectation Result
!
Case 2
Slide 26
Slide 26 text
Prediction Expectation Result
!
Gap!
Case 2
Slide 27
Slide 27 text
Prediction Expectation Result
Gap
Micro Experience Unit
Slide 28
Slide 28 text
Experience
User Service/Product
Context/Environment
Slide 29
Slide 29 text
マーケティングとUX
Slide 30
Slide 30 text
対象ユーザーのペルソナを
どう考えるか
Slide 31
Slide 31 text
プロダクトライフサイクルや
マーケットへの普及のステージ
によって対象ユーザー像は変わる
Slide 32
Slide 32 text
Product Lifecycle
Introduction Growth Maturity Decline
Slide 33
Slide 33 text
Diffusion of Innovation
Innovator Early Adopter Early Majority Late Majority Laggard
Slide 34
Slide 34 text
対象ユーザーペルソナが変わると
プロダクトデザインの何が変わる?
Slide 35
Slide 35 text
学習曲線のデザインが変わる
Type B
Type A
Slide 36
Slide 36 text
何に対する学習度か?
• サービスの提供価値や動作概念に対する理解度
• 利⽤習熟度A（よく使う機能を意識せず素早く使える）
• 利⽤習熟度B（⾼度な機能を⾒つけて使いこなす）
Slide 37
Slide 37 text
Innovator Early Adopter Early Majority Late Majority Laggard
Type A Type B
Slide 38
Slide 38 text
• 新しいものへの興味が強い
• 難しいことも理解しようとする
• 絶対数は少ないがオピニオンリー
ダーとして影響⼒がある
• カーネマンのシステム2的
Type A Type B
• ⼈が使っているもの、流⾏ってい
る物を使いたがる
• 理解するのが難しいと使わない
• 絶対数は多い
• カーネマンのシステム1的
• ⾒た⽬が美しく魅⼒的
• 操作に必要なサインの提⽰
• ⼀度に処理すべき情報量が少ない
• 動作モデルが理解可能
• 慣れた予測で素早く操作可能
• ⼀覧性が⾼く情報量が多い
ϖϧιφ
·ΕΔUI
Slide 39
Slide 39 text
UIとUX
Slide 40
Slide 40 text
PMが考えなきゃいけないモデルたち
Business Model System Model
Product
Mental Model
Slide 41
Slide 41 text
System Model Mental Model
システムがどのように
動作するか（事実）
システムがどのように
動作するように⾒えるか（認知）
これらをいかに⼀致させるか
またはさせないか
Slide 42
Slide 42 text
システムモデルとメンタルモデル
• これらは単純に⼀致させればよいというものではない
• 効率的で合理的なシステムの動作モデルと、ユーザーがわ
かりやすく使いやすいと考えるモデルは違うことは多い
• どちらかが先に決定するわけではなく、相互に影響しなが
らできあがることも多い
• おそらく昔はシステムモデル先⾏だったが、ユーザビリ
ティや⼈間中⼼設計といった概念の普及により改善された
• UXという概念の普及もこの流れの⼀環と⾔える
Slide 43
Slide 43 text
System Model Mental Model
システムがどのように
動作するか（事実）
システムがどのように
動作するように⾒えるか（認知）
これらをいかに⼀致させるか
またはさせないか
Slide 44
Slide 44 text
Mental Model
Designer’s Model User’s Model
Slide 45
Slide 45 text
Mental Model
Designer’s Model User’s Model
User Interface
こう思わせたい（意図） こう思った（認知）
Slide 46
Slide 46 text
デザイナーズモデルとユーザーズモデル
• これらは常に可能な限り⼀致させたい
• それをどううまくやるのか、というのが UI デザイン
• UI を通してユーザーがデザイナーズモデルを理解する
• その理解の結果がプロダクトに対するメンタルモデル
Slide 47
Slide 47 text
System Model Designer’s Model User’s Model
Product
Slide 48
Slide 48 text
System Model Designer’s Model User’s Model
Product
Slide 49
Slide 49 text
ターゲットペルソナは複数いる
• プロダクトライフサイクルやマーケットへの普及のステー
ジによって対象ユーザー像は変わる
• 対象ユーザー像が違えば提供すべきメンタルモデルも違う
• 提供すべきメンタルモデルが違えば UI が違う
つらい
Slide 50
Slide 50 text
名前重要
Slide 51
Slide 51 text
「モデル」とか「理解」とか
⾔ってるけど
⼈はそもそも物事を
どのように理解するのか
Slide 52
Slide 52 text
理解 = 分かる = 分かつ
Slide 53
Slide 53 text
理解 = 分かる = 分かつ
• ⼈は物事に名前がついて初めてそれを他のものと区別する
ことができる
• あるふたつのものが本来的に存在するのではなく、別々の
名前をつけることによって⼆つの存在に分離する
• 分かつことによって、その抽象的性質を帰納的に推論でき
るようになる
• この抽象モデルを⼿に⼊れることが「理解」
Slide 54
Slide 54 text
名前重要
(Ruby の⽣みの親 まつもとゆきひろ⽒)
by Matz
Slide 55
Slide 55 text
System Model Designer’s Model User’s Model
• オブジェクトモデル
• スキーマ、DB カラム
• クラス、メソッド
• 変数
• UI エレメント、
コンポーネント
• UI ラベル、⽂⾔
• ⾊、スタイル
• UI ラベル
• ⽂⾔のトンマナ
• オブジェクトの名称
• ⾏為の名称
User Interface
これらをいかに⼀致させるか
またはさせないか
Slide 56
Slide 56 text
基本的なところは統⼀した⽅が良い
• システムの根幹的な概念や動作モデルに関する名称
• 主要なオブジェクト達（名詞）
• それらが取りうる振る舞い（動詞）
• 利⽤シーンにおけるユーザーの区別（名詞）
• ユーザーが取りうるアクション（動詞）
Slide 57
Slide 57 text
統⼀する利点
• 開発チーム内のコミュニケーションの効率化
• バックエンド、フロントエンド、デザイン、コピーにおけ
る名称の⼀貫性
• システムモデルとメンタルモデルの差異が
意図的か否かが分かる
• 開発ドキュメントが書きやすく、読みやすく
• マニュアル、FAQ、マーケティングにも⼀貫性
• 新しい概念に対する命名の必要性判断の⼟台
Slide 58
Slide 58 text
名前重要
(Ruby の⽣みの親 まつもとゆきひろ⽒)
by Matz
Slide 59
Slide 59 text
おすすめの本
Slide 60
Slide 60 text
PMがUXするために
必要なのは多分IA