Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PMがUXするために必要なのは多分IA / IA for PM
Search
Kotaro Kokubo
October 24, 2018
Design
10
11k
PMがUXするために必要なのは多分IA / IA for PM
PMCONF 2017 の UX トラックでの講演資料です
Kotaro Kokubo
October 24, 2018
Tweet
Share
Other Decks in Design
See All in Design
FANCL×CA流アプリリニューアルPJ 成功の秘訣とそのプロセス / dx-fancl-renewal
cyberagentdevelopers
PRO
2
1k
富山デザイン勉強会_ワンランク上に見せるデザインのコツ.pdf
keita_yoshikawa
0
160
同人音声のための、 最高の視聴体験を求めて【サブカル×デザインMeetUP!】
vivion
0
320
クライアントワークにおける UXリサーチの実践
kozotaira
0
380
デザインシステムの力 Webデザイナーとエンジニアのための実践ガイド / The Power of Design System
spindle
9
5k
LayerX DesignersDeck
layerx
PRO
0
3.1k
Findy - デザイナー向け会社紹介 / Hiring Findy's Designers
findyinc
6
70k
20250129_DAST28_実空間にデジタル資源の接点をデザインする
majimasachi
0
240
東急URBAN HACKSのデザイナーって何やってるの? 〜Designer Night #1〜
tak073
0
270
Managing Design Systems (Antwerp 2024)
nathanacurtis
1
400
株式会社デイトラ様│コーポレートサイト│コンセプトシート
haruka_capeo
0
580
Where to Start with a Design System Across Different Frontend Frameworks | SpectrumTokyoMeetup#15
tararira
0
140
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Navigating Team Friction
lara
183
15k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
A designer walks into a library…
pauljervisheath
205
24k
Fireside Chat
paigeccino
35
3.2k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
BBQ
matthewcrist
87
9.5k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Thoughts on Productivity
jonyablonski
69
4.5k
Speed Design
sergeychernyshev
28
820
Transcript
株式会社 CAMPFIRE ⼩久保浩⼤郎 PMがUXするために必要なのは多分IA
None
IA とは(雑) • IA = Information Architecture です • IA
は職種ではなくスキルセットです • プロダクト開発に関わるすべてのジョブロールの⼈が持っ ていていいスキル • 抽象的に情報を扱うスキル、程度に考えてください • 今⽇の話は、⼤体 IA っぽい領域の話だと思ってください
• UX is 何? • ユーザビリティと UX • マーケティングと UX
• UI と UX • 名前重要
UX is 何?
Experience User Service/Product
Experience User Service/Product Context/Environment 広告、レビュー記事、⼝コミ 利⽤デバイス、利⽤環境・シーン
UXは環境やコンテキストに依存する • ユーザーと対象(サービス、プロダクト)という ⼆者の間の話のように聞こえるがそうではない • それらを取り巻く環境やコンテキストにその認知は ⼤きく依存する • UX を考える時はユーザーの利⽤環境、マーケット認知、
社会的認知など様々なレベルのコンテキストを考える 必要がある • 別に新しい話ではなく、できるデザイナーは 昔からそこを分かっていて考えてやっていた
User Experience とは 発明されたのではなく 発⾒された概念である 詳しくは「UX⽩書」やその解説をおググりください
ユーザビリティとUX
「道を歩く」のユーザビリティ Case 1
None
None
Success! Great Usability!
ユーザビリティ = 予測可能性
But…
Is there any experience? Past Present Future
「道を歩く」の Experience Case 2
None
None
None
! Experience!
これらの違い
Prediction Expectation Result Case 1
Prediction Expectation Result ! Case 2
Prediction Expectation Result ! Gap! Case 2
Prediction Expectation Result Gap Micro Experience Unit
Experience User Service/Product Context/Environment
マーケティングとUX
対象ユーザーのペルソナを どう考えるか
プロダクトライフサイクルや マーケットへの普及のステージ によって対象ユーザー像は変わる
Product Lifecycle Introduction Growth Maturity Decline
Diffusion of Innovation Innovator Early Adopter Early Majority Late Majority
Laggard
対象ユーザーペルソナが変わると プロダクトデザインの何が変わる?
学習曲線のデザインが変わる Type B Type A
何に対する学習度か? • サービスの提供価値や動作概念に対する理解度 • 利⽤習熟度A(よく使う機能を意識せず素早く使える) • 利⽤習熟度B(⾼度な機能を⾒つけて使いこなす)
Innovator Early Adopter Early Majority Late Majority Laggard Type A
Type B
• 新しいものへの興味が強い • 難しいことも理解しようとする • 絶対数は少ないがオピニオンリー ダーとして影響⼒がある • カーネマンのシステム2的 Type
A Type B • ⼈が使っているもの、流⾏ってい る物を使いたがる • 理解するのが難しいと使わない • 絶対数は多い • カーネマンのシステム1的 • ⾒た⽬が美しく魅⼒的 • 操作に必要なサインの提⽰ • ⼀度に処理すべき情報量が少ない • 動作モデルが理解可能 • 慣れた予測で素早く操作可能 • ⼀覧性が⾼く情報量が多い ϖϧιφ ·ΕΔUI
UIとUX
PMが考えなきゃいけないモデルたち Business Model System Model Product Mental Model
System Model Mental Model システムがどのように 動作するか(事実) システムがどのように 動作するように⾒えるか(認知) これらをいかに⼀致させるか またはさせないか
システムモデルとメンタルモデル • これらは単純に⼀致させればよいというものではない • 効率的で合理的なシステムの動作モデルと、ユーザーがわ かりやすく使いやすいと考えるモデルは違うことは多い • どちらかが先に決定するわけではなく、相互に影響しなが らできあがることも多い •
おそらく昔はシステムモデル先⾏だったが、ユーザビリ ティや⼈間中⼼設計といった概念の普及により改善された • UXという概念の普及もこの流れの⼀環と⾔える
System Model Mental Model システムがどのように 動作するか(事実) システムがどのように 動作するように⾒えるか(認知) これらをいかに⼀致させるか またはさせないか
Mental Model Designer’s Model User’s Model
Mental Model Designer’s Model User’s Model User Interface こう思わせたい(意図) こう思った(認知)
デザイナーズモデルとユーザーズモデル • これらは常に可能な限り⼀致させたい • それをどううまくやるのか、というのが UI デザイン • UI を通してユーザーがデザイナーズモデルを理解する
• その理解の結果がプロダクトに対するメンタルモデル
System Model Designer’s Model User’s Model Product
System Model Designer’s Model User’s Model Product
ターゲットペルソナは複数いる • プロダクトライフサイクルやマーケットへの普及のステー ジによって対象ユーザー像は変わる • 対象ユーザー像が違えば提供すべきメンタルモデルも違う • 提供すべきメンタルモデルが違えば UI が違う
つらい
名前重要
「モデル」とか「理解」とか ⾔ってるけど ⼈はそもそも物事を どのように理解するのか
理解 = 分かる = 分かつ
理解 = 分かる = 分かつ • ⼈は物事に名前がついて初めてそれを他のものと区別する ことができる • あるふたつのものが本来的に存在するのではなく、別々の
名前をつけることによって⼆つの存在に分離する • 分かつことによって、その抽象的性質を帰納的に推論でき るようになる • この抽象モデルを⼿に⼊れることが「理解」
名前重要 (Ruby の⽣みの親 まつもとゆきひろ⽒) by Matz
System Model Designer’s Model User’s Model • オブジェクトモデル • スキーマ、DB
カラム • クラス、メソッド • 変数 • UI エレメント、 コンポーネント • UI ラベル、⽂⾔ • ⾊、スタイル • UI ラベル • ⽂⾔のトンマナ • オブジェクトの名称 • ⾏為の名称 User Interface これらをいかに⼀致させるか またはさせないか
基本的なところは統⼀した⽅が良い • システムの根幹的な概念や動作モデルに関する名称 • 主要なオブジェクト達(名詞) • それらが取りうる振る舞い(動詞) • 利⽤シーンにおけるユーザーの区別(名詞) •
ユーザーが取りうるアクション(動詞)
統⼀する利点 • 開発チーム内のコミュニケーションの効率化 • バックエンド、フロントエンド、デザイン、コピーにおけ る名称の⼀貫性 • システムモデルとメンタルモデルの差異が 意図的か否かが分かる •
開発ドキュメントが書きやすく、読みやすく • マニュアル、FAQ、マーケティングにも⼀貫性 • 新しい概念に対する命名の必要性判断の⼟台
名前重要 (Ruby の⽣みの親 まつもとゆきひろ⽒) by Matz
おすすめの本
PMがUXするために 必要なのは多分IA