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
DC Style Redesign
mcduckyart
0
110
本当に欲しかったのはモノレポツールではなく、tsconfigの設定だった / monorepo-tsconfig
rdlabo
1
150
教育分野に強いUIデザイナー / 山口哲弘ポートフォリオ
t2yamaguchi429
0
390
Goodpatch Tour💙 / We are hiring!
goodpatch
31
850k
ビジネス成果を最大限に発揮するPORTFOLIO
ataxi1003
0
160
ビジネスアナリシスはビジネス”分析”じゃないよ!~システム人材が価値を生むための基盤スキルとしてのビジネスアナリシス~
bpstudy
0
460
デフォルトの16:9(960*540px)のケース / Google Slide Size Test
arthur1
0
2.8k
Hatena Engineer Seminar #33 チームと開発するためのモック
takuwolog
0
290
Bulletproof Design System with TypeScript
takanorip
6
3.3k
Storyboard Honey
rocioparronrubio
0
270
真・altはつけるだけじゃなくて -alt属性の考察 2025年版-
securecat
5
1.4k
パンくずリストかわいい(breadcrumb so cute)
ysuda
0
270
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Gamification - CAS2011
davidbonilla
81
5.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.9k
We Have a Design System, Now What?
morganepeng
52
7.6k
The Invisible Side of Design
smashingmag
299
51k
For a Future-Friendly Web
brad_frost
179
9.8k
GitHub's CSS Performance
jonrohan
1031
460k
Become a Pro
speakerdeck
PRO
28
5.4k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Building Applications with DynamoDB
mza
95
6.4k
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