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
アフォーダンスとシグニファイア
ryokanakai
0
300
Haruki_Konaka_Portforio.pdf
haruki556
0
550
みんなに知って欲しい 視覚過敏のアクセシビリティ
0opacity_
4
790
ZKK_001.pdf
nicholaspegu
0
830
Commune_Brand_Guideline_JA
commune
1
150
Осязаемый потребительский опыт. Ловим его за хвост с Картой процесса-опыта
ashapiro
2
210
富山デザイン勉強会_デザイナーの打ち合わせ術_打ち合わせをクリエイティブな時間にする方法.pdf
keita_yoshikawa
1
110
地図・デザイン・可視化 −情報をわかりやすく伝えるために−
hjmkth
1
460
「ちょっといいUI」を目指す努力 / Striving for Little Big Details
usagimaru
6
3.6k
[Designship2024] デザインの力でサービスの価値を追求していたら、組織全体をデザインしていた話
okakasoysauce
1
760
なぜデフォルトが青色!? Tint Colorの理由に迫る
akidon0000
0
430
アクセシビリティのはじめかた デザイナー編
tokimari
3
1.3k
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
The Cult of Friendly URLs
andyhume
78
6k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
The Power of CSS Pseudo Elements
geoffreycrofte
72
5.3k
Writing Fast Ruby
sferik
626
61k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
The World Runs on Bad Software
bkeepers
PRO
65
11k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.8k
Gamification - CAS2011
davidbonilla
80
5k
Building Better People: How to give real-time feedback that sticks.
wjessup
363
19k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
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